Setting Up MCP Servers in Claude Code: A Tech Ritual for ...
Based on an r/ClaudeAI community discussion
Setting up MCP (Model Context Protocol) servers in Claude Code feels like a rite of passage for anyone serious about building production AI agents — and the friction is real. I've been through this process building Buddy, an open-source Google Ads agent on Claude, and the gap between "it works on my machine" and "it works reliably in production" is wider than most tutorials let on. Whether you're automating marketing workflows, spinning up custom tools for client reporting, or just trying to connect Claude to your internal data, getting MCP right is foundational. Here's what actually matters.
Model Context Protocol is Anthropic's open standard that lets Claude connect to external tools, data sources, and services through a defined interface. Think of it as the USB-C standard for AI integrations — instead of writing custom glue code for every tool Claude needs to touch, MCP gives you a consistent way to expose capabilities as "servers" that Claude can discover and call.
In Claude Code specifically, MCP servers let you extend what Claude can do beyond its base capabilities. Instead of pasting data into a prompt or writing elaborate workarounds, you can give Claude a direct line to:
For marketers and advertisers, this is the difference between Claude being a smart writing assistant and Claude being an actual agent that can pull live campaign data, run analysis, and take actions — all in one loop.
A common question in the r/ClaudeAI community is why MCP setup feels so unpredictable — sometimes it just clicks, and other times you're staring at errors with no clear path forward. After going through this multiple times, I've found the process breaks into three distinct phases, each with its own failure modes.
This is where most people underinvest. Your MCP server needs to expose a list of commands (tools) with enough descriptive metadata that Claude can figure out how to use them — even without explicit instructions in every prompt. As practitioners often discuss, a well-designed MCP has tool descriptions that are essentially self-documenting: the name, the parameters, and the description together tell Claude what to call, when to call it, and what to expect back.
Treat your tool descriptions like you're writing documentation for a junior developer who has no other context. Be explicit about:
MCP servers communicate with Claude Code through one of two transport mechanisms: stdio (standard input/output) or SSE (Server-Sent Events over HTTP). Getting this configuration right in your claude_desktop_config.json or equivalent config file is where a lot of the ritual-like debugging happens.
For local development and most agentic workflows, stdio is simpler and more reliable. For production deployments where the MCP server needs to run remotely or serve multiple clients, SSE is the right choice but adds complexity around authentication and connection management.
| Transport Type | Best For | Key Consideration | Production Ready? |
|---|---|---|---|
| stdio | Local agents, single-user tools | Process must be running locally | Yes, for local use |
| SSE (HTTP) | Remote servers, multi-client setups | Needs auth & connection handling | Yes, for distributed use |
Once your server is running and Claude Code is configured to connect to it, there's still the question of whether Claude actually discovers and correctly uses your tools. This phase is where the "ritual" feeling really kicks in — you restart, you check logs, you test a prompt, and you iterate.
The validation process should be systematic, not hopeful. Test each tool explicitly with a prompt designed to invoke only that tool, confirm the input/output is what you expect, then test combinations of tools to see how Claude chains them in real agentic loops.
Here's the actual process, stripped of the magic and laid out in order:
npm install @modelcontextprotocol/sdk for Node.js projects.claude_desktop_config.json to point to your server. The exact path and command matter — test the command manually in your terminal first.If you're building MCP servers to power marketing or advertising agents — which is where I spend most of my time — there are design principles that separate servers that actually work in production from ones that feel impressive in demos but fall apart under real load.
Too coarse-grained and Claude can't be precise enough in what it does. Too fine-grained and you need 15 tool calls to accomplish something simple, burning tokens and latency. For Google Ads workflows specifically, I've found that tools organized around meaningful business actions — "get campaign performance," "update bid strategy," "pause underperforming ad groups" — work better than either giant do-everything tools or atomic CRUD operations.
A rough benchmark: if a single logical task in your workflow requires more than 4-5 tool calls, your tools are probably too granular. If a single tool has more than 6-7 parameters, it's probably trying to do too much.
This is underappreciated. The data your tools return shapes how well Claude can reason about it and take next steps. JSON is fine, but structured JSON with clear field names beats raw arrays. Including summary statistics alongside detailed data gives Claude better signal for decision-making without forcing it to compute everything from raw numbers.
For ad campaign data, I'll typically return something like:
This pattern means Claude can immediately see the headline situation in the summary, drill into specifics in the entity array, and understand the data context from metadata — without needing to do a lot of manual aggregation.
Agentic loops fail at the edges. When your MCP tool hits an API rate limit, gets a malformed response, or encounters a permission error, how it communicates that failure to Claude determines whether the agent can recover gracefully or just stops. Return structured error objects, not thrown exceptions that bubble up as opaque failures. Include enough context in error messages that Claude can explain what happened and, ideally, suggest a next step.
The r/ClaudeAI community has surfaced a lot of the same setup frustrations repeatedly — and most of them come down to a handful of recurring issues.
The most common source of "my server runs fine from terminal but not from Claude Code" is environment variable and PATH differences. Claude Code doesn't inherit your shell environment the way a terminal session does. Any environment variables your MCP server needs (API keys, database URLs, etc.) need to be explicitly provided in the config, not assumed from the system environment.
.env files or shell exports that work in your terminal but aren't available when Claude Code spawns your server process. Always explicitly configure environment variables in your MCP server config entry, and use absolute paths for executables rather than relying on PATH resolution.If Claude is calling your tool but getting errors, check your parameter schemas first. The MCP SDK enforces JSON Schema validation, and mismatches between what Claude passes and what your schema declares will cause quiet failures. Common issues: string vs. number types, required vs. optional parameters, and nested object schemas that don't match the actual structure.
MCP is still evolving. The SDK version your server uses needs to be compatible with the MCP client version that Claude Code implements. When in doubt, check the Anthropic documentation for the current recommended SDK version and don't assume the latest npm version is always right.
For simple workflows, one MCP server with a handful of tools is enough. For production agents handling real advertising budgets — where I'm typically dealing with Google Ads accounts spending anywhere from $10K to $500K+ per month — the architecture gets more deliberate.
A few patterns that hold up at scale:
If you're ready to move from reading about MCP to actually building with it, here's where to put your energy:
MCP setup has a real learning curve, and the "tech ritual" feeling is legitimate — there's friction in the configuration, the environment, and the schema design that you have to work through. But once it clicks, you have the infrastructure to build agents that actually do things, not just agents that talk about things. That's a meaningful capability shift, and it's worth the investment to get right.