> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Components Breakdown of MCP
> Explains Model Context Protocol, its components, and typical stateful JSON‑RPC client–server interactions including resources, prompts, tools, roots, sampling, and elicitation workflows.
In this lesson we'll explain what MCP (Model Context Protocol) is and break down its core components in a clear, practical way. After a short overview, you'll see how an MCP server and client typically interact during a stateful session.
MCP stands for Model Context Protocol.
* Model: the AI (usually large language models or LLMs).
* Context: external or third‑party data and application state that you supply to the model so it can produce more relevant, contextualized responses.
* Protocol: the rules and message formats that govern how clients and servers talk to each other.
For full details, see the official Model Context Protocol specification: [https://modelcontextprotocol.io/introduction](https://modelcontextprotocol.io/introduction)
High-level expectations from the specification
* Communication format: MCP standardizes client ↔ server messages using JSON-RPC. That enforces a consistent request/response shape, error handling, and method dispatching.
* Stateful connection: MCP assumes sessions are stateful. Clients and servers keep shared session state (roots, resources, ongoing contexts) rather than treating every request as isolated.
* Server responsibilities: MCP servers expose structured data, reusable prompts, and callable tools to clients.
* Resources: structured contextual data (documents, embeddings, or connectors to external data sources) that the server supplies to models or clients.
* Prompts: managed templates or prompt compositions the server can provide or reuse for consistent elicitation.
* Tools: integrations and callable actions (search, code execution, API invocations) available to the model or client during generation.
* Client responsibilities: MCP clients orchestrate model sampling, manage roots (conversation or context threads), and coordinate elicitation workflows.
* Sampling: invoking the model to produce text given a prompt and context, with configurable generation parameters.
* Roots: persisting root contexts or conversation threads that group related messages and state.
* Elicitation: composing prompts, selecting resources, and calling tools to derive targeted answers from the model.
Summary table — MCP roles and responsibilities
| Component | What it is | Typical responsibilities |
| - | - | - |
| `Model` | The LLM used for generation | Produce outputs given prompts and context; accept tool calls |
| `Context` | External data and state | Provide documents, embeddings, user/session state to the model |
| `Protocol` | JSON-RPC message rules | Define message formats, lifecycle, error semantics |
| Server | MCP-compliant service | Expose `resources`, `prompts`, `tools`; manage session state |
| Client | Consumer of MCP services | Perform `sampling`, manage `roots`, orchestrate `elicitation` |
Typical MCP session flow (simplified)
1. Connection establishment
* Client opens a stateful JSON-RPC session to the MCP server.
* Server and client negotiate any required session metadata (capabilities, auth).
2. Resource discovery
* Client queries available resources, prompt templates, and tools.
* Server returns metadata describing each resource/tool (types, access patterns).
3. Root creation
* Client creates a root context (conversation thread) to group related interactions and state.
4. Elicitation orchestration
* Client combines prompts, selected resources, and tool calls into an elicitation plan.
* Client requests sampling from the model via JSON-RPC methods, passing generation parameters and context.
5. Tool invocation (optional)
* During elicitation, the model or client may invoke server-side tools (search, APIs, code runners).
* Tools return results back into the session context for reuse.
6. Result delivery and state update
* Server returns model outputs (and any tool outputs) to the client.
* Session state (roots, resources, logs) is updated so future interactions can build on prior context.
7. Session lifecycle
* Clients may continue to sample, update resources, or close the session per lifecycle rules in the spec.
Best practices and interoperability notes
* Keep prompts and resources modular: servers that expose composable prompt templates and typed resources make clients simpler to implement.
* Treat the connection as stateful: rely on roots and resources to persist context rather than repeatedly resending large payloads.
* Use JSON-RPC strictly: following the spec’s method names, parameters, and error codes ensures cross-implementation compatibility.
If you plan to implement or integrate with MCP, read the full [Model Context Protocol specification](https://modelcontextprotocol.io/introduction). It contains detailed JSON-RPC method definitions, required lifecycle behaviors for stateful sessions, and authentication/capability guidance.
References and further reading
* Model Context Protocol — Specification: [https://modelcontextprotocol.io/introduction](https://modelcontextprotocol.io/introduction)
* For related patterns and best practices, search for "stateful LLM orchestration", "prompt templates", and "LLM tool integration".
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.