OpenRegistry, a Canadian corporate-registry service, now lets an AI agent check whether a company is legitimately registered with Corporations Canada, British Columbia, or the Northwest Territories through a single consistent interface, regardless of which government system sits behind it. The registries themselves are inconsistent — different formats, different update cycles, different quirks by jurisdiction. The agent doesn't need to know any of that. It asks one way and gets one kind of answer back.
That consistency is the entire pitch behind Model Context Protocol, and it's why MCP has moved, in under two years, from an Anthropic-authored specification to something vendors like Elastic are building directly into their products. The practical question for Canadian security and technology leaders isn't whether MCP is useful. The OpenRegistry deployment answers that. The question is what happens when a protocol built to make tool access easy becomes the default way agents reach dozens of systems they were never individually vetted to touch — and who is responsible when that goes wrong.
What MCP Actually Replaces
Before MCP, connecting an AI agent to an external tool meant writing custom integration code for that specific API, that specific authentication method, that specific data format. Every new tool was a new engineering project. MCP standardizes that handshake: a tool exposes itself through the protocol once, and any MCP-compatible agent can discover and use it without custom glue code.
That's the "what problem does this solve" answer, and it's a real one — it's the same reason USB replaced a drawer full of proprietary cables. But the analogy has a limit worth naming precisely: USB moves data between a device and a machine you already possess and control. MCP moves an agent's requests into systems — financial platforms, registries, internal databases — that belong to someone else, under authorization rules that are still being figured out in production, not in a lab.
The protocol itself is evolving quickly enough to suggest its backers know the stakes are rising. The 2026-07-28 specification release candidate is described by its own maintainers as the biggest revision since launch: a stateless core built to run on ordinary HTTP infrastructure, response caching, an extensions framework, and — notably — authorization hardening. Standards bodies don't harden authorization for a feature nobody's using. They harden it because production deployments have already found the soft spots.
The Trust Chain Nobody Can Fully See
Here's where the plumbing metaphor stops being comforting. A physical pipe has one property that matters most: you can trace where the water came from. An agent using MCP to reach a tool, which reaches an API, which reaches a downstream service, produces a chain of trust that's much harder to reconstruct after the fact — especially once that agent is connecting to dozens of tools dynamically, deciding at runtime which ones it needs rather than following a fixed, pre-approved list.
Academic research on MCP tool descriptions gives a concrete sense of how shaky the foundation under that chain can be. A recent analysis found that 97.1% of examined MCP tool descriptions contained at least one quality defect, and 56% failed to clearly state what the tool actually does. Fixing those descriptions improved agent task success by a median of nearly six percentage points. Read that finding for what it actually says: agents are frequently choosing which real-world systems to touch based on descriptions that don't reliably say what those systems do. That's not a performance footnote. It's a governance problem wearing a performance costume — an agent that misunderstands a tool's purpose isn't just slower, it's more likely to use the tool wrong.
Now picture that inside a Canadian financial institution's claims workflow. An agent has legitimate, scoped MCP access to a claims database to summarize file histories. Someone later connects the same agent to a payments tool so it can flag suspicious claims for review — a reasonable, incremental decision, made by someone trying to solve a real problem, not someone cutting corners. Nothing forces a review of whether the original access scope still makes sense once a second tool is added. If the tool description for that payments connector is vague about what "flag" actually permits — read-only, or does it also allow the agent to hold a payment? — the person who approved the connection may not know. Multiply that ambiguity across the dozens of tools a mature agent deployment will eventually touch, and the honest answer to "can we reconstruct exactly what this agent was authorized to do and why" is, for most organizations right now: not fully, and not fast.
Governance Is Still Catching Up to the Plumbing
Ask who governs MCP the way a bank or telecom is governed, and there isn't a clean answer yet. It's an open specification with an active maintainer community and a public roadmap, which is more transparent than a black-box vendor API — but transparency in the spec is not the same as enforcement in your environment. The protocol defines how a handshake should work. It does not decide whether your organization should trust the specific MCP server on the other end of that handshake, and it does not audit that server for you.
That distinction matters more in Canada than the marketing suggests, because Canadian organizations adopting MCP inherit a governance gap that already exists around AI systems generally: there is no dedicated federal law governing how AI systems access and act on data, which means the accountability for an MCP connection gone wrong sits entirely with whoever approved it internally, not with a regulator who's already drawn the lines. An organization connecting an agent to a Corporations Canada-facing tool through something like OpenRegistry is, in effect, deciding for itself how much it trusts that intermediary — because no external body has done that vetting on its behalf.
The comparison worth making is to Agent-to-Agent protocol (A2A), which is sometimes framed as MCP's competitor. It isn't, cleanly. MCP standardizes how an agent talks to tools and data sources. A2A is aimed at how agents talk to each other. An organization running agentic workflows will likely end up using both, for different edges of the same graph — which means the governance question isn't "which protocol do we pick," it's "do we have one coherent view of every connection our agents can make, regardless of which protocol carries it." Most organizations don't have that view today. They have an MCP integration here, a direct API call there, and no single inventory of what any given agent can actually reach in total.
The Counterargument Worth Taking Seriously
It's fair to push back on the "plumbing of the internet" framing itself. Plumbing implies something foundational, invisible, and essentially settled — the way HTTP or TCP/IP became settled. MCP is roughly two years old, still issuing breaking changes in its specification, and its production footprint — real enterprise deployments at meaningful scale, not pilots — is genuinely hard to size precisely from public evidence. Calling it "the plumbing" before the pipes have stopped changing shape risks overstating how solved this is.
The more defensible claim is narrower: a standardized connection layer between agents and tools is clearly forming, MCP is currently the leading candidate to be that layer, and the deployments that exist — regulatory registry lookups, search infrastructure, claims-adjacent workflows — are real, not speculative. Whether MCP specifically wins that role permanently, or gets absorbed into something else as the specification matures, is a separate and genuinely open question. The plumbing analogy is useful for understanding the shape of the problem. It's premature as a statement of settled fact.
What This Means for the Next Eighteen Months
The organizations best positioned won't be the ones that adopt MCP fastest or the ones that wait for a standards body to certify it safe — neither instinct fits how this protocol is actually moving. The better position is treating every MCP connection the way a network team treats a new firewall rule: written down, owned by a specific person, reviewed when the agent's scope changes, and revocable without a ticket that takes three weeks. That means an actual inventory of which tools each agent can reach, not the list from the original design document; a real distinction between read access and write access in how those tools are scoped, since a compromised or confused agent with write access to a payments tool is a materially different incident than one with read-only access to a claims summary; and a documented answer, in advance, to what happens when a tool description turns out to have been wrong about what the tool does.
None of that is free, and none of it moves as fast as the protocol itself is moving. That's the actual tradeoff on the table: MCP makes it easier to connect an agent to more systems, faster, than any integration approach that came before it. Easier and faster is exactly the property that makes an unreviewed connection dangerous. The plumbing metaphor gets one thing right whether or not it's premature — nobody audits a pipe after the water's already flooded the basement.
What Leaders Should Do Security and technology leaders should treat AI systems and autonomous agents as governed identities, not informal tools. In practical terms, they should:
- Inventory critical ai dependencies.
- Assign an accountable owner for each agent or ai-enabled workflow.
- Document access controls, authentication, logging, approval boundaries, and revocation paths.
- Test fallback options and incident response playbooks.
- Include ai availability, jurisdictional risk, and auditability in procurement.