Adopt MCP as our default agent-integration standard?
Model Context Protocol release candidate locked May 21. 97M monthly SDK downloads. CIO: 'suddenly on every executive agenda.'
The question
Should we standardize on MCP for every agent ↔ tool integration we ship from now on, or wait for the spec to address its remaining enterprise-auth gaps before committing the integration surface?
The premise
- Team
- ~50 engineers, ~10 actively building AI features, single MLOps engineer. AI work pulls from feature-shipping capacity — any new commitment has to trade against the roadmap. Each customer-facing agent currently has 3-6 hand-coded tool integrations; rewrites are real engineering cost.
- Compliance
- SOC2 Type II in scope. EU customer data subjects us to GDPR plus the EU AI Act's August 2026 GPAI-deployer obligations. AI Act traceability obligations push us toward standardized integration surfaces that can be inventoried.
- Stack
- 11 production agents. Tool integrations today: REST APIs to our own services (auth via internal service tokens), Slack/Salesforce/Zendesk (OAuth), Postgres read replicas (per-agent scoped credentials), GitHub (PAT-per-agent). ~40 distinct tool integrations total across the agent fleet. No MCP usage today.
- Budget
- Monthly AI spend ~$30K with quarterly board visibility. Approvals required for sustained jumps >20%. Cost-per-outcome metrics in place; finance asks for unit economics by use case. Standardization is mostly engineering time, not external spend.
Is MCP actually production-ready for an enterprise integration surface?
Partial. The spec is stable for stdio + SSE transports and the SDK ecosystem is real. The enterprise-auth story is weakest — OAuth-on-MCP is still in flux as of May 2026. For internal-only agents calling internal MCP servers, ready today. For customer-facing agents calling third-party MCP servers, not yet.
What's the realistic adoption path for our 11 agents?
MCP for all NEW tool integrations starting Q3 2026. Existing integrations stay as-is — port only when we're already touching that integration for other reasons. Don't do a big-bang rewrite; the win is consistency for future tools + cleaner agent code, not retiring working integrations.
What if MCP loses momentum to a competing standard?
Low risk. MCP-built integrations are mostly thin wrappers over the underlying API; porting away is a wrapper-rewrite, not a re-integration. The architectural lock-in is shallower than e.g. LangChain's. Worst case: 2-4 engineer-weeks to rewrap our then-existing MCP integrations if we have to migrate.
Counsel's position
Standardize your new agent-tool integrations on the Model Context Protocol immediately by wrapping your existing REST APIs with MCP bridges, and handle enterprise authentication by piggybacking on your current internal service tokens and OAuth flows.
Verdict
The verdict: Separate your agent logic from tool integrations using standardized protocols.
Separate your agent logic from tool integrations using standardized protocols
Given your 40 distinct tool integrations, decoupling how your 11 production agents reason from how they access data prevents custom glue code sprawl.
Deploy specialized MCP gateways to control token costs and enforce compliance
Given your $30K monthly AI budget and board visibility, managing agent chattiness through business-context gateways prevents unexpected cost spikes.
Wrap your existing REST APIs with an HTTP-to-MCP bridge
Given your limited engineering capacity, you can expose your current internal service endpoints to MCP without rewriting the underlying backend code.
Read another verdict
- Kill every AI pilot that can't show ROI in 90 days?
- Use AI to flatten middle management this year?
- Stand up a FinOps practice for tokens and GPUs now?
- Replace customer support with AI — or avoid the Klarna outcome?
- Crack down on shadow AI, or sanction it with guardrails?
- Red-team our own AI agents before shipping them?
- Give every AI agent its own scoped identity before scaling?
- Adopt Microsoft Agent 365 as our agent control plane?