Model Context Protocol (MCP) is an open protocol that lets AI applications discover and use external data, prompts, and tools in a consistent way. It reduces the cost of building a custom integration between every agent and every system, but it standardizes only how capabilities and context are exchanged. Whether data is correct, what a tool may do, and who can approve an action still depend on the host, server, and organizational governance.
Think of MCP as an agent connection standard, not intelligence itself
USB does not make a hard drive intelligent. Its value is that different computers can recognize a device through a common standard. MCP plays a similar role: an AI application sits on one side, while a service providing data or capabilities sits on the other. Standard messages describe “what I have” and “how you can invoke it.”
Under the latest stable MCP specification (2025-11-25), the protocol uses JSON-RPC 2.0 and has three principal participants:
- Host: The AI application coordinating the user, model, and multiple connections.
- Client: A component inside the host that maintains a connection to one MCP server.
- Server: A program that supplies context or executable capabilities.
A server can expose three core primitives:
| Primitive | What it provides | Data-analysis example |
|---|---|---|
| Resources | Readable context or data | Schema documentation, metric definitions |
| Prompts | Reusable message templates or workflow entry points | Monthly-report analysis prompt |
| Tools | Functions the model may request | Query data, create a Plan, export results |
A host may also offer capabilities such as roots, sampling, or elicitation. Client and server negotiate the features they support during connection initialization. “Supports MCP” does not mean “supports every primitive.”
What actually happens during a tool call?
A request to query order data can be broken into five steps:
- The host connects to the server and exchanges protocol versions and capabilities.
- The client asks which tools or resources the server provides.
- The server returns tool names, descriptions, and input schemas.
- The model proposes a tool call based on the user's objective; the host decides whether to send it under the applicable permissions and consent flow.
- The server executes and returns a result, which the model interprets before taking the next step.
The MCP architecture documentation emphasizes that MCP focuses on context exchange. It does not dictate how an AI application uses an LLM or manages retrieved context. Two agent harnesses connected to the same MCP server can therefore provide completely different approval, recording, and error-handling experiences.
This is also where the “USB for agents” analogy ends. An MCP tool may query data, write files, or perform high-impact actions, making it far more sensitive than a typical peripheral. A tool description cannot automatically be treated as trustworthy.
MCP solves three integration problems, not four governance problems
MCP provides three direct benefits:
- Discoverability: An agent can enumerate capabilities through a standard method instead of hard-coding every API into a prompt.
- Composability: One host can connect to multiple servers, and one server can serve different clients.
- Interface consistency: Lifecycle, tool schemas, progress, cancellation, and errors share a common language.
After connecting, however, teams still need separate answers to four questions:
- Permissions: Can the connection read, write, or perform administrative operations?
- Correctness: Is returned data fresh, and are field and metric definitions consistent?
- Governance: When do high-risk actions require human approval, and are activities inspectable?
- Trust: Who controls the server, tool descriptions, input content, and credentials?
The stable specification's security section explicitly calls for user consent and control, data protection, and tool safety, while explaining that the protocol layer cannot enforce every security principle. MCP is therefore one vehicle for governance, not a certification that a connection is safe by default.
Why MCP deserves more attention in 2026
The MCP 2026 Roadmap identifies transport scalability, agent communication, governance maturation, and enterprise readiness as priorities. It also openly notes enterprise deployment challenges involving audit trails, SSO-integrated authorization, gateway behavior, and configuration portability. Most are directions for continued development, not features already solved in full by the core specification.
The signal matters because MCP is expanding from local tool integration toward broader production use. At greater scale, host boundaries, credentials, approvals, and audits can no longer rely on defaults.
Do not confuse Lantide Data's two MCP directions
Lantide Data supports two integrations that point in opposite directions:
Direction one: Lantide as an MCP client
In MCP Sources, Lantide connects to external MCP sources using stdio or HTTP, retrieves data, and materializes it as queryable sidebar tables. This is useful for data and APIs beyond conventional PostgreSQL, MySQL, or SQLite connections. If you only use standard databases and local CSV files, MCP Sources may not be necessary. See Getting started with MCP Sources for operations and states.
Direction two: Lantide as a local MCP Server
Lantide can also let external agents such as Codex, Claude, and Cursor connect to its analysis workspace if they support Streamable HTTP MCP. An external agent can read or create Plans, SQL evidence, and Reports within the connection's Observe/Execute/Admin capability ceiling, while the Lantide GUI retains review, Activity, and audit. The server binds only to local 127.0.0.1. Its bearer credential should be shared only with a trusted local client, never pasted into public or remote environments. See the External Agent and MCP Server guide.
Connection, recovery, and client-compatibility behavior can change between versions, so deployments should follow the User Guide for the installed version and verify behavior directly.
Neither direction gives an agent unlimited access automatically. MCP Source permissions depend on the source and its configuration. External Agent access mode is selected when the connection is created, while Approve & Execute authorizes only the relevant Plan and does not elevate the connection mode.
Four questions to ask before choosing an MCP integration
Do not ask only whether a server connects. Ask:
- Which resources and tools does the server expose, and what side effects does each tool have?
- Where are credentials stored, when do they expire, and how are they rotated or revoked?
- Does the host display clear parameters and a meaningful consent interface before invocation?
- Which artifacts, activities, and audit records remain afterward, and can they reproduce critical results?
If these four answers are incomplete, validate the integration with test data and read-only permissions first. A protocol can shorten integration time. A trustworthy agent workflow still needs concrete scope, approval, and evidence.