Finally managed to connect my MCP Servers
(aka: the season finale)
You’re reading this on a Tuesday morning, but let’s be honest: I’m usually writing it in a caffeine-fueled haze around 9 or 10 PM on Mondays. Why mention this? Because last Wednesday was Kernel’s demo day, and I had grand plans: an interactive trivia game where two different MCP servers would talk to each other, generating a Web3-themed battle of wits. The MVP made it to the finish line, but the “two servers, one dream” part? Not so much. My last-minute fix was to connect the open-source database to a Telegram Bot- good enough for the demo, but not quite the server-to-server magic I’d envisioned. That missing piece finally snapped into place today (Monday), about 30 minutes ago. Cue the dramatic music.
This whole process has been a masterclass in iteration, frustration, and learning how to wrangle copilots-sometimes by just ignoring them. Fun fact: the final tweaks and bug fixes that got everything working? Done solo, no copilot. Does this mean I’ve finally graduated as a developer? (Insert laugh track here.)
There’s a universal law in coding: things that should “just work” will only do so at the last possible second, usually after you’ve sacrificed sleep, sanity, and at least one keyboard. Is it the tools? Is it my brain? I have no idea, so let’s move on to what I actually learned.
Copilots: Helpful, but Also a Bit… Selective
Today, I spent most of my day trying to connect these two servers, starting from scratch-because, apparently, my copilot didn’t absorb any of my previous training. Over the past week, I ran a series of experiments with Windsurf, trying to hard-code best practices and work around the mysterious “limitations” copilots claim are baked into their default settings.
Here’s what I discovered:
Copilots don’t lie, exactly-they just optimize for efficiency, which means they’ll serve you the “closest” answer, not necessarily the right one. If you ask about memory from previous conversations, expect a best guess, not a perfect recall.
Security setups can block your copilot from following instructions step by step, so it improvises. Sometimes that works. Sometimes you get a Picasso instead of a blueprint.
I asked Windsurf to build a table of capabilities, resources, features, and system security policies to walk me through every issue while developing the bot and connecting the servers. It was… enlightening. You can check out the tables if you’re into that sort of thing.
This is a set of prompts I threw at Windsurf to create the templates and PRD:
Define the “activation moment” of a Junior Developer using a Copilot.
List the “Jobs to be Done” for a Junior Developer with a Copilot.
Break each job into a modular PRD (Product Requirements Document).
Use top-rated GitHub repos as context,
Then generate documentation and schema templates for defining a project with a copilot-including normalization of variables, methods, tools, libraries, you name it.
I ended up with a collection of templates: one for supposed best practices, two from failed projects, a comparison doc, and a couple more for payment rails (including ERC-20 + Arbitrum). In the end, I couldn’t get the copilot to connect backends and endpoints reliably. What worked was rolling up my sleeves, reading the docs, and fixing things by hand. Shocking, I know.
If you want to see the repo of failed experiments, it’s all there-warts and all.
So, What Actually Worked?
I’m happy to report that most of my MCP server adventures have been successful. They’re surprisingly easy to set up, and the documentation is actually readable (a rare treat). I’ve used four major MCP repos so far, all Python-based and Python-friendly: two for the Python SDK and FastAPI, and two focused on my own tools- Open Sourced Observatory MCP, and the new favorite, ttaat (Two Truths and a Twist). The idea: use OSO as the data source and ttaat as the logic engine. Here are two working examples (links in the repo). Example 1 and Example 2.
Once I actually read the documentation, the copilot’s job was relegated to writing a few repetitive scripts. I didn’t let it anywhere near the primary logic.
Key Takeaways (a.k.a. “What I Wish I’d Known Last Week”)
Read the documentation. Seriously. The copilot is just that-a copilot. You’re still the pilot.
Think like a project manager: break everything into small, modular steps.
Keep a control log.
Test each module.
When you finish a module,
set a milestone and have a fallback plan.
Don’t let the copilot debug. It just can’t.
Random hack: if one copilot can’t fix something, give a screenshot of the issue to another copilot. Sometimes, that actually works.
Coming Soon:
How I finally fixed the TG bot (hint: it needs to connect to a Jupyter Notebook, not a raw database).
Launching the bot into production.
First attempt at building a voice assistant with Mastra.
Launching the voice assistant through Gumroad.
If you have been reading my Substack for a while, you know is all about curiosity, talking about the latest tools framed by AI/Web 3 because let’s face it are the most relevant technological shifts of this decade. It is all about building bridges between technical and non-technical audiences. The future belongs to builders, and this is my journey learning how to build-sometimes with copilots, sometimes despite them.