Terry-Level MCP Development
Building Mutual Intelligence That Earns Trust
🔐 Recap: Part 1 taught us 30 years of security lessons
🚀 Recap: Part 2 showed MCP’s 8-month speedrun to everywhere
🔧 This Part: How to build context-aware systems the right way
Here’s what 30 years of SSL/TLS disasters taught us that MCP developers need to know:
Don’t repeat history. SSL 1.0 was broken. SSL 2.0 was broken faster than a politician’s promise. TLS 1.0? Also broken. Each time, smart people thought they’d patched the holes, but they were building on quicksand.
MCP got it right in 8 months because it learned from those mistakes. But here’s the thing - you have to learn from them too.
Terry-Level Craftsmanship
I once had the honor of working for a very talented Upholsterer/Tucker. A lot stands out, but I remember how when he was working on priceless (to me) convertibles - he would meticulously lay out a spotless, soft cover on the trunk, lay out his tools and plan his work.
Everyone that knew Terry would say Terry was ‘their guy’ - and not in a ‘knows a guy who knows a guy’ way, but in a ‘this is the craftsman you trust with your baby’ way. He was experienced, thoughtful, meticulous and most of all, he seemed to know what he didn’t. Don’t get it twisted - I’m saying the guy knew his limits, consulted manuals/others/took his time and then gained the context he needed. Sometimes that context was “it’s someone else’s problem”, other times it was “need help”, other times it was “waiting for parts”, sometimes he just “needed more time”.
Unlike those SSL developers who kept patching holes for decades, Terry understood the whole system before touching anything. That’s the difference between craftsmanship and “ship it and see what breaks.”
You owe it to every Tom, Dick and Eric - every Harriet, Grace, GitHub dev, keyboard hero, nameless contributor who spent decades fixing the web’s security disasters.
The Five Principles of Mutual Intelligence
For the love of all things, when you build your MCP servers:
1. Give Them Proper Context
Not just data dumps, but meaningful descriptions of what they do and when to use them.
Bad: “Database connector”
Good: “PostgreSQL query executor for development and staging environments. Handles read-only analytical queries with automatic query timeouts and connection pooling.”
Your MCP server should explain itself like Terry explaining which tool he needs for which part of the job.
2. Test Your Edge Cases
SSL kept breaking because nobody thought about the weird scenarios.
What happens when:
- The database is down?
- The user has no permissions?
- The input is malformed?
- The network connection drops mid-query?
Terry would never start a job without checking his tools worked properly. Neither should your MCP server.
3. Document Clearly
If Terry had to guess what tools he needed, your convertible would look like shit.
Write docs like you’re explaining to Terry’s apprentice:
- What does this server do?
- When should I use it?
- What does it need from me?
- How does it connect to other tools?
- What could go wrong?
4. Think Security First
Don’t ask for passwords in elicitation (seriously, don’t be that person).
Security by design:
- Never ask for credentials through forms
- Validate all inputs
- Rate limit requests
- Log security events
- Fail safely
5. Know Your Limits
Terry knew when to say “it’s someone else’s problem”.
Your MCP server should:
- Gracefully handle what it can’t do
- Point users to better alternatives
- Fail fast with clear error messages
- Never pretend to be something it’s not
Advanced MCP Features That Matter
Here’s some cool MCP features you might like - maybe they’ll spark your next MCP Server/Client/Combo.
Roots: Context Awareness
Roots are something that the “Client” advertises to the “Server”. Let’s say you’re doing something with a server and it needs to know what’s available.
For example, what project do I have open in my editor/IDE/Blender/etc? Maybe you have a time tracker widget that you update with which project you’re working on. When you change it, your MCP Clients automatically tell the MCP Servers what new list of “resources” are available.
Maybe I run Aider or another client and when I ask it to do something, the MCP client tells the MCP Servers where to target its code search/knowledge base tools.
You could have an MCP server setup that changes the roots on all your active clients.
Elicitation: Smart Questions
Not that kind of MCP server! Haha - Elicitation, although hard to spell and fun to say, opens some unimaginable possibilities.
Think of it like this: you’ve given your MCP servers the ability to raise their hand and ask you questions. Not just any questions - structured ones.
Imagine your MCP server is like a smart assistant that needs clarification:
- “Hey boss, which database should I connect to?” (dropdown: prod, staging, dev)
- “What format do you want the report in?” (multiple choice: PDF, CSV, JSON)
- “Should I include archived records?” (yes/no toggle)
- “How many results do you want?” (number field: 10, 50, 100, all)
You get a nice form popup, and you can:
- Accept: “Here’s your answer, now get to work!”
- Reject: “Nope, not doing that right now”
- Cancel: “Forget I asked…”
The cool part? After you accept or reject, the server might come back with another question. Maybe you said “prod database” but forgot to specify the region. Or maybe you entered an invalid number and it’s giving you another shot. It’s like a conversation, but with forms instead of freeform chat.
Now here’s the important bit - these servers can’t just ask for your passwords or secrets. That’s a big no-no. The whole system is designed to be transparent about who’s asking for what, and you always have the power to say “nah, I’m good” and cancel out.
The Security Fine Print (That Actually Matters)
Since we’re building on solid foundations (remember that whole SSL/TLS journey?), elicitation comes with built-in guardrails. We spent 30 years learning these lessons the hard way - Heartbleed, BEAST, POODLE - so let’s not repeat them:
- No sketchy questions: Servers literally CAN’T ask for passwords, API keys, or your mother’s maiden name
- You see who’s asking: Like caller ID, but for your MCP servers - no anonymous requests
- Reject button always works: Don’t like the question? Slam that reject button. No explanation needed
- Schema validation: Both sides check that the questions make sense - no asking for your shoe size in a database field
- Rate limiting: Your servers can’t spam you with 1000 questions per second (looking at you, chatty database connector)
- Clear requests: No vague “gimme data” - you see exactly what they want and why
Real talk though: When I say “CAN’T”, I mean “SHOULDN’T” - like really, really shouldn’t. Just like Terry wouldn’t use duct tape on a Corvette’s upholstery, a good MCP craftsperson won’t ask for your passwords through elicitation. The protocol gives you the guidelines, but it’s up to the developer to not be that person who ruins it for everyone. Don’t be the reason we need MCP 2.0 with mandatory security enforcement, ya know?
Basically, it’s like having a well-trained assistant who knows the boundaries and respects them. Way better than the old days of “just put your credentials in this sketchy config file and hope for the best.”
I’m launching a simple framework, on top of FastMCP that makes elicitation easier than getting a targeted ad for something you just whispered about, or cracking a ’90s password.
MCP Matryoshka Dolls: Servers All the Way Down
MCP is so composable! Servers can be clients and vice-versa. Think about an MCP server in front of your MCP server…
Remember those rabbits we couldn’t count? Turns out they’re all connected - and that’s the beauty of it. Just like MCP provides context between tools, these architectural patterns provide context between systems.
Imagine:
- MCP gateways that route requests based on context
- Security layers that validate every tool call before it hits your production systems
- Multi-tenant MCP architectures where each client gets their own isolated server cluster
- Dynamic service discovery where MCP servers find and compose other MCP servers at runtime
What about:
- MCP-to-legacy protocol bridges?
- Performance optimization layers that cache and batch requests across multiple backend servers?
- Cross-organizational MCP federations where companies can securely share tools without exposing internals?
The rabbit hole goes deep. Enterprise customers are already asking about things that don’t exist yet - MCP load balancers, audit trails for compliance, circuit breakers for when upstream servers go haywire.
Building Trust Progressively
Just like human relationships, Mutual Intelligence builds trust progressively.
Traditional AI: “Give us all your data upfront so we can help you better”
Mutual Intelligence: “Let us earn your trust progressively, and we’ll protect your context like sacred responsibility”
Progressive Context Disclosure
🌍 Public Context → 📋 Earned Access → 🛡️ Sacred Trust Immediate → 10+ interactions → Unwavering loyalty
Start with what’s safe to share. Prove your value. Earn deeper access over time. Never betray that trust.
The Real Moral
Go forth and craft your MCP servers with care. I’ve been inspired by many craftspeople across many disciplines (I don’t use that word lightly). Think about your own personal experiences - that perfect meal, beautiful furniture, zip-tie hack that’s just right…
The web took 30 years to get security mostly right. MCP gives us the chance to do it right from the start. Don’t waste it building the digital equivalent of a Home Depot deck that collapses when someone sneezes.
Build something Terry would be proud to put his name on.
Mutual Intelligence Patterns
Here are some battle-tested patterns for building context-aware systems:
The Terry Pattern: Plan Before You Touch
- Understand the whole system before making changes
- Lay out your tools (what MCP servers do you need?)
- Plan the work (how do they connect?)
- Test everything before going to production
- Document for the next person
The Progressive Trust Pattern
- Start with public data (GitHub repos, public APIs)
- Prove your value (10+ successful interactions)
- Earn sensitive access (internal databases, private repos)
- Maintain sacred trust (never leak, never abuse)
The Graceful Failure Pattern
- Expect everything to fail (networks, databases, users)
- Fail fast with clear messages (“Database timeout, try again”)
- Offer alternatives (“Try the read-only version?”)
- Log for debugging (but not sensitive data)
The Context Flywheel Pattern
- Each interaction teaches the system about your preferences
- Better context enables better tools (more relevant suggestions)
- Better tools encourage more use (positive feedback loop)
- More use generates better context (flywheel effect)
Common MCP Antipatterns to Avoid
The Password Phisher
// DON'T DO THIS
{
"type": "text",
"name": "password",
"description": "Enter your database password"
}The Black Box
// DON'T DO THIS
{
"name": "database-thing",
"description": "Does database stuff"
}The Kitchen Sink
// DON'T DO THIS - one server trying to do everything
{
"tools": [
"database_query", "send_email", "deploy_code",
"order_pizza", "launch_missiles", "pet_cat"
]
}The Chatty Cathy
# DON'T DO THIS - spamming the user
for i in range(1000):
await request_user_input(f"Question #{i}")The Future We’re Building
If you smell what I’m 👨🍳 cooking, let’s talk.
We’re not just building better tools - we’re building intelligence that understands context. Intelligence that knows when to ask questions and when to stay quiet. Intelligence that earns trust instead of demanding it. Intelligence that fails gracefully and recovers elegantly.
This is the future where your AI doesn’t just know about the world - it knows about your world. Where context isn’t an afterthought but the foundation. Where craftsmanship matters more than speed-to-market.
We’re building the Terry-level AI infrastructure that the world deserves.
Series Conclusion: Context Changes Everything
From SSL’s 30-year journey to MCP’s 8-month revolution, we’ve seen how context separates craftsmanship from hack jobs.
The lessons:
- Part 1: Web security disasters taught us what NOT to do
- Part 2: MCP learned from those mistakes and changed everything
- Part 3: Now it’s your turn to build something that lasts
The challenge: Don’t just build MCP servers - build Mutual Intelligence that enhances human capability instead of replacing it.
The opportunity: We get to do this right from the start. No 30 years of technical debt. No decades of security patches. Just clean, context-aware systems built with care.
The responsibility: Build something Terry would be proud of. Something that earns trust progressively. Something that handles edge cases gracefully. Something that respects the craft.
📢 Ready to build Terry-level MCP servers?
Share the complete trilogy with developers who care about craftsmanship.
(The world needs more context-aware intelligence, built with care)
🎉 ACHIEVEMENT: CONTEXT CRAFTSPERSON 🎉
You’ve completed the Mutual Intelligence trilogy.
Now go build something that earns trust, handles edge cases gracefully,
and makes Terry proud. 🔧⚡