BIPI
BIPI

Model Context Protocol (MCP): What It Actually Solves, and Three Mistakes We Saw in Early Deployments

Agentic AI

MCP is the protocol most teams trying to ship agents in 2026 are reaching for. It is a real improvement over bespoke tool wiring. The early-adopter mistakes are also real and avoidable.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 9, 2026 · 8 min read

#mcp#ai-agents#tool-use#anthropic

The Model Context Protocol — MCP — is what the industry settled on for connecting AI agents to tools and data. Anthropic published it, the major model providers and IDE vendors adopted it, and by mid-2026 it is the default plumbing for any team building agentic systems that go beyond a single LLM call.

MCP is genuinely a step forward over the bespoke tool-registry-per-client wiring it replaced. It is also being deployed wrong in three specific ways that we keep finding when we audit MCP-based systems. Below: what MCP actually solves, and the three mistakes that show up in production.

What MCP actually solves

Before MCP, every agent platform reinvented tool integration. The same Slack-message-sending tool got rewritten for the OpenAI client, the Anthropic client, the LangChain wrapper, the custom internal agent framework. Each implementation drifted. Each had its own auth model. None of them composed.

MCP standardises the protocol between an AI client (the host running the agent) and a tool server (the thing exposing capabilities). One server can expose tools to any MCP-compliant client. The auth model is consistent. The discovery model is consistent. The same server that fronts your Jira API can be used by Claude, ChatGPT, Cursor, your internal agent — same code, same install.

Mistake 1: treating every API as a tool

The temptation is to wrap every endpoint in your existing API as a separate MCP tool. The result is an agent with 80 tools in its context, most of which it never picks correctly because the names blur and the descriptions overlap.

The fix is the opposite of microservices thinking. Compose tools at the level of the user task, not the level of the underlying API. A 'create-supplier' tool that internally calls 12 of your endpoints is more useful than 12 tools the agent has to chain. The agent picks better when the choice is sparse and outcome-named.

Mistake 2: shared MCP server across tenants

Most early MCP deployments run a single MCP server that connects to multiple users' data. The server has admin credentials to the underlying systems and authorises by passing the user identity in tool arguments. This is the same anti-pattern that creates IDOR in web apps, with the same outcome.

The fix is per-user MCP server instances or, when that is too heavy, MCP servers that get the user's own credentials at session start and never see admin credentials. The auth path mirrors how you would design any per-tenant API gateway. MCP does not exempt you from authorization design.

Mistake 3: no audit trail for agent actions

Every tool call your agent makes through MCP changes something or reveals something. If it cannot be reconstructed who initiated which call against which data with which tool result, you have shipped an unauditable system. Compliance reviewers will reject it. So will your future self trying to debug why an agent emailed the wrong customer.

MCP's protocol does not impose audit logging on you. You have to add it on the server side. Every tool invocation logs: principal (the user), tool name, arguments (with sensitive fields hashed), result hash, timestamp. The log goes to the same audit store as your other system events.

What we install for clients

  • MCP servers grouped by capability cluster, not by underlying API. Around five to twelve tools per cluster.
  • Per-user credentials passed at session start; servers never hold admin tokens.
  • Audit logging at the server boundary into the existing SIEM.
  • A 'requires-confirmation' flag per tool. Default true for any write or send operation.
  • Tool descriptions co-located with the tool code in the same repo, so descriptions cannot drift from behaviour.

Closing

MCP is the right plumbing for agentic systems. It is also raw plumbing — it does not impose authorization, audit, or sandboxing. The teams shipping MCP successfully in production are the ones treating it the way they would treat any new internal API surface: design the auth model deliberately, add the logs, gate the destructive paths. The protocol is the easy part.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.