Most posts about MCP treat it like a new kind of magic. It isn't. MCP is a protocol. A specification for how an AI agent talks to a server that offers tools. Nothing more. That said, it's the right protocol at the right time, and it's changed how we ship agents. Before MCP, every tool integration was custom. Want your agent to read Gmail? Write the wrapper. Want it to post to Slack? Write another wrapper. Want it to hit your CRM? Hope the vendor has a decent SDK, otherwise write that too. MCP replaces all of that with one client and a bunch of servers. The agent speaks MCP. Any tool that speaks MCP plugs in. Gmail, Slack, HubSpot, your internal database, a custom scraper you built last week. Same interface. So why do so many agent deployments still go sideways? Because people confuse the protocol with the strategy. Here's what breaks in real deployments. Tool bloat. I've audited agents running with forty-plus MCP tools loaded. Every tool description, every parameter schema, every example lives in the context window before the agent reads a single user message. Forty tools can easily burn ten thousand tokens. The agent gets slower, costs more per call, and starts picking the wrong tool because it's drowning in options. The fix is boring. You read the logs. You find out which tools actually get called. You strip the rest. An agent for a sales manager probably needs five tools from Gmail, not thirty-two. It needs two from HubSpot, not the full suite. Schema drift. MCP servers update. Parameters change. If you're not pinning versions or at least watching release notes, your agent will wake up one morning and start failing calls because an optional field became required. We've had this happen. Silent for hours. The agent kept responding, just with wrong answers. Log your tool calls and their results. Alert on error rate spikes. Auth sprawl. Every MCP server has its own auth flow. OAuth, API keys, tokens that rotate. For a single-user agent this is fine. For a business agent that handles multiple team members' data, it gets messy fast. Plan your auth architecture before you wire the first tool. Mismatched granularity. Some MCP servers give you one huge tool that does everything. Others give you fifty tiny tools. Both extremes hurt. One huge tool confuses the agent about what it can do. Fifty tiny tools fill the context window. If a server is too coarse or too granular for your use case, wrap it with your own MCP server that exposes the right abstractions. MCP is a good protocol. It's not the hard part of the job. The hard part is deciding which tools your agent should see, writing their descriptions well, and keeping the surface area small enough that the agent can actually reason about what it has. If your agent feels off, don't chase the protocol. Count your tools and read your logs.