One protocol so your AI can actually reach your tools
Model Context Protocol standardizes how an AI application talks to the systems that hold its tools and data — so a server built once works with any compliant host, instead of every app inventing its own connector.
Enterprise example — an assistant looks up an incident or issue, adds context, or runs an approved update, always inside the server's own permissions.
Without a shared protocol, every integration is a one-off
Repositories, ticketing systems, internal APIs, documents, databases — an AI app needs all of it eventually. Left alone, each connection becomes its own bespoke build, maintained forever, and none of it transfers to the next application.
Before
A different custom connector per system, each with its own upkeep.
After
One protocol. A server built once is reachable by any compliant host.
How the pieces fit together
The host is the AI application. It uses MCP client functionality to reach one or more servers, and each server exposes capabilities while connecting onward to whatever it actually represents.
Host
Owns the UX, model calls, orchestration and policy.
Client
Speaks MCP to a server and uses what it exposes.
Server
Publishes tools, resources and prompts.
External system
The API, database, repo, files or platform.
Key distinction
MCP is an integration protocol, not an agent framework. It can hand capabilities to an agent, but reasoning, planning, approval and orchestration stay the host's job.
Three building blocks
Tools let the model act. Resources hand it read-oriented context. Prompts package a reusable interaction template.
Tools
Actions — for when the model needs to perform an operation.
e.g. create a ticket, query an API, update a record
Resources
Data & context — for read-oriented material the app pulls in.
e.g. documents, records, configuration, reference data
Prompts
Reusable templates — for interaction patterns users can pick.
e.g. code review, investigation, analysis workflow
Six steps, one round trip
From learning what a server can do, to folding the result back into the conversation.
1
Discover
Learn what the server exposes.
2
Select
Check the capability fits the task.
3
Validate
Match arguments to schema and policy.
4
Execute
The server runs the operation.
5
Return
Results come back to the client.
6
Continue
The host acts on the result.
Protocol-version note
Modern MCP (2026-07-28) is stateless at the protocol layer and dropped the older initialize/session handshake — confirm which generation your SDKs support before comparing examples.
Local and remote MCP
The common choice for a local subprocess integration — the host launches or attaches to a server and talks over standard input and output.
The current transport for a remotely deployed server — built for the authentication, gateways, policy and observability an enterprise setup expects.
MCP inside an enterprise agent stack
Identity, authorization, approval, audit and observability travel with the request as it crosses the boundary.
Cross-cutting controls
What to get right — and where teams trip up
Security principles and the design mistakes that break them, side by side.
Least privilege
Grant a server and its tools only the permissions their purpose needs.
Validate inputs
Schemas help; sensitive operations still need deterministic checks.
Preserve identity
Carry a real authorization model instead of one open service account.
Audit actions
Log who asked, what ran, and the outcome — without leaking secrets.
Treat MCP as the agent
It standardizes the connection; your agent still owns reasoning and policy.
Build one giant tool
Prefer narrow operations with explicit schemas over a catch-all.
Grant broad permissions
Respect the authorization boundary of the system underneath.
Trust everything returned
Tool descriptions and server responses are input, not instructions.
Reading older MCP material
The 2026-07-28 generation dropped sessions and the initialize handshake, and marks standalone roots, sampling and logging as deprecated for new work. Older implementations may still behave the old way — check the protocol version before comparing examples.
Ready to see if it stuck?
AI Pathway's scenario-based mock exams test whether you can apply architecture, tool design, context and reliability concepts under exam conditions.
Browse mock examsOfficial MCP resources
Use the official spec and SDK docs as the source of truth for implementation details.