Building MCP Servers with Claude: What I've Learned
A practical breakdown of Model Context Protocol — what it is, how to build a server, and where it actually fits in real client work.
Model Context Protocol (MCP) is the standard Anthropic built to let AI models like Claude talk to external tools, data sources, and APIs in a structured, predictable way. After getting certified in both the introductory and advanced tracks, and shipping a few real implementations, here's what I wish I'd known going in.
What MCP actually is
MCP is a client–server protocol. Your AI (the client) sends requests. Your server responds with context — data, files, API results, whatever the model needs to do its job. The key insight is that it's not a plugin system. It's a communication standard. That distinction matters for how you design.
A well-built MCP server is:
- Stateless where possible
- Typed (inputs and outputs are declared)
- Composable — tools should do one thing well
Where it's useful in client work
The pattern I reach for most is giving Claude access to a client's content system. A publishing team has hundreds of articles in a headless CMS. Instead of copy-pasting content into a prompt, you expose the CMS via MCP — Claude can query, summarize, cross-reference, and draft without leaving the context of what's actually published.
Same idea applies to:
- E-commerce catalog queries (Shopify storefront data → MCP → Claude)
- Support ticket triage (helpdesk API → MCP → response drafts)
- Code review pipelines (GitHub diff → MCP → structured feedback)
The advanced topics that changed how I build
The advanced certification covered a few patterns that aren't obvious from the intro material:
Tool composition — chaining tools within a single session so the model can iteratively refine. Rather than one big fetch, you build small, chainable tools.
Error surface design — how you surface errors matters a lot. The model reads your error messages and tries to recover. Descriptive, structured errors ("No records found matching — try broadening the date range") work far better than generic 500s.
Resource vs Tool distinction — Resources are things the model can read (files, documents, data). Tools are things it can do (run queries, call APIs, write files). Mixing these up leads to bloated, hard-to-debug servers.
Honest caveats
MCP is still early. The tooling is maturing fast but you'll hit rough edges — especially around auth, streaming, and session state. Budget time for that.
It's also not a replacement for good prompt engineering. A well-structured server with a poorly designed prompt is still a poorly designed system. Both matter.
If you're evaluating MCP for a project or want to talk through whether it's the right fit for your stack, get in touch.
Written by Jay Tillery — full-stack developer & AI engineer. Work with me →