The Model Context Protocol is the reason Claude can query your QuickBooks, ChatGPT can search your Gmail, and Perplexity can pull from your Shopify. Before MCP, every AI-tool integration was a one-off. After MCP, tools and models interoperate.
This post explains what MCP actually is, how it works at the protocol level, and why the architecture decisions matter for anyone evaluating AI-native tooling.
The problem MCP solves
Before MCP, connecting an AI assistant to an external tool required a custom integration per model. An integration with Claude would not work with ChatGPT. A Gmail connector built for one model needed to be rebuilt for every other model.
The analogue is the web before standard protocols. Every browser implemented its own way of talking to servers. Once HTTP and HTML standardized, the web became interoperable.
MCP plays the same role for AI tool use. A server that exposes QuickBooks via MCP works with any MCP-compliant client: Claude, ChatGPT, Perplexity, or anything else. Build once, work everywhere.
The three components of MCP
MCP defines three roles.
Host. The application the user talks to. Claude Desktop, Claude on the web, ChatGPT, Perplexity. The host presents the conversation UI and runs the model.
Client. The component inside the host that speaks MCP. Every host has an MCP client that handles the protocol mechanics: connecting to servers, discovering tools, routing calls.
Server. The component that exposes tools. This is where CorpusIQ lives. A CorpusIQ MCP server exposes QuickBooks, Shopify, Gmail, and 20+ other tools. The server describes each tool, its inputs, and its outputs. When the model wants to call a tool, the client routes the call to the server, the server executes it, and the result comes back.
How a conversation actually flows
A user asks Claude, "what is my current cash position in QuickBooks?"
- Claude's host sends the user message to the model.
- The model recognizes this requires external data. It responds with a tool call: "use the QuickBooks tool
get_balance_sheetwith these parameters." - The host's MCP client receives the tool call intent and routes it to the CorpusIQ MCP server.
- CorpusIQ's server receives the call, authenticates with QuickBooks using the user's OAuth token, executes the query against QuickBooks Online's API.
- The QuickBooks response flows back through the server to the client to the model.
- The model uses the data to compose a human-readable answer.
- Claude shows the answer to the user.
Steps 1, 2, 6, and 7 happen inside Anthropic. Steps 3-5 happen between Anthropic's client and the CorpusIQ server. The user experiences it as a natural conversation.
Discovery, capability negotiation, and tool definitions
The part that makes MCP extensible is discovery.
When a client connects to a server, the server sends a manifest. The manifest lists tools, their names, descriptions, input schemas, and output schemas. The model does not know what tools exist until this discovery happens.
This matters because the set of available tools changes based on what the user has connected. A user with QuickBooks gets QuickBooks tools. A user with Shopify gets Shopify tools. A user with both gets both sets, and Claude can call either.
The manifest is also how tool descriptions inform model behavior. A well-described tool ("Search Gmail for messages matching a query. Returns message IDs, sender, subject, and snippet.") gets called at the right times. A poorly-described tool gets called incorrectly or ignored.
Why the transport layer matters
MCP uses JSON-RPC 2.0 over stdio or HTTP+SSE. That sounds boring; it is not.
JSON-RPC is a stateful protocol. Client and server maintain a connection. Either side can send messages at any time. This allows the model to call tools multiple times in a single conversation turn without reconnecting, and it allows servers to push notifications (for example, "your connection expired").
The stdio transport is for local MCP servers running on the same machine as the client. Useful for desktop apps.
The HTTP+SSE (Server-Sent Events) transport is for remote servers. CorpusIQ runs HTTP+SSE so Claude and ChatGPT in the cloud can reach CorpusIQ's servers wherever they are deployed.
What CorpusIQ adds on top of MCP
Raw MCP is a protocol. It does not solve authentication, data safety, rate limiting, or scale.
CorpusIQ implements MCP and adds:
OAuth flows per connector. QuickBooks wants OAuth one way, Shopify another, Google a third. CorpusIQ handles each vendor's authentication idiosyncrasies and exposes a uniform MCP interface to the model.
Read-only enforcement. CorpusIQ's tool definitions expose only read operations. The model cannot trigger write actions through CorpusIQ regardless of what it tries.
Rate limiting. If a model tries to make 500 QuickBooks calls in a minute, CorpusIQ's auth gate enforces reasonable limits before any of those hit Intuit's servers.
Multi-connector queries. A user asks about a customer across QuickBooks, Gmail, and HubSpot. CorpusIQ's server exposes all three and Claude can call any of them in sequence to build the answer.
Managed infrastructure. CorpusIQ runs on Azure Container Apps with health checks, audit logging, scoped retention, and per-tenant token storage in Azure Key Vault. Direct MCP does not retain raw customer files or full connector response payloads; operational logs may persist for up to 30 days.
None of this is mandated by MCP. MCP is the protocol. CorpusIQ is the production-grade implementation.
What MCP does not do
Three things.
MCP does not handle authentication. Each server implements its own auth. CorpusIQ handles OAuth for 40+ connectors; that is work MCP did not define.
MCP does not define data residency or retention policy. CorpusIQ applies separate lifecycles for direct retrieval, 30-day Azure Log Analytics logs, and optional indexed search. The selected AI client's plan and settings govern conversation handling after receipt.
MCP does not guarantee safety. A badly designed MCP server could expose dangerous tools to any connected model. Safety requires intentional design, which is why CorpusIQ enforces read-only scopes across all connectors.
Why this matters for AI-native businesses
Two reasons to care.
First, MCP is the standard. Betting on a single-vendor tool integration is a strategy that dies the moment that vendor changes its API or you want to switch models. MCP-based integrations work with any MCP client, today or in the future.
Second, the reasoning layer can now cross tools freely. The old model (integrations pre-defined by the vendor, one workflow per tool) is replaced by: connect many tools, let the model reason across them. The compounding value is high.
See also
FAQ
Who created MCP?
Anthropic published the Model Context Protocol specification in late 2024. It is an open standard; any vendor can implement it.
Does MCP only work with Claude?
No. ChatGPT, Perplexity, and other AI assistants have added MCP support. The protocol is model-agnostic by design.
Is MCP the same as OpenAI function calling?
Similar in purpose, different in implementation. Function calling is vendor-specific and defined per-model. MCP is a transport-layer protocol that any model can speak.
Do I need to understand MCP to use CorpusIQ?
No. CorpusIQ handles the MCP implementation. You connect your tools and ask questions. Understanding MCP helps if you are evaluating AI infrastructure decisions.