Expanding AI capabilities for everyone with the Model Context Protocol
It’s been almost two years since Anthropic introduced the Model Context Protocol, an open standard to make third-party services and tools accessible to AI chat models. Recently, we added MCP support to Schemas.Pub, enabling AI models to browse, search, and share public data schemas hosted on the site. But how does it all work?
Where AI abilities come from
Most AI chat models can only generate text. If you send the message “What’s the weather?” directly to an AI model, the response will almost certainly not be helpful. By default, the model doesn’t know where you are, what day it is, or any current or predicted weather conditions for any location. It might hallucinate conditions, or hopefully reply that it can’t help with your request. So how do chatbots like ChatGPT and Claude manage to answer these requests helpfully, not to mention edit files, search the web, and all the other things AI agents are being used for today? The answer lies with the program used to run the model.
When you chat with an AI model, you use an interface like a website (chatgpt.com, claude.ai, gemini.google.com, etc) or an app on your device (Claude Code, Claude Desktop, ChatGPT Work, Codex, etc). Most of these interfaces do much more than just forward your message to the model and show you the response. They also inject additional text as context for your message.
For example, when you send “What’s the weather?” a chatbot interface might add context like, “The user is located in New York City. The date is Monday, September 14, 10:18 AM.” Many interfaces also include a list of “tools” available, which represent software designed to be invoked by the AI model. Modern AI models have been trained to watch for available tools and respond with special text to invoke them. Tools are advertised to the model along with other context, like in this simplified example:
The user sent: "What's the weather?"
The user is located in New York City. The date is Monday, September 14, 10:18 AM.
You have access to tools you can use to answer the user's question:
Tool: Weather search
Description: Search for weather conditions for the provided location (city, state, country)
Use: Respond with "search_weather(<location>)"
If the model wants to use a tool, it’s been trained to respond with special text, along with any data necessary to use the tool.
In this example, it might respond with something like, “<invoke_tool>search_weather("New York City")</invoke_tool>.”
The chatbot interface intercepts this response, and rather than showing it to you, performs a weather search for New York City.
The results of that search are sent back to the model, which can finally respond to your original “What’s the weather?” message based on actual weather data.
This is how AI models actually do stuff, but there’s two problems:
- With so many different chatbot interfaces (we listed 7 above and barely scratched the surface!), how can third-party service providers sustainably create integrations for them all?
- More importantly, how can users and service providers actually add the integrations they want to use without relying on the interface developers?
As we’ll see, the Model Context Protocol is designed to help with both.
The Model Context Protocol
The Model Context Protocol is an open standard for integrating custom tools into AI chat interfaces. It defines a client/server relationship and communication protocol which enables AI chat interfaces to provide models with access to external services and tools.
Most popular chat interfaces can already act as MCP clients, including claude.ai, Claude Code, Claude Desktop, ChatGPT work, Codex, and many more. Organizations and software developers can create MCP servers for their services to make their functionality accessible to these clients. For example, GitHub has created an MCP server to allow AI models to interact with its services. Users can add any MCP servers they like to whichever MCP clients they use to give AI models new functionality.
MCP clients handle getting a list of tools and instructions for their use from MCP servers, according to communication specified by the Model Context Protocol. The clients then include that information along with a user’s messages to the AI chat models, just as they would with the “weather search” tool in the previous example. If the MCP client detects an invocation, it again communicates with the MCP server according to the MCP specification. When the server recieves the request, it runs whatever code the server’s developers wrote for the requested tool, and returns some response back the the MCP client. That response is usually sent back to the model, just like in our weather example. MCP even defines optional authentication methods, allowing AI models to access data and take actions using the user’s authorization.
Since MCP is just a protocol definition, MCP client and server developers simply need to implement their respective sides of the relationship according to the MCP specification to make their software work together. Offical code libraries exist to aid developers in making their software compatible with MCP. During our development of the Schemas.Pub MCP server, these libraries allowed us to mostly skip thinking about the details of the protocol and instead spend our time on the actual functionality we wanted to make accessible to AI.
MCP and personal data
While our work adding MCP support to Schemas.Pub focused on public data, the experience helps us understand MCP’s potential for personal data. Companies have already added support for managing personal data through MCP, and we’re especially interested in exploring if MCP can facilitate personal data portability between services. It may be possible to transfer personal data between services by connecting AI agents to the services’ MCP servers, then instructing the agents to copy data from one service to another.
That said, providing AI agents with personal data management capabilities also involves privacy and safety considerations. It may add AI service providers as another party with access to personal data. Additionally, AI agents have potential to mishandle personal data, especially if influenced by malicious attacks such as prompt injection. As MCP adoption increases, navigating these risks will be essential to ensuring the technology empowers users without compromising the privacy and security of their personal data.
The Model Context Protocol is an example of the power of open standards. MCP enables independent developers to build interoperable software which gives users the freedom to extend AI model functionality through the interfaces and services they choose. This aligns well with our fourth guiding principle for AI calling for “open processes” when AI services communicate with other services.
We wanted to help empower AI-assisted users who may not have coding experience to take advantage of the portable data schemas on Schemas.Pub. By supporting MCP, we only had to write one AI integration, which saved us a significant amount of time. And yet, our single integration serves the maximum number of AI chat interfaces we could practically support, meaning users get to choose whichever compatible client they like. This exemplifies how open standards like the Model Context Protocol can be beneficial for everyone.