I had been seeing “MCP” everywhere and I had no real idea what it was.
That’s not a comfortable admission for someone who teaches API documentation in the age of AI tools. I know what protocols are. I know what servers are. I’ve been connecting systems to other systems for a long time. And yet every time I read an explanation of MCP, something wasn’t clicking.
So, I built one.
Why reading about it wasn’t enough
The official description is accurate: MCP is the interface for an AI tool to connect to other services. The analogies help too. The official description compares it to USB-C for AI, a universal adapter that lets any model plug into any tool or data source without custom wiring for every combination.
All of that is true, yet none of it helped make it feel real to me.
I realized that I had the same experience with the Internet of Things (IoT) six years ago. I’ve spent years connecting devices to computers, but IoT, literally connecting devices to computers over the Internet, left me scratching my head. Leaning into my hands-on learning style, I built a couple of IoT applications and went on to write API documentation about the AWS IoT service for a couple of years.
As with my IoT experience, to get to the bottom of this MCP mystery, I needed a problem to solve. And there it was, right in front of me (and it’s right in front of you, too): my website.
My website has an API and 169 articles that I’ve published with no easy way to analyze how they connect to one another. I was curious whether an MCP server could help. That seemed like a safe place to start (read-only access, real data, actual use case) and concrete enough to move from theory to something running on my laptop.
I asked Claude what a content-focused MCP server could do with a site like mine. The ideas came back quickly in a list of things that normally require manually exporting the data or writing a one-off script to pull it out.
- Content graph analysis
- Gap identification
- Cross-reference suggestions
- Tag and category hygiene.
With an MCP server, these become tools Claude could call during any conversation.
This is getting interesting. An MCP server could add data from my website to a Claude conversation.
Time to get hands-on.
Let’s build one
I’ve done enough coding projects with, and without, Claude to know that incremental development is the only sane way to do them. Build the smallest thing that works, verify it, then add the next layer. Lather. Rinse. Repeat. Debugging a system with five moving parts is miserable. Debugging one moving part at a time is just working.
Claude sketched a seven-phase roadmap:
- Install Claude Desktop
- Build a minimal “hello world” MCP server (one tool, no real functionality)
- Add a connection to my website and verify authentication
- Add content retrieval tools
- Add basic connection analysis
- Build a full content graph
- Add draft integration for cross-reference suggestions while writing
Each phase had a clear deliverable that could be tested before moving on. This is a design habit that has saved me countless hours in the past. I know this from the hours I’ve wasted by not following it.
Phase 1 was trivial. I already had Claude Desktop installed.
Phase 2 is where things got interesting. Getting Python configured correctly on my machine took longer than expected and getting Claude to successfully call the minimal server took longer still. Log files held the secrets to both.
The “hello world” phase isn’t just scaffolding. It’s where you find out what’s broken before the real complexity arrives. If I’d skipped straight to website integration, I’d have been debugging three things at once.
Phase 3 connected the MCP server to my web server. I added the necessary security keys (not to my GitHub repo, of course). Unfortunately, the first attempt failed because Claude added a new import to the server code without mentioning it, and without me catching it in the diffs. Running the server from the command line before handing it over to Claude would have caught that immediately. Another lesson learned for next time.
Phase 4 added richer content retrieval: posts by date, by category, with excerpts or full content. This attempt worked the first time, which felt suspicious, so I tested several variations before moving on, which were also successful.
This phase is where I hit the first conversation limit on the project. Regrouping to continue in a new conversation gave me time to reflect on a useful practice: identifying tasks the MCP server should handle locally, saving AI tokens for the work that needs them. After a quick chat, Claude suggested converting the HTML to Markdown locally for faster content processing and we added the html2text Python library to the MCP server.
Phase 5 was supposed to add connection analysis, but we’d already built some of that in Phase 4. Claude recognized the drift and adjusted the roadmap rather than forcing the original structure. Plans are hypotheses. The code is the experiment.
Reviewing the results of the analysis delivered an uncomfortable finding. Claude really wanted to work with tags to identify topic relationships. I don’t tag my posts. So, the connections it found were purely category-based, which just confirmed that posts in the same category are related. Not exactly a revelation. Tagging my posts is now on the roadmap.
Phase 6 built the full content graph. Claude provided a command-line test script to verify the tool before exposing it through the MCP interface. This is a pattern to carry forward: test the component, then test the integration. Unit tests. What a concept.
The graph analysis worked, and delivered its verdict on my tagging situation with the patience of someone who had already made this point. Twice.
Zero tags across all posts means connections are purely category-based. Posts with unique category combinations have the fewest connections (bottom 10 have 2-9 connections vs. 116+ for the majority).
Message received.
After about three hours, including reheating leftovers, I pushed the code to GitHub and called it a night.
What clicked when it was running
Once I saw the server working, MCP made sense. An MCP server is middleware: a layer that handles the translation between two systems that weren’t built to talk to each other. Claude on one side, my web server on the other, and my Python server in the middle brokering the conversation.
That’s not a new idea. Service buses, API gateways, integration layers. The pattern has been around as long as there have been systems worth connecting. MCP is the pattern that is standardized for AI tools, with a spec that any model or client can implement.
I don’t say that to diminish it. Standardization is genuinely valuable. Before MCP, every AI tool that wanted to connect to external data needed its own custom integration. MCP collapses that into a common protocol, which is why adoption has been so fast.
But understanding what it is only came from building one. The abstractions didn’t land until I had something running. Seeing the interfaces in action brought everything into focus.
What happened after October
This build session took place in October 2025. Now, in February 2026, MCP looks less like an interesting experiment and more like infrastructure. OpenAI adopted it across their Agents SDK. Google DeepMind confirmed support in Gemini. Anthropic donated the specification to the Linux Foundation in December. There are now over 10,000 active MCP servers with first-class support in Claude, ChatGPT, Cursor, Gemini, and Visual Studio Code.
The fog that surrounded the term in October has largely lifted, not because the explanations got better, but because there are now enough implementations that people can see what it does.
Which is the point. If MCP still feels abstract to you, the fastest path through the fog isn’t a better article. It’s building something small.
The real takeaway
There’s a pattern to how new technology gets named and described. The terminology is promoted before the mental models can take shape, which means a lot of people spend time feeling like they’re missing something obvious. Sometimes they are. More often, the fundamental concept is straightforward but the jargon is just young.
MCP is genuinely useful. The adoption numbers aren’t hype. But the concept underneath it is more approachable that it might seem at first (or fourteenth) glance. For me, the fastest way to see what made it tick was to build a small one and watch it work. You, too, should be able to ask your favorite AI tool to help you build your own MCP server and see for yourself.
That’s what a three-hour conversation with Claude and a Python server taught me that the documentation hadn’t. And that I should tag my content. Apparently, that’s important, too.