MCP is a real cross-vendor standard now. Here's what that should change about how you evaluate it
Google, Microsoft, Salesforce, Snowflake, and ServiceNow all shipped native MCP support in 2026 — what to check before connecting an agent to your data through it.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
For most of 2025, “supports MCP” was a claim one company made about its own protocol. That changed in a concrete, checkable way over the past year: in December 2025 Anthropic handed governance of the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it alongside co-founders Anthropic, Block, and OpenAI. Since then, three more enterprise platforms with very different products — Salesforce, Snowflake, and ServiceNow — have each shipped their own native MCP support rather than a proprietary alternative.
That’s a different situation than “one AI company’s protocol that other vendors grudgingly support.” It’s closer to what happened with Kubernetes or OAuth: a specification that outgrew its original author and became something competitors converge on because the alternative — everyone building and maintaining their own incompatible tool-calling format — is worse for everyone, including them.
What actually changed, concretely
The governance move matters more than the individual product launches, because it answers the question every developer should ask about any standard: who controls the spec if the group that invented it changes its mind? MCP now sits under the same style of neutral stewardship as Kubernetes, PyTorch, and Node.js — a directed fund with named corporate backers, not a single vendor’s roadmap.
| Vendor | What they shipped | Direction |
|---|---|---|
| ServiceNow | Native MCP server + client in its Zurich release, gated by its own AI Control Tower (identity-verified, permission-scoped, audited) | Both consumer and provider |
| Salesforce | Agentforce MCP client, pilot in July 2025, beta since January 2026 — connects agents to any MCP-compliant server | Consumer, with a hosted server option for its own data |
| Snowflake | A managed MCP server run inside Snowflake under its own OAuth, exposing Cortex Analyst, Cortex Search, and Cortex Agents as tools | Provider |
| Google, Microsoft, AWS, Cloudflare, Bloomberg | Backers of the Agentic AI Foundation that now stewards the MCP spec itself | Governance |
The pattern across all four is the same: these are companies with existing, mature access-control systems (ServiceNow’s AI Control Tower, Salesforce’s org permission model, Snowflake’s role-based access, cloud IAM at the governance layer) choosing to expose that control surface through MCP rather than around it. That’s the detail worth noticing, because it’s also the thing a lot of smaller “we support MCP” integrations skip.
The checklist a standard’s popularity doesn’t replace
None of this makes MCP itself a safety guarantee. A protocol being widely adopted tells you vendors agree on how tools get listed and called — it says nothing about whether a specific server you’re about to connect an agent to implements auth correctly, scopes its tools sanely, or is even the server it claims to be. “MCP support” on a landing page is now common enough to be a checkbox, which is exactly when it stops being a useful signal on its own. Before pointing an agent at anyone’s MCP server — including ours — a few questions are worth answering first:
- Is the tool list real, or a marketing wrapper around three endpoints?
Connect and actually call
tools/list. A server with a handful of narrow, well-described tools is often more trustworthy than one claiming “full API access” through a single do-everything tool, because the narrow server is telling you exactly what it can do. - What authenticates the connection, and what does that credential actually grant? A bearer token, an OAuth flow, an API key pasted into a config file — each has a different blast radius if it leaks. Ask specifically whether the credential is scoped to a workspace/org, or whether it’s an all-or-nothing grant to everything the underlying account can touch.
- Does a consequential action require anything beyond “the agent decided to”? Sending, deleting, paying, or publishing something through an MCP tool should not be indistinguishable from a read. Check whether the server or the client you’re using enforces any confirmation step, and don’t assume the model itself will reliably ask first.
- Is there an audit trail you could actually pull if something went wrong? ServiceNow’s approach — every MCP action running through a central control tower — is the shape to look for: something that answers “what did this agent do, as whom, and why” after the fact, not just a server log that rotates out in a week.
- Who governs the spec this server implements, and is the server actually current with it? MCP’s spec has moved fast; a server built against an early draft may be missing auth or capability-negotiation features a newer one has. The current specification is worth a quick check against whatever the server’s own docs claim to support.
Run through that checklist against Norbelys’s own MCP server and the answers are meant to hold up:
a real, generated tool list you can inspect with tools/list rather than a marketing summary; a
bearer credential scoped to a single organization that can’t reach data outside it; explicit
confirmation required before anything consequential — sending, deleting, archiving — executes; and
every call attributable back to the credential and org that made it.
Why this matters more now than it did a year ago
When MCP was one company’s protocol, the honest skepticism was “will this still exist in two years.” That’s a much weaker objection today — a spec governed by a multi-vendor foundation and implemented natively by enterprise platforms with entirely different businesses (a CRM, a data warehouse, an ITSM platform) is not going anywhere. What replaces that skepticism is a narrower, more useful one: not “is MCP real,” but “is this particular server, from this particular vendor, implementing it the way the spec — and basic security hygiene — expects.”
Norbelys’s own MCP server is one instance of that pattern: a real tool list, a real auth mechanism tied to an org-scoped credential, and every tool call attributable back to the credential that made it — the same bar this post argues you should hold any MCP server to, including ours. If you’re picking your first client to connect, the setup guide for Claude, Cursor, and Windsurf walks through exactly that connection, and scoping the key you hand an agent covers the credential side once you’re connected.