MCP stands for Model Context Protocol: a standard that Anthropic developed to give Claude a consistent way to interact with the outside world. Understanding it is worth your time, even if you never build one yourself, because it explains the architectural layer that connects Claude to your data, your tools, and your services.
The Problem MCP Solves
Without a standard like MCP, every integration between Claude and an external service requires custom code. You'd need one approach to connect Claude to BigQuery, a different approach for Slack, another for your CRM. Each connection is its own engineering problem: its own authentication handling, its own error logic, its own way of formatting results so Claude can work with them. That works at small scale. It becomes a maintenance nightmare quickly.
MCP solves this by introducing a standard intermediary. Instead of Claude needing to know the specifics of every API in existence, someone builds an MCP server for a specific service, and that server acts as a translator. Claude speaks MCP on its side. The server converts that into whatever the external API needs, then passes results back in a format Claude understands. Claude never has to know the details of the BigQuery API, or the Slack API, or your internal data warehouse; it just knows how to talk to MCP servers, and MCP servers handle the rest.
How It Actually Works
When you start a conversation with Claude through a compatible client, the tool definitions from the connected MCP server get loaded automatically. Claude sees the tool, understands what it does from the description, and uses it when appropriate. It doesn't need to know the underlying API specifics. The server handles that translation.
The Token Cost Most People Miss
There's a catch. Every tool definition gets sent as input tokens with every single request, whether Claude uses the tool or not.
Watch out: tool definitions are always-on overhead
Every tool definition gets sent as input tokens with every single request, not just when Claude uses the tool, but on every call whether Claude needs those tools or not. If you connect ten MCP servers and each offers five tools, that's fifty tool definitions riding along. Each definition might be 100–300 tokens. Fifty tools can easily add 5,000–15,000 tokens of overhead per request before you've said a single word.
The design implication is simple: be intentional about what you connect. Don't load MCP servers speculatively because they might be useful someday. Connect what the tool actually needs, and nothing more.
Why It Matters for Marketing Tools
If you're building a marketing data tool and considering how to connect it to BigQuery or another data source, packaging that connection as an MCP server gives you something valuable: interoperability. An MCP-based integration works in Claude Code, the Claude desktop app, and any other MCP-compatible client without you building custom code for each.
As the MCP ecosystem grows, and it's growing quickly, this becomes increasingly meaningful. Tools that adopt the standard today are easier to extend and connect tomorrow. For most marketing teams just getting started, this is probably a second-phase concern rather than something to solve on day one. But knowing it exists shapes early architecture decisions in useful ways. The choice you make about how to connect Claude to your data either opens or closes this door later.
MCP vs. System Prompts: Different Layers
| Layer | What it handles | The question it answers |
|---|---|---|
| MCP Server | How Claude accesses a service (BigQuery, Slack, CRM) | "How does Claude connect to this?" |
| System Prompt | What Claude knows and how it should behave | "What rules apply and what does Claude know?" |
MCP servers answer the question of how Claude accesses a service. The other questions, what should Claude know before it acts, how should it behave, what rules apply, those are handled by system prompts and context files, which we cover in the next post.