The current state of AI agents is a mess of fragmented integrations. Every time I want to give an LLM access to a new data source or a specific tool I find myself writing custom glue code that breaks the moment an API version changes. It is a frustrating cycle of building brittle wrappers. We are effectively forcing highly intelligent models to peer through a keyhole when they should have a wide-open window into our data ecosystems.
This fragmentation creates a massive technical debt for developers. You spend eighty percent of your time on plumbing and maybe twenty percent on the actual intelligence of the agent. Without a unified way to share context the model often hallucinates because it lacks the grounding of real-time data. It is stuck in a loop of “I don’t have access to that” or worse “I’ll guess what that data looks like” — which leads to unreliable outputs and a poor user experience.
The Model Context Protocol (MCP) changes this dynamic entirely. It is an open standard that allows me to build context-aware agents that connect to any data source using a universal language. By standardizing how servers and clients communicate I can focus on building sophisticated logic rather than managing endless API endpoints. It is the missing link in the agentic workflow.
Why MCP matters for developers
I have spent years building custom web applications and one of the biggest hurdles has always been data silos. When I work on complex technical challenges the goal is usually to make data actionable. Traditional tool-use requires the developer to define every schema and every function call manually for the model. MCP flips this script.
MCP acts as a bridge. It defines a clear boundary between the AI application (the client) and the data sources (the servers). This separation of concerns means I can swap out the underlying model without rebuilding the entire data integration layer. If I move from Claude to another model that supports MCP, the tools and resources remain the same.
It also solves the “context window” problem. Instead of stuffing a massive document into the prompt I can expose it as an MCP resource. The model only fetches what it needs when it needs it. This is significantly more efficient and cost-effective. It allows me to build agents that are aware of their environment without being overwhelmed by it.
The three pillars: tools, resources, and prompts
To understand how to build with MCP I look at its three core primitives. These are the building blocks for any context-aware system.
- Tools are model-controlled actions. When I give an agent a tool I am giving it the ability to change the world. This could be writing a file to a disk or making a POST request to a Shopify API. The model decides when to call the tool based on the user’s intent.
- Resources are application-controlled data. Think of these as read-only files or database entries that the agent can inspect. Resources provide the necessary grounding. If I am building a support agent the documentation for the product would be a resource. The agent can search and read it to provide accurate answers.
- Prompts are user-controlled templates. They help guide the interaction. By using MCP prompts I can standardize how users interact with the agent across different platforms. It ensures consistency in how the model interprets tasks.
Building your first MCP server
I prefer using TypeScript for building MCP servers because of the robust SDK provided by Anthropic. However the protocol itself is language-agnostic. Here is a simplified look at how I structure a basic server that exposes a weather tool.
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
CallToolRequestSchema,
ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
const server = new Server(
{
name: "weather-server",
version: "1.0.0",
},
{
capabilities: {
tools: {},
},
},
);
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: "get_weather",
description: "get the current weather for a location",
inputSchema: {
type: "object",
properties: {
location: { type: "string" },
},
required: ["location"],
},
},
],
};
});
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "get_weather") {
const location = request.params.arguments?.location;
// logic to fetch weather from an api goes here
return {
content: [{ type: "text", text: `it is sunny in ${location}` }],
};
}
throw new Error("tool not found");
});
const transport = new StdioServerTransport();
await server.connect(transport);This snippet illustrates the simplicity of the protocol. I define the tool and how to handle the call. The MCP client handles the rest. This modular approach is exactly what I look for when managing cloud infrastructure or complex backend systems. It is clean and scalable.
Security and the MCP ecosystem
Security is a major concern when giving an AI agent access to your data. I have seen many implementations where API keys are hardcoded or permissions are too broad. MCP addresses this by using a client-server architecture where the server controls exactly what is exposed.
The server acts as a gatekeeper. I can implement fine-grained access control at the server level. For example an MCP server connecting to a database can be restricted to only specific tables or read-only queries. This level of control is essential for enterprise-grade applications.
The ecosystem is growing rapidly. We are seeing early adoption from major players in the dev tools space. Tools like Zed, Cursor, and Claude Code are already integrating MCP to help developers write better code by giving their AI assistants better context. This trend will only accelerate as more developers realize the power of standardized context.
Practical steps for getting started
If you are a developer looking to dive into MCP I recommend following these steps.
- Explore the existing MCP servers on GitHub. There are already servers for file system access and SQLite databases. See how they are structured.
- Pick a simple data source you use every day. It could be your Obsidian notes or a local directory of markdown files. Build a basic server to expose these as resources.
- Use a client like Claude Desktop to test your server. See how the model interacts with your data. Adjust the tool descriptions to make them more intuitive for the AI.
- Compose multiple MCP servers once you are comfortable. Imagine an agent that can read your calendar and then write a draft email based on your upcoming meetings.
MCP is more than just a new protocol. It is a fundamental shift in how we build AI applications. It moves us away from the era of “black box” agents and toward a world of transparent and context-aware assistants. I am excited to see how this technology evolves and how it will transform our development workflows.
How are you planning to use MCP in your next project? Drop me a line — happy to swap notes on real-world MCP server design.
