Model Context Protocol (MCP) is an open-source standard used to connect AI applications to external systems. It is a stateful protocol.
One can use MCP to connect language models to data sources - files, databases, etc. Alternatively, if you wish to connect to external tools such as a calculator, search engines, etc., or even specialized prompts, then MCP is the tool you probably need to consider.
To keep things simple, we can think about MCP from the perspective of tools, resources, prompts and notifications.
As seen above, MCP sits between the LLM client and the tools, resources, prompts, etc., that is exposed to it. It is a standardize way of connecting AI applications to external systems
**ARCHITECTURE**
MCP architecture consists of hosts, clients and servers.
Hosts:
The host is the AI application that coordinates and manage MCP clients. VSCode, etc., is an example of a MCP host.
MCP Client:
A component that maintains a connection to a MCP server and obtains a context from the MCP server to use.
The MCP clients are instantiated by the host application, for example VSCode. The host application manages the overall user experience and coordinates multiple clients. Each client handles one connection with a specific server.
Considering the above, it is important to distinguish between the host and the client. The host is the application like VSCode that we interact with. The client represents the protocol-level components that enable server connections.
While clients get context from the server, clients may provide several features to the servers. Because the client can share information, it allows the server authors to create richer interactions.
**Elicitation** - Allows the server to request specific information from users during interactions. This allows the servers a structured way to gather information on demand. Instead of requesting all information upfront, the server is able to request specific information as needed. This allows the servers to adapt to user needs rather than rigid patterns.
**Roots** Allows the clients to specify which directory, the servers should focus on.
They define the boundary of the filesystem for server operations. More specifically, the allows the client to specify which directories the server should focus on.
Roots consists of URIs. These specify where the servers can operate. It is important to understand, while these roots provide boundaries, they do not enforce security restrictions. The security has to be implemented at the OS level. At this point, you have to enforce permission or run your solution in a sandbox.
These roots are exclusively file system paths, that always use file:///
Clents update the root list via "roots/list_changed"
Think about roots as a coordination point between clients and servers. The server SHOULD respect root boundaries and they must enforce them. Keep in mind the server runs code that the client cannot control. These roots work best when the servers are trusted.
**Sampling** This allows the servers to request LLM completions through the clients, which enables an agentic workflow.
Image source: https://www.elastic.co/security-labs/mcp-tools-attack-defense-recommendations
MCP Server:
Program that provides a context to the MCP clients. They expose specific capabilities to AI applications through a standardized interface. For example, access to database servers, documents, GitHub, etc. The real power comes when multiple MCP servers work together.
As an example of this architecture, VSCode would be a MCP host. When it establishes a connection to a MCP server, VS Code run-time initiates a client object that maintains a connection to that MCP server. Similarly for other connections to MCP servers, VSCode run-time will initiate a client object. The host will manage all of those connections.
**Primitives**:
Key to MCP are the primitives. They define what clients and servers can offer each other. It also entails the type of contextual information that can be shared with AI applications and the actions that can be performed:
**Tools**:
These are the executable applications that the model can invoke. They allow the AI model to perform actions. These tools are requested based on context. They have a defined schema interface that the LLM can invoke.
Each tool performs a single operation, with clearly defined inputs and outputs. In some cases, these tools may require user consent prior to execution. This allows users to maintain control over the model's action.
Methods uses are "tools/list" which is used to discover available tools and "tools/call" to execute the specific tool.
These tools are model controlled, as in the model can discover and invoke them automatically. While the model can invoke these tools automatically, MCP emphasizes human oversight via:
* Displaying available tools in a UI. This allows the user to decide if a tool should be used in specific interactions.
* Approval dialogs for tool interaction
* Permission settings
* Activity logs showing tool execution.
**Resources**:
These are the data sources, that provides contextual information to your AI applications. For example, access to database, files, records, etc.
Provides structed access to information that the AI model can use for additional context. These data can come from files, API, databases, etc., that can be used to add additional context to the model. These resources are accessed via unique URI for example "file:///path/to/document.md".
Resources have two discovery patterns.
**Direct Resources**. Fixed URIs that that points to a specific data.
The other is **Resource Templates**. These are dynamic URIs with parameters for flexible queries. These templates include metadata such as title, description and expected mime types. This makes them discoverable and self-documenting.
- resources/list
- resources/templates/list
- resources/read
- resources/subscribe
AI applications retrieves the reources and decides how to process them.
**Prompts**:
Templates that can be reused to help structure the interactions with language models. Think about your system prompts as an example.
To learn which primitives are available, MCP servers will use "*/list" to discover the available primitives. For example to list tools, a client can do "tools/list". Once it has the list it can then execute them.
These are reusable templates, that allow MCP sever authors to provide parameterized prompts for a domain or showcase how best t suse the servers.
The methods used are:
- prompts/list
- prompts/get
These prompts are structured templates. They define expected input and interaction patterns. These are user specific and require explicit invocation rather than automatic. These prompts can also be context aware by referencing available resources and tools. These allow for comprehensive workflows.
From the layers perspective MCP consists of a **Data** and **Transport Layer**.
**Data Layer**
- Defines the JSON-RPC protocol schema for client server communication: It handles:|
- Lifecycle management: This relates to the connection initialization, capability negotiation and connection termination between clients and servers.
This is also where capabilities are negotiated for the client and servers.
- Server Features: Allows the server to provide core functionality such as tools that allow AI actions, resources for context data and prompts. These prompts are used for interaction with clients.
- Client features: Allows the servers to request the client to sample from the host LLM, get input from the user and log messages to the client.
Utility features: For additional capabilities such as notification for real time updates, progress tracking, etc. The server can proactively notify connected clients.
**Transport Layer**
Define the communication mechanism and channels than enables data exchange between clients and servers. This includes connection establishment, message framing and authorization.
It abstracts communication details from the protocol layer.
There are two transport mechanisms used by MCP, these are **Stdio** and **Streamable HTTP** transports.
**Stdio Transport**:
Used on the local machine via standard input/output for direct communication between processes.
**Streamable HTTP transport**:
This uses HTTP post for client-server communication. The server can optionally use Server-Sent Events for streaming capabilities. MCP uses standard HTTP authentication methods, including bearer tokens, API keys. For authentication tokens, MCP recommends using OAuth for authentication.
MCP also has the capability for notifications
**Notifications**
Notifications allow for dynamic update between the servers and clients. Hence when a tool changes or some new capability has been introduced, the server can send a tool update notification to the client. MCP servers can provide real-time updates to connected clients.
No response is required when a notification is sent.
The notification is only sent by the servers that declare "listChanged" : True as part of the tool capability during initialization.
The decision to send a notification is dependent on internal state changes. These connections are dynamic. From the client perspective, when this notification is received, it typically requests the updated tool list.
The notification mechanism is critical and helps to ensure a dynamic environment. The tools may come and go based on the server state, external dependencies or user permissions.
Clients do not have to ask for updates; they are notified when they occur.
It also ensures consistency, in that the client always have reliable information about the server capabilities.
Finally, there are real-time collaboration.
When the AI application initializes and establishes a connection to configured servers, the client's manager stores their capabilities for later use.
From the perspective of tool discovery, the "tools/list" is used. Each tool response has several fields:
- name: This is unique tool name. The name should follow a clear format: For example, "calculator_arithemtic" rather than "calculate".
- arguments: These are the input parameters. These are determined by the tools inputSchema.
- Title: This is a human readable tool, that clients can show to users.
- description: A detailed explanation of what the tool does and when to use it.
- inputSchema: A JSON schema, that defines the expected input parameters and validation. There should be clear documentation. Uses standard JSON-RPC with unique id. This id is used for request response correlation.
When the language model needs to use a tool, the AI application intercepts the tool call and routes it to the appropriate MCP server, executes it and returns the results back to the language model. This is all part of the conversation flow. Thus, the LLM can access real-time data and perform actions in the external world.
Reference:
What is the Model Context Protocol (MCP)? - Model Context Protocol
MCP Tools: Attack Vectors and Defense Recommendations for Autonomous Agents
Posts in this Series:
Beginning Message Context Protocol (MCP): But what is MCP?
Beginning Message Context Protocol (MCP): MCP Security
Beginning Message Context Protocol (MCP): Attacking and Defending MCP
No comments:
Post a Comment