What is Model Context Protocol
Model Context Protocol is a common plug so AI apps can use the same tools, like USB for accessories. It is plumbing, not a company strategy, and it does not decide who may update Salesforce.
USB did not create a data-governance programme. A common plug let keyboards, cameras, and drives talk to any computer. It did not decide who may copy the finance drive, or whether a change to the ledger needs a signer.
Model Context Protocol (MCP) is the same kind of open standard for AI. Anthropic announced it as a common plug so AI apps can use the same tools and files, instead of every vendor inventing a one-off connection. The specification standardises how a host calls tools and reads resources.
In one sentence: MCP is plumbing, not a company strategy. It does not decide who may update Salesforce.
Developers already know this pattern from the Language Server Protocol: one language server, many editors, instead of rewriting autocomplete for every IDE. MCP is that idea for tools an AI can call. LSP made language servers interchangeable. It did not make every language server a safe place for customer lists.
Before this standard, every AI product invented its own way to “use a tool.” Teams spent months redoing the same wiring. That cost was real. So is the over-read: “we support MCP” is not “we have enterprise governance.”
Words you’ll hear
- Protocol / standard. Agreed wiring so products can interoperate. At work, this is the USB cable, not the access-control list on the share.
- MCP server / helper. A small programme that says “here are the actions I can take, and here are the files I can show you.” At work, a helper that searches Drive as a superuser is still a superuser.
- Host / client. The AI application that calls the helper. At work, several hosts can speak MCP and still have completely different write gates — or none.
- Tool call. The AI asking that helper to search a folder, look up a ticket, post a message, or query a database.
- Resource. A file or record the helper can expose for reading.
- Connector (Nimbus). A supported, company-controlled integration to a live system — OAuth, scoped to the job, read-only by default. That is the operator-facing story. MCP may sit at a developer edge. It is not a substitute for connectors plus governance.
- Least privilege. Which tools this workstream may call. Importing every available helper is how a demo becomes one actor with every production login.
A tool call can still change production data. The protocol will happily pass that change along. The company still has to decide whether that is allowed. Fail-closed writes, named signers, and quoted payloads live above the plug. See What is write-back governance.
Why you should care
The plug is useful. It is also easy to over-read.
MCP does not decide:
- whose login is used
- whether the AI may only read, or also change a live system
- who must approve a change
- how the company remembers what happened
- which model is used for the step — see What is model routing
Choosing a model is choosing a brain. This standard is choosing hands. A cheap model with dangerous tools is worse than a strong model with none. Decide them separately.
An agentic workflow that imports every available tool is a confused workflow. Plumbing is not a stop condition. Anthropic’s note on building effective agents is about bounding tools and stops, not about collecting helpers.
It affects you if a vendor says “we support MCP” and you hear “we have enterprise governance.” Those are different sentences.
What changes by role
Finance. A helper that can post a journal is a write path, protocol or not. Finance should ask whether the host quotes the payload and requires a named signer, not whether the wiring is MCP. Spend also sits above the plug: tool loops can burn NTUs without a ceiling.
Legal. Processing agreements, purpose, and customer data in helpers running on laptops. Legal should not treat “open standard” as “safe.” A standard plug does not create a DPIA.
Operations. Bounded tool belts per job. Ops should refuse workflows that attach every helper “for flexibility,” and should keep human wait and budget as stops regardless of how tools are wired.
Go-to-market. Faster wiring to CRM and Drive can be good — if the connector is still read-only by default. GTM should not confuse a demo that updates an opportunity via MCP with a governed release.
Security. This is the sharp edge. Helpers run with some identity. Superuser search is still superuser search. Prompt injection can trick a model into requesting a tool call; the OWASP Top 10 for LLM applications is the relevant list. The protocol will not save you. Least privilege, read-only defaults, and fail-closed writes will.
What people get wrong
MCP as governance. Wiring is not a named signer.
MCP as the Salesforce strategy. You still need identity, read versus write, an approver, and a record.
Refusing products that do not speak MCP. Interoperable tools are a plus. Absence of MCP is not absence of a connector. Presence of MCP is not presence of governance.
Replacing the integration platform. MCP standardises how an AI talks to a helper. Your identity, iPaaS, and change-control stack still have to exist.
Assuming retrieval will respect permissions. Only if the helper is built that way. See What is enterprise RAG.
Collecting every server. A large tool belt is a confused agentic workflow and a larger attack surface.
Good looks like: MCP where it reduces duplicate wiring; operator-facing connectors that stay scoped, encrypted, and read-only by default; writes only after sign-off; no belief that the spec implemented your control framework. Failure looks like a laptop running a superuser helper pointed at production.
Think of the stack in layers, or you will buy the wrong layer. MCP is how a host talks to a helper. A connector is how operators attach a live system to a workstream with OAuth and a read-only default. Write-back governance is whether a tool call that mutates production is allowed to execute. The lifecycle graph is whether you can still explain the call next quarter. Model routing is which brain issued the call. None of those jobs is in the spec, and that is fine — specs should stay thin. Trouble starts when a thin spec is sold as the thick programme.
An enterprise AI operating system sits above plumbing the way an OS sits above USB: isolation, permissions, I/O policy, and state. USB made accessories interchangeable. It did not decide who may format the finance drive.
How this shows up in Nimbus
Nimbus’s operator-facing integrations are connectors: scoped per workstream, encrypted per tenant, read-only by default. Action connectors write only after human sign-off. See Integrations.
MCP can be useful at developer edges. It is not the product’s answer to “who may change CRM.” Governance, wiki, and the Lifecycle Graph still sit above any plug.
See Governance and Workstreams.
Questions people actually ask
Is MCP how we should connect Salesforce?
Not by itself. You still need identity, read vs write rights, an approver, and a record. A standard plug does not provide those.
Should we refuse products that don’t speak MCP?
No. Interoperable tools are a plus. Absence of MCP is not absence of a connector. Presence of MCP is not presence of governance.
Does MCP replace our integration platform?
No. It standardises how an AI talks to a helper. Your integration, identity, and change-control stack still has to exist.
Can MCP make retrieval respect permissions?
Only if the helper is built that way. A tool that searches Drive as a superuser is still a superuser.
Is MCP the same as a Nimbus connector?
No. A connector is the operator-facing, company-controlled integration: OAuth, workstream scope, read-only default. MCP is a developer wiring standard that might sit at an edge.
Does the spec require fail-closed writes?
No. The spec does not require a quoted Salesforce payload, a named approver, or a fail-closed write. Those are product and policy choices.
How does this relate to USB and LSP?
USB and LSP are the right analogies: interoperability of accessories and language servers. Neither is an access-control programme. Do not buy MCP as if it were.
Can we let every agent team install their own MCP servers?
That is how you get overlapping write rights and no inventory. Treat helpers like production integrations: owners, scope, and a default of read-only.
Does MCP choose the model?
No. Routing is which brain you pay for. MCP is which hands that brain can use. Decide them separately. See What is model routing.
Is “we support MCP” a good RFP answer for governance?
It is a good answer for tool interoperability. For governance, ask about quotes, named signers, workstream scope, and the lifecycle graph.
What is the security failure mode?
A helper with broad credentials, a host with no gate, and a model tricked into calling update_record. The protocol did its job. Your company did not.
Should customer-facing bots get MCP tools to internal CRM?
That is how a public conversation inherits production hands. Scope tools as tightly as you would scope a workstream — usually, do not.
Related reading
What is an agentic workflow and What is write-back governance.
Sources
See what governed AI looks like on your stack.
Connect your tools, run a workstream, and keep every decision on your ledger - free for 7 days.