Before a standard, every integration invented its own conventions for schemas, auth and errors, and the agent runtime accumulated one adapter per customer system. MCP replaces that with a common shape: a server exposes tools, a client discovers and invokes them.
What it gives you
- A uniform description format, so tools can be discovered rather than hard-coded.
- A transport, so invocation looks the same regardless of what is behind it.
- Composability: an integration written once works with any client that speaks the protocol.
What it leaves to you
Authorisation, tenancy, rate limiting, audit logging, schema governance and cost control. These are application concerns and it is correct that a transport protocol has no opinion about them - but a plan that treats adopting MCP as replacing an integration layer will be wrong about roughly half the work.
Agent runtime
- loop
- tool selection
Broker (yours)
- tenant scoping
- authorisation
- rate limits
- audit
- schema pinning
MCP
- discovery
- schemas
- invocation
Servers
- CRM
- calendar
- internal APIs
The under-appreciated risk
Discovery is dynamic, and behaviour must not be. If an upstream server changes a tool schema, instructions written against the old shape stop working silently. Pin schema versions per tenant and treat an upstream change as a migration with a diff, not as an automatic upgrade.
The second one: tool descriptions arriving over a protocol are still prompts. Two servers exposing the same capability with differently-worded descriptions produce different agent behaviour, and now the wording is outside your repository.