# What A standardized way for LLMs to consume APIs. I.e. a protocol for such activities. # Why? Because things get pretty interesting when you let LLMs take independent actions, interacting with the outside world. The classic example: Ask LLM about the weather. Wouldn't it be nice if it could respond accurately? I say yes. # An ode to Uncloud... I'm pretty excited about MCP because I tried to build something similar several years ago. Before LLMs were interesting I set about trying to build a connected knowledge graph of my personal digital information, then productize it for others. The idea was to have adapters that could be used to pull data out of various systems using a standard protocol. The adapters could be written by end users, so any user could connect any data source and _importantly_ they could share those connectors with others. This would allow a community to build up and allow any given user to connect all theri data sources without needing to write code themselves. The Raycast extension store solves an analogous problem, in case you're familiar with it. Raycast is a mashup of a GUI and a command line. This turns out to be a useful interface to lots of different apps, so they created an extension system whereby anyone can extend the product and share it with others. Anyway, back to Uncloud and MCP. The nascent startup folded before we fully developed the idea or the protocol. Thankfully, it looks like MCP may fill that void. You can read more about Uncloud here, if I ever get around to publishing the post: [[Uncloud- A retrospective]] # Servers MCP has an analogous concept to our "adapters" from the Uncloud days—Servers. A server is, essentially an adapter to some system. It utilizes pipes (stdin, stdout) ~~rather than HTTP for communication, which I find somewhat off-putting, but it works.~~ 2025-01-08: The protocol has been updated to support HTTP, great: https://modelcontextprotocol.io/docs/concepts/transports#server-sent-events-sse Example: You want your LLM to be able to search your browsing history. MCP says that you can write a server for this. The server will be able to grab your browsing history from disk and server it up to any other process on the system that asks for it using MCP. How nice! The real power here is not strictly in being able to write such adapters—That's been possible forever. The power is leveraging the work of others, because someone has probably done it for you. This becomes more and more likely as the community grows, and luckily Anthropic has the clout to have already kickstarted the MCP ecosystem. See here: https://github.com/punkpeye/awesome-mcp-servers # Clients Of course someone has to speak MCP so that you can interact with all those nice servers others have built, which is where the clients come in. The client talks to an MCP server and, probably, sprinkles in some LLM goodness along the way so that you can interact with MCP servers conversationally. If I was to put this in terms for the general public, I would say that MCP gives your LLM new skills, like checking the weather or managing your calendar. Looking at the MCP docs it appears there is only the Claude desktop client that is a full-featured and simple LLM interface to interact with MCP servers. That will likely change, but for now you need to use Claude desktop. At least until I update [[Prompta]]. # Gotchas / Caveats As of [[2025-01-08]]: - there is no error message for a malformed request - Invalid JSON results in nothing - A method name that does not exist (akin to a 404) results in nothing - if you don't include an `id` param you get nothing - `id` can be a string too, so `"abc"` is as valid as `123`. - confirmed via the source under `.venv/lib/python3.13/site-packages/mcp/types.py`: - `RequestId = str | int` - it can even be an empty string... - Since this is all running through zod on the TS side and pydantic on the python side I suspect the SDK will expose helpful errors at some point - in the examples they define the json schema types separate from the implementation. this seems like a poor choice in practice since the schema describes the implementation (or the implementation implements the schema...) they are tightly coupled. - Using `bun` from the Python client example doesn't work... - it just hangs trying to initialize. there really should be an error. i suspect its some parsing issues. - works fine with `tsx` using the same code ```sh # This works, but if you try invalid JSON or another method # name you will get nothing echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | ./index.ts # Call a tool # The name and args come from the JSON schema echo '{"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"get-alerts", "arguments":{"state":"VA"}}}' | ./index.ts # Another tool, different args echo '{"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"get-forecast", "arguments":{"latitude":38.5,"longitude":-121.5}}}' | ./index.ts ``` --- I posted a follow up on Medium: https://medium.com/@ians/teaching-your-ai-to-do-stuff-model-context-protocol-4d4ea655fd40 --- MCP servers have: - tools - resource - prompts ??