MCP Protocol

Before MCP, every AI agent integration was custom. Want Claude to use your CRM? Build a specific plugin. Want GPT to query your database? Build another one. Different formats, different auth mechanisms, different everything. It was the USB-A era of AI — a different cable for every device.

MCP changed that. It's the USB-C moment. One protocol, universal compatibility. Build an MCP server once, and every MCP-compatible agent can use it. Claude, GPT, Gemini, open-source agents — all of them.

The reality is this matters enormously for B2B companies. AI agents are increasingly involved in purchasing decisions, product evaluations, and workflow automation. If your product doesn't speak MCP, agents can't include you in their recommendations or automate interactions with your service. You're voluntarily opting out of the agentic economy.

MCP defines a client-server architecture with a clean separation of concerns:

1. The MCP Host — the AI application (like Claude Desktop or a custom agent) that needs external capabilities. It runs one or more MCP clients.

2. The MCP Client — maintains a 1:1 connection with a specific MCP server. Handles message routing and protocol negotiation.

3. The MCP Server — exposes tools, resources, and prompts. Each server declares its capabilities during an initialization handshake.

The protocol flow works like this. The client sends an initialize request. The server responds with its capabilities and supported features. The client calls tools/list to discover available tools. Each tool comes with a name, human-readable description, and a JSON Schema for its parameters. When the agent decides to use a tool, the client sends tools/call with the tool name and arguments. The server executes and returns structured results.

All messages are JSON-RPC 2.0 — request, response, and notification patterns. The transport layer is pluggable: stdio for local servers, HTTP with SSE for remote ones. This means the same server implementation can work both during development (locally) and in production (remotely).

A RevOps team at a mid-market SaaS company connects their Salesforce instance through an MCP server. The server exposes tools like search_accounts, get_deal_pipeline, and update_opportunity_stage.

Their VP of Sales opens Claude and asks: "Show me all opportunities over $100K that haven't had activity in the last 14 days." Claude's MCP client calls search_accounts with the right filters. The server queries Salesforce's API, formats the results, and returns them. Claude presents a clean table with account names, deal sizes, last activity dates, and assigned reps.

The VP then says: "Move the Acme Corp deal to Negotiation stage and add a note that I'll follow up Thursday." Claude calls update_opportunity_stage — one tool call, the CRM is updated, and the VP saved 10 minutes of clicking through Salesforce.

• Confusing MCP with function calling. Function calling is how an LLM decides to invoke a tool. MCP is the protocol for how that invocation actually reaches the external system. They're complementary, not competing.
• Building without the SDK. Official MCP SDKs exist for Python, TypeScript, and other languages. Rolling your own JSON-RPC implementation is reinventing the wheel and missing edge cases around connection management, error handling, and capability negotiation.
• Exposing sensitive operations without guardrails. MCP servers should implement proper authorization. Just because an agent can call delete_all_records doesn't mean it should. Add confirmation flows, permission scopes, and audit logging.
• Ignoring the initialization handshake. The initialize exchange is where clients and servers agree on capabilities and protocol version. Skipping it or hardcoding values leads to silent failures when either side updates.
• Treating MCP as a replacement for webhooks or REST. MCP is for AI agent interactions. Your existing integrations still need REST APIs, webhooks, and GraphQL. MCP is an additional interface, not the only one.