Introduction to Model Context Protocol (MCP)

If you haven’t looked at the Model Context Protocol (MCP) yet, I recommend familiarizing yourself with it, at least briefly.

Documentation: modelcontextprotocol.io/introduction Protocol Specification: spec.modelcontextprotocol.io/specification/2024-11-05/

For the task at hand, “we need an API to connect the world with LLM, but the outcome is unclear,” the API turned out to be quite good. It’s simple (built on JSON-RPC 2.0), compact (JSON-Schema occupies 2000 LOC), and extensible through capabilities. The protocol includes synchronous communication via request/response and asynchronous communication through one-way notifications. The primitives are nice: there is a structure for errors and an id for “gluing requests and responses” is provided, and there are no unclear fields:

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "result?": {
    "key": "unknown"
  },
  "error?": {
    "code": "number",
    "message": "string",
    "data?": "unknown"
  }
}

The interaction is two-phased. At the start, the client and server exchange versions and “capabilities” that they can provide to each other.

Currently, the following capabilities are described:

• client:roots — the ability to provide a list of “folders” in the file system. It’s still unclear.
• client:sampling — support for requests to the client’s LLM from the server side. The name is strange, but okay. Through this capability, theoretically, you can also ask something from the user.
• server:prompts — the ability to provide the client with “useful” prompts in the context of this server, among which the user can already choose what they need.
• server:resources — providing access to resources. Resources can be text or binary. They are identified by URI (https://, file://, git://). Currently, only reading and subscribing to changes are available, no writing.
• server:tools — everything is clear here, a complete analogy with regular tools.
• server:logging — the ability to send logs to the client.

What confused me about the capabilities was the lack of versioning within a single capability. For experimental ones, for example, I had to create a separate one. I’m afraid there will be chaos with compatibility or some kind of workaround, like versions in names. Or they might add it in future versions.

Current Roadmap: modelcontextprotocol.io/development/roadmap

• Remote MCP connections
• Reference implementation of the client
• Package management for MCP servers
• Support for agents