MCP Architecture
How clients, servers, tools, resources, prompts, permissions, and results fit together.
The basic model
MCP separates the agent runtime from the systems it needs to use. The client talks protocol; the server owns the integration with a database, file system, SaaS product, or internal workflow.
User request β AI client / agent runtime β discovery + invocation MCP server β controlled access Tool, data source, workflow, or local system
Capability types
Callable actions with structured inputs, such as search, create ticket, query database, or validate file.
Readable context, such as documents, records, schemas, configs, or project metadata.
Reusable prompt templates that guide common interactions or workflows.
Responsibility split
| Layer | Owns | Should not own |
|---|---|---|
| Client | Discovery, selection, model context, permission UX | Business logic hidden inside external systems |
| Server | Integration logic, validation, execution, errors, audit logs | Unbounded model reasoning or unrelated task workflow |
| Skill | Task procedure and reusable expertise | Direct protocol transport or server implementation |
Concrete request flow
This is the same documentation-search workflow written as a sequence. It shows what each layer knows and what it should not guess.
1. User asks:
"Which page explains how Skills are structured?"
2. Client prepares available capabilities:
search_docs(query, limit)
3. Model selects the capability:
query = "Skill structure"
limit = 3
4. Server validates input:
query must be a non-empty string
limit must be between 1 and 10
5. Server executes search and returns:
results: [{ title, url, snippet }]
6. Client gives result back to the model.
7. Model answers with a link and a short explanation.Security boundaries
MCP does not remove the need for permissions. It gives you a place to define and enforce them.