The metaphor comes from the source. The official docs say it plainly: "Think of MCP like a USB-C port for AI applications." A USB-C port gives every device one standardized plug. MCP gives every agent one standardized way to reach tools and data. That is a genuine advance, and it is worth adopting.
A port is also the wrong place to look for safety. USB-C standardizes the connector. It does not decide which device is trusted, how power is managed, or what data may cross the cable. MCP is the same. It moves the request. It does not decide what the request is allowed to do. Read the table below as the whole argument.
| Capability | Raw MCP connectivity | MCP + Colrows semantic execution |
|---|---|---|
| What the agent gets | A pipe to tools and a database | Governed capabilities: approved metrics, valid joins |
| How SQL is produced | The model guesses SQL | Intent compiled to deterministic SQL |
| Access control | Inherited from the tool, if any | Identity, RBAC, row-level security, masking before execution |
| Same question, same answer | Not guaranteed | Guaranteed by construction |
| Auditability | A log of the call | Full trace: intent, query, data touched, and reason |
The point is not to replace MCP. The point is to put a governed layer behind it. Standardizing on MCP is the correct first decision. It is not the last one.
Why the USB-C analogy is actually correct
MCP is not a lab experiment. It is now cross-vendor infrastructure, and the adoption record proves it. Anthropic introduced MCP in November 2024. OpenAI adopted it in March 2025. Sam Altman said, "People love MCP and we are excited to add support across our products." Google committed Gemini and Vertex AI support in April 2025. Demis Hassabis called MCP "rapidly becoming an open standard for the AI agentic era." Microsoft shipped native MCP support at Build 2025.
Then the governance of the protocol itself changed. In December 2025 Anthropic donated MCP to the Linux Foundation's new Agentic AI Foundation. The founding members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Anthropic's Mike Krieger said MCP "has become the industry standard for connecting AI systems to data and tools." The latest specification revision is dated 2026-07-28. Even news providers now ship MCP servers: Reuters launched one on 2026-07-08.
A protocol governed by direct competitors carries a clear signal. None of them can quietly break it. All of them have a reason to keep it interoperable. That is what makes the USB-C claim more than hype. The plug is standard, and it is here to stay. For the full adoption record, see how MCP became enterprise infrastructure.
The part USB-C never promised: trust
Standardized access is the easy half. The hard half starts once the agent is connected. Four questions decide whether an enterprise agent is safe, and a port answers none of them.
- Identity. Which user or service does the agent act for? A shared service token cannot answer that.
- Access. May this identity see the rows it asked for? Row-level and column-level policy has to run before the query, not after.
- Semantics. What does "revenue" mean here? Which join is the correct one? A schema does not carry that meaning.
- Observability. Can you replay what the agent did, and prove it? A log of the call is not a log of the decision.
One correction is worth making, because it appears in a lot of MCP write-ups. Microsoft Copilot Studio supports MCP tools and resources, not prompts, per Microsoft Learn updated 2026-08-03. The detail matters for the same reason the whole post does: connectivity features are precise, and governance features are separate. Do not assume the protocol gives you a control it does not.
What "just connect the database" actually does
Give an agent a raw SQL tool and it will guess. The benchmarks show how often it guesses wrong on real enterprise data.
On Spider 2.0, the enterprise text-to-SQL benchmark from ICLR 2025, GPT-4o solved 10.1 percent of tasks and o1-preview solved 17.1 percent. The same models score around 86 percent on the older, toy Spider 1.0. The gap is the enterprise. Real schemas average about 812 columns. Real queries run past 100 lines. On BIRD, the best system reaches 81.95 percent execution accuracy with oracle knowledge, still below the 92.96 percent human baseline.
In self-service analytics there is no analyst checking the number. So 90 percent accuracy behaves like zero. One silently wrong figure in a board deck destroys trust in every figure next to it. We cover this failure in full in the text-to-SQL accuracy cliff.
Raw connectivity has also caused real incidents, not just wrong answers. CVE-2025-6514 in the popular mcp-remote client scored 9.6 and allowed remote code execution through a malicious server. In June 2025 an access-control logic flaw in Asana's MCP feature exposed data from about 1,000 organizations to other tenants. Elastic Security Labs tested MCP implementations in September 2025 and found 43 percent had command-injection flaws and 30 percent allowed unrestricted URL fetching. Connect first and govern later is not a safe order of operations.
Connectivity versus correctness
Here is the sharp line. Raw MCP produces SQL by probability. A governed semantic layer produces SQL by compilation. The agent states intent. The layer resolves that intent against a typed model, proves the join, enforces access, and emits deterministic SQL. The agent is right by construction, not by luck. This is the distinction we draw in deterministic versus probabilistic text-to-SQL.
Two objections deserve a straight answer.
"The warehouses already do this." In part, they do. Snowflake Cortex Analyst and Databricks Genie pair a semantic model with native access control. Each is single-vendor and single-warehouse, and you hand-author the model. The natural-language step stays probabilistic outside the modelled scope. Enterprises run many engines at once and need one identity-aware layer across all of them.
"Cube and AtScale are already the semantic layer for agents." This is the real overlap, because they use the same words. Be precise about the difference. Their models serve pre-defined cubes and metrics, and determinism holds inside what is modelled. Colrows compiles free-form intent into governed SQL and enforces per-identity access at execution, across sources. Compare the positions directly in Colrows vs Cube and Colrows vs the dbt Semantic Layer.
Fix the Context, Not the Model. The agent does not fail because the model is weak. It fails because it guesses over raw schemas with no business context and no access rules. Give it governed context, and correctness stops being a gamble.
Where the industry goes next
The transport layer is hardening fast. MCP added OAuth authorization, and gateways now add rate limits, allowlists, and audit on the tool call. That work is real and useful. It secures the door. It does not govern the query behind the door.
So the next frontier is the data layer. Once every platform speaks MCP, the differentiator is no longer whether an agent can connect. It is whether the answer it gets back is correct, authorized, and auditable. That is a semantic problem, and it sits one layer below the protocol. The teams that treat it as an architecture decision, not a checkbox, are the ones whose agents reach production.
Where Colrows fits: behind the protocol, never instead of it
Colrows is the semantic execution layer behind your MCP fleet. Agents emit intent over MCP. Colrows resolves that intent against a typed semantic graph, proves every join, enforces RBAC, ABAC, and row and column policy at compile time, and emits dialect-perfect SQL across 16+ engines. It returns a structured result with a full audit trail: the graph version, the definitions used, the executed SQL, and the identity context.
It exposes an MCP server and a REST surface over the same governed tools, so agent traffic and dashboard traffic compile through one graph and return the same answer. See the Colrows MCP integration guide for the endpoint, the OAuth flow, and the tool catalog. The wider case sits in how to build an MCP semantic layer server. MCP is the transport. The semantic layer is the logic. You need both.
The same thesis drives the Company Brain argument for enterprise AI: the model is rarely the constraint, and the governed context almost always is.
Frequently asked questions
Is MCP really the USB-C port for AI agents?
Yes. The official Model Context Protocol documentation uses that exact metaphor. MCP gives AI applications one standardized way to connect to external systems, the way USB-C gives devices one standardized plug. The metaphor is accurate, and it also marks the limit: a port standardizes the connection, not the safety of what flows across it.
What does MCP not do for enterprise data?
MCP standardizes access. It does not decide which user an agent acts for, whether the agent may see the rows it asked for, whether the generated SQL is correct, or whether the answer is auditable. Those are governance and correctness questions. They belong to a semantic execution layer behind the MCP server, not to the protocol.
Why is connecting an agent directly to a database risky?
A direct connection lets the agent guess SQL over raw schemas. On the Spider 2.0 enterprise benchmark, GPT-4o solved 10.1 percent and o1-preview 17.1 percent of real tasks. Real schemas average about 812 columns. A wrong join or a wrong metric produces a confident, wrong number, and in self-service analytics no human checks it.
How is a semantic execution layer different from MCP?
MCP is the interface. A semantic execution layer is the logic behind it. It compiles a business question into deterministic SQL, enforces identity, RBAC, row-level security, and masking before execution, proves the join path, and returns a full audit trail. MCP moves the request. The semantic layer decides what runs and guarantees the answer.
Do warehouse-native tools already solve this?
In part. Snowflake Cortex Analyst and Databricks Genie pair a semantic model with native access control. Each is single-vendor and single-warehouse, and the natural-language step stays probabilistic outside the modelled scope. Enterprises run heterogeneous data estates and need one governed, identity-aware layer across them, not a separate one per warehouse.
