"Describe the architecture of MCP Protocol and how it works. Keep it simple"

gemini-2.5-pro.txt

### Core Architecture

MCP utilizes a **Host-Client-Server** architecture:

1.  **Host:** This is the primary application integrating with AI/LLMs (e.g., Claude Desktop, an IDE like Cursor or Zed, a custom application). The Host's responsibilities include:
    *   Creating and managing multiple **Client** instances.
    *   Orchestrating interactions between the user, the AI model, and various Clients/Servers.
    *   Enforcing security policies, managing user consent, and handling authorization.
    *   Aggregating context from different sources before presenting it to the LLM.
    *   Handling `sampling` requests initiated by Servers (acting as the intermediary to the actual LLM).

2.  **Client:** These components run *within* the Host process. Each Client instance maintains a dedicated, stateful **1:1 connection** with a single **Server**. Its roles are:
    *   Establishing and managing the connection lifecycle (initialization, operation, shutdown) with its paired Server.
    *   Handling protocol version and capability negotiation.
    *   Routing JSON-RPC messages between the Host and the Server.
    *   Managing security boundaries between different Servers it connects to.

3.  **Server:** These are typically lightweight, independent processes or services (can be local or remote) that expose specific capabilities or data sources via the MCP protocol. Servers:
    *   Provide context through **Resources** (data like files, database schemas).
    *   Offer executable **Tools** (actions the LLM can trigger, like API calls, file writing).
    *   Define reusable **Prompts** (templates for common interactions, often user-triggered).
    *   Can request LLM interactions (`sampling`) *through* the Client/Host.
    *   Operate within the security constraints defined by the Host and protocol.

This architecture is visualized in the documentation:

```mermaid
graph LR
    subgraph "Application Host Process"
        H[Host]
        C1[Client 1]
        C2[Client 2]
        C3[Client 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "Local machine"
        S1[Server 1<br>Files & Git]
        S2[Server 2<br>Database]
        R1[("Local<br>Resource A")]
        R2[("Local<br>Resource B")]

        C1 --> S1
        C2 --> S2
        S1 <--> R1
        S2 <--> R2
    end

    subgraph "Internet"
        S3[Server 3<br>External APIs]
        R3[("Remote<br>Resource C")]

        C3 --> S3
        S3 <--> R3
    end
```

### How It Works: Communication and Lifecycle

1.  **Protocol Foundation:** MCP is built on **JSON-RPC 2.0**. All communication uses standard JSON-RPC Requests, Responses (Results or Errors), and Notifications. Batching is also supported.

2.  **Transports:** The JSON-RPC messages are exchanged over a transport layer. Standard transports include:
    *   **stdio:** For local servers launched as subprocesses by the client. Communication happens over standard input/output streams.
    *   **Streamable HTTP:** For remote or independent servers. Uses HTTP POST for client-to-server messages and GET (potentially with Server-Sent Events - SSE) for server-to-client messages/streaming. Session management and authorization mechanisms are defined for this transport. *(This replaced the older HTTP+SSE transport)*.

3.  **Connection Lifecycle:**
    *   **Initialization:** The client sends an `initialize` request to the server, specifying its supported protocol version and capabilities. The server responds with the protocol version it agrees to use and its own capabilities. The client confirms with an `initialized` notification. This negotiation ensures both sides know what features are available for the session.
    *   **Operation:** Client and Server exchange messages (requests, responses, notifications) according to the negotiated capabilities and protocol version.
    *   **Shutdown:** Connections are terminated using the underlying transport mechanism (e.g., closing streams for stdio, closing HTTP connections).

### Key Primitives and Interactions

MCP defines several core ways for servers to provide value:

*   **Resources:** Data provided by the server (e.g., file content, logs, database records). Clients can list available resources (`resources/list`), read their content (`resources/read`), list templates for dynamic resources (`resources/templates/list`), and optionally subscribe to updates (`resources/subscribe`, `notifications/resources/updated`). Resources are considered **application-controlled**, meaning the Host/Client decides how and when to use them.
*   **Tools:** Executable functions exposed by the server (e.g., run a command, query an API, write a file). Clients/LLMs can list tools (`tools/list`) and invoke them (`tools/call`). Tools are considered **model-controlled**, intended for the LLM to invoke (with user approval). Servers can provide `annotations` (read-only, destructive hints) for tools.
*   **Prompts:** Pre-defined templates or workflows offered by the server (e.g., common analysis tasks, code review structures). Clients can list prompts (`prompts/list`) and retrieve a specific prompt's message structure, potentially filling in arguments (`prompts/get`). Prompts are **user-controlled**, typically triggered explicitly by the user (e.g., via slash commands).
*   **Sampling:** Servers can request the *Client* to perform an LLM generation (`sampling/createMessage`). This allows servers to leverage AI without needing their own API keys, while the Host/Client maintains control over the model, context inclusion, and user approval.
*   **Roots:** (Client Capability) Clients can inform servers about relevant filesystem directories or locations (`roots/list`, `notifications/roots/list_changed`).

### Design Principles

The architecture is guided by principles like:
*   **Ease of Server Development:** Keep servers simple; complex orchestration is the Host's job.
*   **Composability:** Servers are focused and can be combined.
*   **Security/Isolation:** Servers operate with limited context and cannot see into other servers. The Host enforces boundaries.
*   **Progressive Features:** Capability negotiation allows servers and clients to support features incrementally.

### Security

Security is paramount. User consent, clear permissions, robust validation (especially for tool inputs/outputs and URIs), and secure transport (HTTPS for HTTP) are crucial. The Host plays a central role in enforcing security and managing user approval flows, especially for potentially destructive tools or sensitive resource access. The protocol also defines an [OAuth 2.1-based authorization framework](/specification/2025-03-26/basic/authorization) for HTTP transports.

---

**Relevant Files:**

*   `docs/docs/concepts/architecture.mdx`
*   `docs/specification/2025-03-26/architecture/index.mdx` (Latest Specification Version)
*   `docs/specification/2024-11-05/architecture/index.mdx` (Older Specification Version)
*   `docs/introduction.mdx`
*   `docs/specification/2025-03-26/basic/index.mdx`
*   `docs/specification/2025-03-26/basic/lifecycle.mdx`
*   `docs/specification/2025-03-26/basic/transports.mdx`
*   `docs/specification/2025-03-26/basic/authorization.mdx`
*   `docs/docs/concepts/resources.mdx`
*   `docs/docs/concepts/tools.mdx`
*   `docs/docs/concepts/prompts.mdx`
*   `docs/docs/concepts/sampling.mdx`
*   `docs/docs/concepts/roots.mdx`
*   `docs/docs/concepts/transports.mdx`
*   `schema/2025-03-26/schema.ts` / `schema/2025-03-26/schema.json`

optimus-alpha.txt

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between Large Language Models (LLMs)/AI applications and external tools, resources, and data sources. Its architecture is inspired by proven patterns (such as the Language Server Protocol) and emphasizes security, modularity, and ease of extensibility.

Below is a comprehensive breakdown of MCP architecture and its operation, based solely on the codebase and documentation.

---

### 1. **High-Level Architecture**

#### **Client-Host-Server Model**

MCP follows a **client-host-server** architecture, where each **host** (an LLM application like Claude Desktop or an IDE) can run multiple client instances, and each client maintains a session with a particular server.

```
+--------------------------------------+
|         Application Host Process     |
|  +-------+      +-------+           |
|  |Client1|      |Client2|           |
|  +-------+      +-------+           |
+------+--------------------+---------+
       |                    |
       v                    v
  +----------+        +----------+
  | Server 1 |        | Server 2 |
  | (e.g.,   |        | (e.g.,   |
  |  files)  |        |  db)     |
  +----------+        +----------+
```

#### **Component Roles**

- **Host**: Container/coordinator; manages client instances; enforces security & user consent; handles AI integration, session management.
- **Client**: Establishes 1:1, stateful connection to a server; negotiates protocol/capabilities; manages message transport, request/response dispatch, and maintains session integrity.
- **Server**: Offers specialized context, tools, and resources to clients; can execute code, perform computation, read files, expose prompts, or more.

**Reference:**
- [docs/docs/concepts/architecture.mdx](#)
- [docs/specification/2025-03-26/architecture/index.mdx](#)

---

### 2. **Core Protocol Concepts**

#### **JSON-RPC Foundation**

All MCP communication is based on [JSON-RPC 2.0](https://www.jsonrpc.org/):

- **Requests**: Expect a response (`{ jsonrpc, id, method, params }`)
- **Responses**: Sent in reply to requests (`{ jsonrpc, id, result }` or `{ error }`)
- **Notifications**: One-way messages, no response (`{ jsonrpc, method, params }`)

#### **Capability Negotiation**

During initialization, both sides declare supported capabilities, such as:

- **Sampling**: Can client provide access to LLM completions?
- **Roots**: Can client/server define file system/resource boundaries?
- **Tools**/**Resources**/**Prompts**: Which protocol primitives does the server support?

**Capability negotiation ensures that only mutually supported features are used during the session.**

---

### 3. **Connection Lifecycle & Message Flow**

#### **Lifecycle Phases**

1. **Initialization** (Capability and protocol version negotiation)
2. **Operation** (Bidirectional message exchange using declared features)
3. **Shutdown** (Graceful disconnection)

**Initialization Example:**
```mermaid
sequenceDiagram
    participant Client
    participant Server

    Note over Client,Server: Initialization
    Client->>+Server: initialize request (with protocolVersion, capabilities)
    Server-->>Client: initialize response (with protocolVersion, capabilities)
    Client--)Server: initialized notification

    Note over Client,Server: Normal operation
    ... (requests, notifications, etc.)

    Note over Client,Server: Shutdown
    Client--)-Server: Disconnect
```

#### **Transports:**

MCP supports multiple transport mechanisms for message exchange:

- **Stdio** (standard input/output): typically for local process integration (i.e., host launches server as a subprocess)
- **HTTP with SSE**: independent servers, allows multiple clients, streaming messages via Server-Sent Events (SSE)
- **Streamable HTTP (2025)**: replaces previous HTTP+SSE for enhanced streaming and batching
- **Custom transports**: Implementors can provide others, as long as JSON-RPC and lifecycle rules are enforced.

---

### 4. **Key Protocol Features (Primitives)**

All features are standardized and strongly typed.

#### **Tools (Model-controlled)**

- Exposed by servers, discovered via `tools/list`
- Invoked via `tools/call` (LLM can call tools, subject to human approval)
- Used for integrating actions, computations, API calls, etc.

#### **Resources (Application-controlled)**

- Any server-exposed, addressable data identified by URI (file contents, DB rows, API responses, etc.)
- Discovered via `resources/list`, accessed via `resources/read`
- URIs follow `[scheme]://[host]/[path]` pattern

#### **Prompts (User-controlled)**

- Structured templates for recurring or complex LLM interactions
- Discovered via `prompts/list`, detailed via `prompts/get`
- Allow argument-based customization and resource injection

#### **Sampling**

- Allows servers to request LLM completions through the client
- Ensures privacy and human-in-the-loop for AI operations

#### **Roots**

- Clients inform servers of resource boundaries via roots (e.g., only operate on specific directories)
- Increases clarity and security

---

### 5. **Unified Protocol Utilities**

- **Progress**: Supports progress notification for long-running operations (`notifications/progress`)
- **Cancellation**: Any request can be cancelled (`notifications/cancelled`)
- **Pagination**: Large lists can be paginated via cursors (opaque tokens)
- **Logging**: Servers can emit structured log notifications (`notifications/message`) at syslog severity levels

---

### 6. **Security & Trust Model**

- **User Consent & Control**: All LLM/tool usage must be under explicit user approval. No tool or resource access occurs without user’s knowledge and permission.
- **Data Privacy**: No user data is exposed to servers without user consent. Servers get only necessary slices of context.
- **Capability Isolation**: Servers operate within declared capability boundaries—no server can "see into" another's context or read entire conversations.
- **Tool Confirmation**: Model-controlled actions (“tools”) always require explicit human-in-the-loop confirmation.

---

### 7. **Protocol Versioning & Extensibility**

- Protocol is versioned (e.g., `2025-03-26`).
- Initialization phase negotiates version and falls back if needed.
- Backwards compatibility and extensibility is prioritized—features can be negotiated and older versions supported as needed.

---

### 8. **Reference Implementation Patterns**

#### **TypeScript Example (Server)**
```typescript
import { Server } from "@modelcontextprotocol/sdk/server";
// ...setup...
server.setRequestHandler(ListToolsRequestSchema, async () => {...});
server.setRequestHandler(CallToolRequestSchema, async (request) => {...});
```
#### **Python Example (Server)**
```python
from mcp.server import Server
@app.list_tools()
async def list_tools(): ...
@app.call_tool()
async def call_tool(name: str, arguments: dict): ...
```
#### **Java (Client/Server)**
Supports sync/async paradigms, works with stdio, HTTP(SSE), WebFlux, etc.

---

### 9. **Extending MCP**

- **Custom transports** can be added (see [Transports section](/docs/concepts/transports.mdx))
- **Additional features**/capabilities can be added via capability negotiation and extension objects (`experimental` capabilities)

---

## **Summary Table**

| Layer/Aspect          | Role/Functionality                                                                                                  |
|-----------------------|--------------------------------------------------------------------------------------------------------------------|
| **Host Process**      | Starts clients, manages connection/session, coordinates consent/security, aggregates context                        |
| **Client**            | Maintains 1:1 session with a server; handles protocol negotiation, transport, dispatch, and capability management   |
| **Server**            | Exposes tools, resources, and prompts; handles requests and notifications; operates in isolated context             |
| **Transports**        | Stdio, HTTP (SSE / Streamable), custom                                                                              |
| **Protocol Base**     | JSON-RPC 2.0 messages; requests, notifications, responses; supports batching (2025+)                                |
| **Features (Primitives)** | Tools (model-controlled), Resources (application-controlled), Prompts (user-controlled), Sampling, Roots, Logging   |
| **Lifecycle**         | Initialization → Operation (requests/notifications) → Shutdown                                                      |
| **Utilities**         | Progress, cancellation, logging, pagination, structured errors                                                      |
| **Security Model**    | Explicit user consent, minimized context, tool-bounded operations, clear capability exposure, never full-convo mutability |

---

### **References — Relevant Files**

The following files were key to this answer:

- [docs/docs/concepts/architecture.mdx](#)
- [docs/specification/2025-03-26/architecture/index.mdx](#)
- [docs/specification/2025-03-26/basic/lifecycle.mdx](#)
- [docs/specification/2025-03-26/basic/transports.mdx](#)
- [docs/specification/2025-03-26/server/index.mdx](#)
- [docs/specification/2025-03-26/server/tools.mdx](#)
- [docs/specification/2025-03-26/server/resources.mdx](#)
- [docs/specification/2025-03-26/server/prompts.mdx](#)
- [docs/specification/2025-03-26/client/roots.mdx](#)
- [docs/specification/2025-03-26/client/sampling.mdx](#)
- [docs/docs/concepts/tools.mdx](#)
- [docs/docs/concepts/resources.mdx](#)
- [docs/docs/concepts/prompts.mdx](#)
- [docs/docs/concepts/roots.mdx](#)
- [docs/docs/concepts/sampling.mdx](#)
- [docs/docs/concepts/transports.mdx](#)
- [docs/quickstart/server.mdx](#)
- [docs/quickstart/client.mdx](#)
- [docs/sdk/java/mcp-overview.mdx](#)
- [docs/sdk/java/mcp-client.mdx](#)
- [schema/2025-03-26/schema.ts](#)
- [schema/2025-03-26/schema.json](#)

---

### **Further Reading**

- [Official Documentation](https://modelcontextprotocol.io)
- [MCP Specification (latest)](/specification/2025-03-26/index)
- [Quickstart guides](/quickstart/server, /quickstart/client)
- [Protocol schemas (TypeScript, JSON)](/schema/2025-03-26/)

---

**In short:**
MCP's architecture provides a modular, secure, and extensible framework so that LLM-powered applications can easily and safely access and control external data and tools—without compromising user privacy or security.

If you need diagrams or specific code/usage examples, let me know!

quasar-alpha.txt

he **Model Context Protocol (MCP)** is an open, standardized protocol that connects **LLM (Large Language Model) applications** to **external data sources and tools** in a secure, modular, and highly extensible way. It enables applications like Claude, IDEs, or custom clients to integrate complex context and capabilities into agent workflows, without proprietary integrations.

Below is a comprehensive overview of the **MCP architecture and operational flow** based on the official specifications (latest **2025-03-26**) and the extensive documentation in your repository.

---

## Overview of MCP Architecture

### 1. **Core Components**

MCP follows a **Host → Client → Server** layered model:

```
[Host Application]
      |
      | runs multiple
      v
[Clients] <----> [Multiple Servers]
```

- **Host (Application Host Process)**
  - The LLM-powered application itself (e.g., Claude Desktop, IDEs, agent frameworks)
  - Manages **client instances** internally
  - Enforces security zones, user consent, orchestration

- **Clients**
  - Represent **isolated connections** within the host, one **Client ↔ Server** pair per session
  - Handle initialization, protocol negotiation, message routing
  - Proxy or mediate LLM requests and server capabilities

- **Servers**
  - Lightweight processes exposing **resources**, **tools**, **prompts**
  - Provide API, database, filesystem access, or AI features
  - Can run locally (more common) or remotely
  - Never see full conversation unless explicitly authorized (privacy-preserving by design)


### 2. **Key Design Principles**

- **Isolation & Modularity**
  - Servers do **not** have access to all LLM conversations by default
  - Each server runs in a sandboxed session
  - Hosts orchestrate multiple servers together

- **Progressive Capabilities**
  - Clients and servers can **incrementally** declare support for extra features
  - Compatible even if some features (e.g., sampling, prompts) aren’t supported

- **Maximal Composability**
  - Servers expose granular functionality, can be combined in arbitrary ways
  - A rich ecosystem of composable server modules is encouraged

- **Security & Consent Centric**
  - User controls what data/tools servers see & can execute
  - Designed around **security boundaries** and **human-in-the-loop controls**

---

## How MCP Works: Protocol and Session Lifecycle

### 1. **Transport Layer**

MCP operates over **JSON-RPC 2.0**, transmitted using either:

- **stdio transport** (default, highly portable)
  - Processes connected via stdin/stdout
  - Normally the host **spawns the servers as subprocesses**
- **Streamable HTTP** (replaces HTTP+SSE in 2025 spec)
  - HTTP POSTs + optional SSE streams
  - Suitable for remote servers with persistent connections
  - Requires stricter origin & auth controls (OAuth2.1 support added)

> **Custom transports** can be implemented if they maintain JSON-RPC semantics.

---

### 2. **Protocol Layers**

**MCP** organizes communication into protocol layers:

| Layer              | Description                                                   |
|--------------------|---------------------------------------------------------------|
| **Base Protocol**  | JSON-RPC message exchange, batching, identification          |
| **Lifecycle**      | Connection setup, capability negotiation, graceful shutdown  |
| **Server Features**| Prompts, Resources, Tools                                    |
| **Client Features**| Roots (file/project boundaries), Sampling                    |
| **Utilities**      | Cancellation, Progress, Pagination, Logging, Autocompletion  |
| **Authorization**  | OAuth 2.1 compatible security for HTTP transports            |

---

### 3. **Connection Initialization**

- **Client sends `initialize` request** declaring:
  - Supported **protocol version** (e.g., "2025-03-26")
  - Its own **capabilities** (roots, sampling, etc.)
  - Basic info (`clientInfo`: name, version)

```json
{
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": { ... },
    "clientInfo": { "name": "...", "version": "..." }
  }
}
```

- **Server responds** with:
  - Confirmed/fallback protocol version
  - **Server capabilities** (resources, tools, prompts, logging, etc.)
  - Optional **instructions** (string) summarizing context for model use
  - Its own info (`serverInfo`)

- **Client** must then send:

```json
{ "method": "notifications/initialized" }
```

to transition into operational state.

This **negotiation phase** defines what features both sides may use for that session.

---

### 4. **Operational Phase: Messaging Patterns**

Once initialized, the host and servers communicate via:

| Type         | Initiator(s)            | Purpose                                                                  |
|--------------|-------------------------|--------------------------------------------------------------------------|
| **Requests** | Client or server        | Operation requests (read resource, call tool, create LLM message, etc.)  |
| **Responses**| Counterpart             | Replies to requests, with success or error                               |
| **Notifications**| Both parties        | Inform of changes (resource updated, prompts/tools list changed, logs)   |

Supports **batching** multiple requests in 2025 version for atomic or parallel operations.

---

### 5. **Core Features and Primitives**

#### A) Server Primitives

| Primitive    | Control            | Purpose                                              | Examples                                      |
|--------------|--------------------|------------------------------------------------------|-----------------------------------------------|
| **Prompts**  | *User-controlled*  | Templated prompts / slash commands offered to users  | "Summarize file", "Explain snippet"          |
| **Resources**| *Application-controlled* | Context data supplied by servers                   | Files, git diffs, images, logs               |
| **Tools**    | *Model-controlled (+user approve)* | Executable functions called by LLMs         | Run API call, update DB, shell commands      |

Servers **declare** which of these they support during initialization.

Each supports standard list/get, paginated, and update notification methods.

#### B) Client Features

- **Roots**
  - Client tells servers what filesystem areas/repositories to focus on
  - Client declares whether root-list *changes* will be notified
- **Sampling**
  - Servers request nested LLM calls *via the client*
  - Client always **maintains control** and can inject moderation/human oversight
  - Server preferences for model/cost/speed/intelligence are **hints**

---

### 6. **Utilities**

Standardized utilities complement data and tool exchange:

- **Cancellation** of long-running or obsolete requests
- **Progress** notifications with percentage and messages
- **Pagination** of large resource, prompt, tool lists via opaque cursors
- **Logging**: Servers can emit structured log notifications with severity levels
- **Autocompletion** for arguments to server prompts or resource URIs

---

### 7. **Shutdown**

Either side can terminate the session at any time, usually by:

- Closing transport streams
- Killing server subprocess
- Ending HTTP/SSE connections

No special shutdown messages are required, but graceful cleanup and cancellation **SHOULD** be attempted.

---

## Other Important Aspects

### Capabilities Negotiation (dynamically)

Each *session* defines what is supported by each side – older/newer servers and clients can **downgrade features gracefully**.

---

### Security & Trust Model

- **User remains in control**:
  - Server never sees whole LLM conversation unless context explicitly included
  - Tools cannot execute without client mediation
  - Sampling can be reviewed and modified by user BEFORE executed
- **OAuth 2.1** recommended for remote servers, including:
  - Metadata discovery
  - PKCE
  - Dynamic client registration
  - Access & Refresh tokens
- **Explicit fencing** of Roots, user approval before data is shared or actions taken
- **Annotations / Hints** (e.g., tool may be destructive, readonly) to help UI, but **NOT** enforceable trust boundaries

---

### Protocol Versioning

- Protocol versions named by cutoff date, e.g., `"2024-11-05"` or `"2025-03-26"`
- Clear schema backward compatibility rules
- Negotiation ensures both sides use compatible set

---

## Summary Diagram (from specification)

```mermaid
graph LR
subgraph Host Process
    H[Host]
    C1[Client 1]
    C2[Client 2]
    C3[Client 3]
    H --> C1
    H --> C2
    H --> C3
end

subgraph Local
    S1[Server 1<br/>Files & Git]
    S2[Server 2<br/>Database]
    R1[(Local Resource A)]
    R2[(Local Resource B)]
    C1 --> S1
    C2 --> S2
    S1 <--> R1
    S2 <--> R2
end

subgraph Internet
    S3[Server 3<br/>External APIs]
    R3[(Remote Resource C)]
    C3 --> S3
    S3 <--> R3
end
```

---

## Typical Request-Response Sequence

```mermaid
sequenceDiagram
Client->>Server: initialize
Server-->>Client: initialize result
Client--)Server: initialized notification

Client->>Server: tools/list
Server-->>Client: list of tools

Client->>Server: prompts/get
Server-->>Client: prompt content

Server->>Client: sampling/createMessage (nested LLM request)
Client-->>Server: generated message (after user approval)
```

---

## Recap: What does MCP provide?

- **Standard language** for connecting multiple servers, tools, data sources, prompts with LLM-powered hosts
- **Privacy & consent** boundaries by design
- **Composability & flexibility** — works with many servers, easy to build new servers
- **Incremental adoption** with minimal capabilities, or full features
- **Multiple transports** (local stdio, remote HTTP/SSE)
- **Optional advanced features** like OAuth2.1, batching, autocompletion, granular capabilities

---

## References to Relevant Files

The above answer is synthesized from:

- **`docs/specification/2025-03-26/architecture/index.mdx`** — core architecture diagrams and description
- **`docs/specification/2025-03-26/basic/lifecycle.mdx`** — protocol initialization and negotiation flow
- **`docs/specification/2025-03-26/basic/transports.mdx`** — stdio and HTTP transport details
- **`docs/specification/2025-03-26/server/index.mdx`**, `server/prompts.mdx`, `server/resources.mdx`, `server/tools.mdx` — description of key server primitives
- **`docs/specification/2025-03-26/client/roots.mdx`** and **`client/sampling.mdx`** — client-exposed features
- **`schema/2025-03-26/schema.ts`** and `schema.json` — canonical schemas
- **`docs/docs/concepts/architecture.mdx`** — explanation of concepts from a developer-centric perspective, complementing the spec
- **`docs/sdk/java/mcp-overview.mdx`**, **`mcp-client.mdx`**, **`mcp-server.mdx`** — SDK implementation details supporting the above architecture

---

# In short:

MCP defines a **modular, privacy-preserving, extensible JSON-RPC protocol** that **allows LLM applications (hosts) to connect multiple isolated servers**, which expose **tools, prompts, and resources**, **coordinate nested LLM calls**, and **integrate a wide array of data and APIs into AI workflows** — all with **secure user consent** and **flexible runtime capabilities negotiation**.

This unlocks building sophisticated, composable, and **safe** LLM-based systems with minimal integration effort.