Model Context Protocol: Beyond Desktop Applications
Everyone’s talking about Model Context Protocol, but most discussions miss the point. Yes, you can use it to add AI features to desktop applications. But if you’re building production agentic AI systems, MCP solves a much bigger problem.
The USB-C analogy floating around? Not helpful. Let me show you what MCP actually does and why it matters.
The Core Problem
Start with how an LLM works from the outside. You send a prompt, you get words back. That’s fine if words are all you need.
But agentic AI needs to do things. It needs to invoke tools, take actions, cause effects in the world. It also needs access to current information beyond what’s baked into the foundation model - enterprise data, real-time events, external APIs.
You might be using RAG to bring enterprise data into context. That’s not old news, despite what some people claim. In enterprise environments, RAG patterns work well. But whether you use RAG or not, you still face the same challenge: getting external resources and tools into scope for your agent.
These resources could be anything - files, databases, Kafka topics, third-party APIs. The agent needs awareness of them, and it needs the ability to use them.
How MCP Works
Think of MCP in terms of basic microservice architecture. Nothing exotic here.
You have a host application - your agent service. It uses the MCP client library to create a client instance.
On the other side, you have an MCP server. This could be an existing server someone else built, or one you’re writing yourself. The server exposes tools, resources, and prompts through well-defined RESTful endpoints described in the MCP spec.
The server implements a capabilities endpoint that tells clients what’s available - which tools exist, what resources can be accessed, what prompts are provided.
The connection between client and server works two ways. You can use standard IO for local processes (common in desktop app examples). For production systems, you use HTTP with server-sent events. Messages are JSON-RPC.
The protocol includes client-server handshaking and supports asynchronous notifications from server to client. It’s a reasonably rich communication setup.
A Concrete Example
Say you’re building a service for scheduling meetings - coffee with a colleague, breakfast with a client, dinner with your spouse. Think about what that requires:
Tools you need:
- Create calendar invites
- Make restaurant reservations
- Send notifications
Resources you need:
- Your calendar availability
- Maybe the other person’s calendar (if you have permissions)
- Nearby restaurants and coffee shops
- Business hours and reservation systems
You could bake all this into your agent directly. Write the calendar integration, talk to Yelp’s API, handle everything in your codebase. But then it’s locked in there. Nobody else can use those capabilities without copying your code.
With MCP, you put those capabilities in a server. Here’s how it works in practice.
The Workflow
A user sends a prompt: “I want to have coffee with Peter next week.”
The LLM alone can’t help. Who’s Peter? Where? When?
But your agent can ask the MCP server: what capabilities do you have? The server returns a list of available resources with descriptions.
Now your agent can send a modified prompt to the LLM: “Here’s what the user said. Here are the available resources. Do I need any of them?”
The LLM responds: “Yes, get me the list of coffee shops in the area.”
Your agent requests that specific resource from the MCP server, gets the data back, and includes it in the next prompt: “Here’s the user request. Here’s the coffee shop data. What should I do?”
For tools, the process is even cleaner. Modern foundation model APIs let you pass tool descriptions as structured data - the tool name, URL, parameter schema. The API will tell you which tool to invoke and with what parameters. You don’t write parsing code for any of this. The LLM handles it.
The models won’t actually call the tools themselves (that would be Skynet territory). They’ll tell you what to invoke, and your client code makes the decision - maybe asking the user first, maybe not.
Why This Matters
Instead of hardcoding capabilities into your agent, you get three key benefits:
Pluggability: Register new MCP servers and your agent gains new capabilities without code changes.
Discoverability: The agent doesn’t need to know what tools exist ahead of time. It asks and finds out.
Composability: MCP servers can themselves be clients of other MCP servers. Need to consume from a Kafka topic? Your custom MCP server can use Confluent’s MCP server as a client.
Say you have data in Kafka. Rather than writing Kafka integration code in your server, you make your server a client of Confluent’s MCP server. You get access to that Kafka topic through composition.
This is how you build production agentic AI systems. Not desktop app enhancements - real enterprise infrastructure.
The Enterprise Context
At AlienGiraffe, we built data infrastructure for security systems. The integration problem was constant - connecting different data sources, making them available to analysis tools, keeping everything discoverable as the system grew.
MCP solves that same class of problem for AI agents. Instead of building monolithic agents with everything baked in, you build modular systems where capabilities can be added, discovered, and composed.
The technology choices - JSON-RPC, server-sent events - might raise eyebrows. But they work, and they’re what we have. The protocol is straightforward enough that you can implement a server in an afternoon.
Getting Started
Pick a capability your agent needs. Build an MCP server that provides it. Make the resource descriptions clear - the LLM uses those to decide what to fetch.
Register the server with your agent. Let the discovery process work. Watch your agent gain new abilities without you writing integration code in the agent itself.
The broader vision here isn’t about making desktop apps smarter. It’s about building enterprise AI systems that can grow, adapt, and compose capabilities the way we’ve learned to build microservices.
That’s worth paying attention to.
Questions to consider:
- What capabilities in your current system could be modularized as MCP servers?
- Where are you currently hardcoding integrations that could be discovered dynamically?
- What would composable AI capabilities unlock in your infrastructure?