With my time currently at my own discretion, I wanted to really get a grip on Anthropic’s Model Context Protocol (MCP), since it’s taken AI Engineering by storm. MCP was only introduced in November of 2024. It really started flying across my radar around March or so, and now seems omnipresent.
Key Takeaways
The core kernel of the MCP Server model (tools, resources, and prompts accessible via a JSON-RPC API serving subprocess via stdin/stdout) is quite accessible, compelling, and applicable. Claude Desktop integration makes MCP servers, off the shelf and custom developed, immediately useful. Expansion to many other applications, including ChatGPT, just solidifies the utility. The value proposition is clear.
Go beyond that tight core and the payoff is not quite as obvious. Patterns for MCP Clients don’t feel as numerous or polished. The promise of remote MCP servers, instigating a confusing passel of network transports combined with AuthN/Z issues, seems headed for an enterprisey morass. I understand the utility of an MCP Client supporting samples but it’s a hard feature to wrap one’s head around. Roots seems prone to foot gunning.
To solidify my understanding, I’ll be doing some prototyping with basic MCP Server capabilities. FastMCP looks like a well-designed foundation for getting started. Plugging into Claude Desktop and ChatGPT should be fun, but I’ll also be on the lookout for terminal CLI frameworks to work with just because I’m a REPL and terminal sort of guy. Also, Python + FastMCP + uv + (Docker | podman) can support rapid development, packaging, and deployment with good isolation. Don’t even have to buy into the Docker MCP Toolkit.
The previous section was also posted to my LinkedIn feed.
Deeper Dive
Here’s the definition of MCP, straight from the horses mouth:
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.
Using MCP, AI applications like Claude or ChatGPT can connect to data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows (e.g. specialized prompts)—enabling them to access key information and perform tasks.
Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.
MCP is inspired by Language Server Protocol (LSP), a JSON-RPC based standard that supports intelligent code services within integrated development environments (IDEs). At first MCP’s choice of JSON-RPC as a foundation for RPC confused me but the connection with LSP clarified things. This also helps explain the canonical approach of launching an MCP server as a local subprocess of the hosting AI app.
The minimal useful core of MCP has three key concepts:
- tools, descriptions of available callback invocations for LLM tool usage
- resources, named content to be added to LLM contexts
- prompts, canned prompts for direct feeding of LLMs
On the more advanced end of MCP deployment you have
- sampling, let’s the MCP server proxy LLM interactions back through the MCP client
- logging, a mechanism for an MCP server to notify the client of updates.
- roots, management of filesystem access by the client.
- elicitation, enables the server to make interactive requests of the actual user
- “remote” processes and alternative transports, instead of running an MCP server as a direct subprocess client, the client connects using network transports like StreamableHTTP
Most of these extra features make surface sense, but upon further inspection tickle my complexity spidey sense. For example, sampling seems like a reasonable feature, but then the MCP spec doesn’t provide much guidance about security considerations for sampling. Here be dragons.
Pics, cause it happened:
