I hit a wall with AI agents a while back. They were getting smarter at reasoning, but they were still trapped in their own little worlds. They couldn’t see my data. They couldn’t use my tools. They could write code that called APIs, but that’s not the same as actually having access.
Then I tried MCP—Model Context Protocol—and something clicked.
What MCP Actually Does
MCP is a protocol that lets AI agents connect to external data and tools. Think of it like USB for AI agents. You plug in a data source—a filesystem, a database, a web API—and suddenly the agent can actually see it and work with it.
What I found interesting wasn’t the protocol itself. It was how having this standard changed what was possible.
Before MCP, if I wanted an agent to work with my data, I had two choices:
- Copy-paste the data into the conversation
- Write custom code for each data source
Both are limiting. Copy-pasting doesn’t scale. Writing custom code means every new integration is a project.
With MCP, you register a data source once, and any MCP-compatible agent can use it. The agent discovers what’s available, figures out how to use it, and just… works.
How It Works in Practice
Here’s what my setup looks like. I have a few MCP servers running:
A filesystem server that lets agents read and write files in specific directories. I’ve restricted it to safe locations—my notes folder, some project directories. Not my whole system.
A web reader server that can fetch and parse web content. It handles the annoying parts—JavaScript rendering, authentication, rate limiting—so agents don’t have to.
A database server for a Postgres database I use for some projects. The agent can run queries, but I’ve limited it to read-only access.
When I start an agent with these servers connected, it can inspect what’s available. It discovers tools like read_file, write_file, web_reader, query. It doesn’t need to know the implementation details. It just knows these tools exist and what they do.
Why This Feels Different
The thing that surprised me was how much this changed the interaction.
Without MCP, if I ask an agent to analyze my project structure, I have to feed it file contents. Or I have to write a script that dumps the structure and pipe that to the agent. There’s this manual step every time.
With MCP, I can say “Look at my project in ~/projects/x and tell me how it’s structured.” The agent calls read_file on the relevant files, figures out the architecture, and responds.
The difference is subtle but important. The agent is doing the work of figuring out what to read. I’m not playing file manager.
Integrating MCP with Skills
The real power move came when I combined MCP with Agent Skills—Claude’s knowledge system.
Here’s what I built: An apple-writer skill that drafts articles about Apple news. The skill knows how to write articles, where to find templates, what tone to use. But the actual data fetching? That’s MCP’s job.
The workflow looks like:
- Skill has domain knowledge: how to write, what format to use, what makes a good article
- MCP provides capabilities: fetch web content, read cached articles, check database
- Agent orchestrates: uses skill knowledge + MCP tools to do the work
What I like about this separation is that each part does what it’s good at. The skill doesn’t need to know about HTTP requests or HTML parsing. MCP servers don’t need to know about article structure or tone. The agent combines them.
What I’ve Actually Built
Let me be specific about what’s working well:
Research assistant: I have an MCP server connected to my notes database. I can ask an agent with a research skill to “find everything I’ve written about X” and it actually searches my notes, synthesizes, and responds. Before, I’d have to grep through files myself or paste relevant notes into the chat.
Content processor: Another setup fetches RSS feeds, checks against a database to avoid duplicates, and formats new entries for my reading list. The skill knows how I like things formatted. MCP does the fetching and database work. I just say “process my feeds” and it happens.
Code archaeologist: An agent that can explore codebases, find patterns, and explain how things work. The filesystem MCP server gives it read access to project directories. The skill has knowledge about code architecture. Together they can answer “how does feature X actually work” better than either could alone.
The Limitations
I’ve hit plenty of edges:
Permission management is tricky. You want agents to be able to see and do useful things, but you don’t want them to accidentally delete your home directory. I’ve had to be thoughtful about what each MCP server can access. Filesystem servers are scoped to specific directories. Database servers are read-only where possible.
Agent confusion. Sometimes agents don’t quite understand what tools are available or how to use them effectively. They’ll try the wrong tool, or call a tool with bad arguments, or get stuck in a loop. Better prompts help, but it’s not solved.
Tool discovery isn’t perfect. Agents can inspect available tools, but they don’t always understand the nuance of when to use which. I’ve had to add guidance in prompts like “use the filesystem tool for local files, web reader for remote content.”
Setup overhead. Running multiple MCP servers means managing multiple processes. You need to keep them running, handle crashes, update them. There’s operational complexity.
Why This Matters
What I keep thinking about is how this changes the economics of automation.
Before MCP-style integrations, the cost of adding a new capability was writing custom code. Every data source, every API, every tool was a project. That meant most things weren’t worth automating.
Now the cost is configuring an MCP server once. After that, any agent can use it. Suddenly the math changes. Things that weren’t worth it before become worth it.
I’ve automated small tasks that I never would have written code for. “Check this RSS feed and format new entries for me.” “Look through these project files and find the configuration pattern.” “Search my notes for everything about X and summarize.”
These aren’t critical tasks. But automating them saves friction. And over time, that friction adds up.
The Bigger Picture
I think we’re seeing a shift in how AI agents fit into development workflows.
We used to think of agents as things you’d prompt to do a task, and they’d generate code or text or whatever, and that was it. But with protocols like MCP and knowledge systems like Skills, agents become something more like coworkers.
A coworker can:
- See your data (through MCP)
- Understand your domain (through Skills)
- Figure out the right approach (through reasoning)
- Execute the work (through tools)
That’s a different relationship than “AI tool that generates stuff.” It’s more collaborative. Less “I’m using a tool” and more “I’m working with something that has capabilities.”
The Hard Part
The technical parts—the protocol, the servers, the integration—are actually the easy parts. You can copy examples, follow docs, get something working.
The hard part is figuring out what’s actually useful.
Not everything should be automated. Not everything should be accessible to an agent. You have to think about:
- What tasks actually benefit from AI assistance?
- Which data sources are safe to expose?
- What guardrails do you need?
- Where does human judgment matter?
I’ve found it useful to start small. Pick one data source, one use case. Get that working. Understand the edges. Then expand from there.
If You Want to Explore
The MCP spec is open. You can find it by searching for “Model Context Protocol Anthropic.” There are example servers, client implementations, documentation.
I’d start by running a simple server—filesystem is a good one. Connect an agent to it. See what the agent can figure out on its own. Then add a second server. Watch how the agent starts combining capabilities.
The interesting moments happen when agents do things you didn’t explicitly teach them. When they combine tools in ways you didn’t anticipate. That’s when you start to see the potential.
What Changed for Me
Before MCP, I thought of AI agents as smart chatbots. They could reason, they could write code, but they were fundamentally constrained to what you gave them in the conversation.
With MCP, they’re something else. They’re entities that can navigate your actual environment. See your actual data. Use your actual tools.
That sounds like a small shift, but it’s not. It’s the difference between having a really smart assistant in a locked room, and having an assistant who can actually walk around and open doors.
I’m still figuring out what that means. What’s possible. What’s useful. What’s dangerous. But it feels like we’re moving toward AI agents that are actual collaborators, not just tools you use.
That’s the shift I’m excited about.
This reflects my early experiments with MCP and Agent Skills. The ecosystem is evolving quickly, and I’m sure some of this will feel dated in a few months. If you’re building interesting things with MCP, I’d love to see what you’re making.