A company picks Copilot, wires it into SharePoint and a couple of internal APIs, trains everyone, and signs the contract. Eighteen months later the pricing changes, or a competitor's model is suddenly better at the one task that matters, and switching means rebuilding every integration from scratch. The model was never the expensive part. The wiring was.
That wiring is the asset. The provider sitting on top of it (Claude, ChatGPT, Copilot, or something you run on your own hardware) is a client you can replace. Once you separate those two things, vendor lock-in stops being a strategic problem and becomes a configuration detail.
The piece that lets you separate them is the Model Context Protocol. Anthropic published MCP in November 2024 as an open way for an AI model to call tools and read data through a standard interface. The part that matters for a company isn't the spec itself, it's what the spec made possible: you describe your systems as MCP tools once, and any compliant assistant can use them.
Read that diagram top to bottom. The provider at the top is rented. The agent definition in the middle (its instructions, the list of tools it's allowed to call, the scopes attached to each) is a contract you write. The MCP servers at the bottom, sitting behind your own identity provider, are the part you build and keep. Swap the top and the bottom two layers don't notice.
Here's the division of labor that makes it work. Each MCP server exposes a set of tools, which are just your systems and apps described in a way a model can call: look up this customer, read this document, create this ticket, fetch this person's leave balance. That's all an MCP server is, a typed list of actions against software you already run.
The model is the driver. Someone types a request in plain language, and the model decides which tools to call and in what order, then turns the structured results back into an answer a person can read. Nobody learns an API. They ask, and the model does the translating in both directions. This is the part that's genuinely hard, and it's also the part you can swap, which is the whole trick: the work of making your systems usable in plain language sits in a layer you don't own and can replace.
Because the tools are discrete, you compose them. Read a PDF, extract the fields, match the customer in the CRM, draft a reply, file a ticket: five tools, one request, an actual workflow. Each tool is a building block any agent can pick up, so what you wire for one task becomes parts you reuse in the next. A handful of well-chosen tools turns into dozens of workflows without new integration work.
This stopped being one vendor's idea
If MCP were still just Anthropic's protocol, betting on it would be its own kind of lock-in. It isn't. OpenAI adopted MCP in March 2025 across its Agents SDK, the Responses API, and the ChatGPT desktop app. Google confirmed support in Gemini around the same time. Microsoft showed MCP support in Windows 11 at Build 2025, and in December 2025 Microsoft 365 Copilot declarative agents gained MCP support too, which means an agent built for Copilot can reach the same tools and data a Claude or ChatGPT agent uses.
Then Anthropic gave the protocol away. On December 9, 2025 it donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. Competitors who agree on almost nothing now share governance of this one thing. The same announcement put the adoption numbers in context: more than 10,000 active public MCP servers, 97 million-plus monthly SDK downloads across Python and TypeScript, and over 75 connectors in Claude alone.
A standard governed by a neutral foundation and implemented by every major provider is exactly the kind of thing worth building on. The point of an MCP server you write is that it works in ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code without you porting anything.
OAuth is what makes this safe to put in front of real systems
A protocol that connects AI to your CRM is only useful if it respects who's allowed to see what. The design here is better than it had to be, and the assumption that MCP plus a corporate identity provider gives you a reusable, secure endpoint is correct.
An MCP server acts as an OAuth 2.1 resource server. It doesn't handle logins. It validates tokens issued by a separate authorization server, which is your existing identity provider: Microsoft Entra, Okta, Auth0, or Keycloak. The flow follows standard OAuth conventions the spec spells out, including protected resource metadata so clients can discover where to authenticate, resource indicators so a token meant for one server can't be replayed against another, and mandatory PKCE. When a user connects an assistant, they consent through your IdP, and the MCP server enforces scopes and role-based access internally on every call.
Two things follow from that. First, the AI provider never sees a password or holds a long-lived credential; it carries a short-lived, scoped token your IdP issued and your server checks. Second, because the authentication is plain OAuth, the same protected endpoint works for any compliant client. You don't build one auth path for Claude and another for Copilot. You build one, and the spec mandates the rest.
Atlassian's production server is a clean example. Its Remote MCP Server for Jira and Confluence uses OAuth 2.1 so that, in their words, all actions respect the user's existing access controls. An agent can't read a board the person driving it couldn't already read. That's the property you want from every server you stand up: every action runs as the user who asked for it, with that user's permissions, not a superset of them.
That guarantee is only as good as your configuration. The protocol gives you the mechanism; you still have to scope it correctly. Hand a server a broad token, or skip the per-tool scope checks, and the agent ends up with more reach than the person driving it, which is a setup mistake rather than a flaw in MCP. Done right, OAuth means you never have to trust the AI provider with standing access to anything; it gets a short-lived token, for one user, for the scopes you granted, and your server checks all three on every call.
The integration points that actually pay off
Abstract architecture is easy to nod along to, so here's what people are connecting and why.
ChatGPT
Copilot
SharePoint
SalesforceDocument intake is the obvious first win because it's tedious and high-volume. Upload a PDF, have the agent extract the fields, check them against systems of record, and present a filled-in draft for a human to approve. One vendor-reported HR onboarding example describes cutting a two-hour, multi-system process to a 15-minute review with roughly a 70% reduction in processing time per hire. Treat the exact figure as a vendor claim, not an independent measurement, but the shape is real: the work is reading a document and copying its contents into four places, and that's precisely what an agent with the right tools does well.
Customer lookups across CRM and ERP are the second. Connect the agent to the systems where customer state lives and it can pull a customer's history, flag at-risk accounts, or summarize open issues without a human clicking through five tabs. There are MCP servers for Salesforce, HubSpot, and Zendesk, and Microsoft's Power Apps MCP server connects agents to Dataverse tables in Dynamics 365, where they can take a trigger like an incoming email and act on the structured data behind it.
HR and people data is the third, and the one where scoped access matters most. Aggregators like Unified.to expose HR, ATS, and CRM systems through a single MCP layer that handles authentication and permission scopes across hundreds of SaaS platforms, so an agent can answer "how many days of leave does this person have left" without you writing a bespoke integration per system.
You don't have to build all of this. A lot of it already exists as hosted, OAuth-secured remote servers. Cloudflare runs remote MCP servers with Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow, all permissioned through OAuth. For the systems unique to your company, you write the server; for the common SaaS tools, you mostly connect to one.
The most instructive example is a company that went all-in. Block built its MCP servers in-house rather than relying on third-party ones, which gave it control over security and let it tailor integrations to its own workflows. It wired Snowflake, Jira, Slack, Google Drive, and internal APIs into its open-source agent, Goose, and put it in the hands of engineering, data, design, and support teams. Engineering uses it to refactor legacy code and run migrations; support and product teams use it to process tickets and generate documentation. Same plumbing, many consumers.
The honest risks
None of this is free of downside, and the failure modes are specific enough to name.
The big one is indirect prompt injection. If your agent reads a document, an email, or a web page, an attacker can hide instructions in that content and the model may follow them. A related attack is tool poisoning, where malicious instructions are buried in a tool's description or metadata rather than in user input. One write-up reports tool poisoning succeeding 84.2% of the time in controlled testing when agents had auto-approval enabled, which is a reported lab figure rather than a field rate, but the lesson holds: auto-approving tool calls on untrusted input is how you get hurt. Add over-privileged agents, credential sprawl across servers nobody's tracking, and audit blind spots, and you have a real attack surface.
The mitigations are not exotic. The MCP spec's security guidance is direct about the basics: use short-lived tokens, validate every token and its intended audience, scope permissions per tool instead of granting catch-all access, and never roll your own token validation. On top of that, a gateway or proxy in the path gives you one place to enforce policy, log every call, and keep traffic inside your network boundary, which is the pattern enterprise security teams keep landing on. The work here is governance, and it's the same governance you'd want around any system that can touch customer data.
There's a limit worth stating plainly. MCP standardizes how an assistant talks to your tools. It does not yet fully standardize the agent definition itself across providers; efforts like the Linux Foundation's AGNTCY project are working on portable agent descriptions, but that layer is younger than MCP and less settled. So the strong, proven claim is about the tool and data layer: that part is portable today. The agent's instructions and orchestration may still need light rework when you move providers. That's a far smaller cost than rebuilding integrations, which is the cost you're actually trying to avoid.
A plan you can run at your own company
Start by listing the three to five systems an agent would genuinely need to touch. Not everything, the few that show up in the requests people actually make: probably your CRM, your ticketing system, a document store, and one database. Resist the urge to connect everything at once.
Stand up one MCP server in front of the highest-value read path before you build any write path. Customer lookup is a good first target because it's useful immediately and a read can't corrupt anything. Put it behind your existing identity provider with OAuth, so the agent inherits each user's permissions from day one and you never manage a separate set of credentials.
Then prove the portability is real, because that's the whole premise. Point two different providers at the same server, Claude and Copilot, or ChatGPT and a local model, and confirm the tools work in both with no changes to the server. If they do, you've demonstrated that the thing you built is an asset independent of any vendor. If they don't, you've found the gap before it cost you anything.
Add a gateway before you scale, not after. The moment more than one team is using more than one server, you want a single point for policy, logging, and audit. Retrofitting that across a dozen scattered servers is the kind of cleanup nobody enjoys.
Save write actions for last, and scope them tightly. Reading customer data is recoverable; creating a refund or updating a record is not. When you get there, give each write its own narrow scope and keep a human in the approval loop for anything irreversible.
Build the read path for customer lookup this quarter, behind your IdP, and make it work in two providers. That single exercise teaches you more about what MCP is worth to your company than any amount of reading, this post included.
If you'd rather not build the OAuth flow, dynamic client registration, and MCP hosting yourself, ChurroStack handles that layer for you.