Topic starter
06/06/2026 11:32 am
TL;DR: REST still fits developer-written integrations, but AI agents need runtime discovery, stateful sessions, and scoped authorization, so MCP layers over existing APIs rather than replacing them, according to WorkOS. The governance issue is not protocol choice alone, but whether identity, context, and tool access are being governed for non-human actors that decide at runtime.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “MCP vs. REST: What's the right way to connect AI agents to your API?”.
Key questions
Q: How should security teams handle tool discovery for AI agents in MCP environments?
A: Security teams should treat tool discovery as a privilege boundary, not a convenience layer.
Q: Why do REST APIs become harder to govern when the client is an AI agent?
A: REST assumes a caller that already knows the endpoint and the sequence of calls it needs.
Q: What signals show that an API layer is not ready for agentic access?
A: If the interface depends on static docs, manual adapters, or human memory of which endpoint to call next, it is not ready for an agent that reasons dynamically.
Practitioner guidance
- Define agent-facing tool boundaries Separate developer APIs from agent-facing tools so each MCP capability has a narrow, outcome-oriented scope and a clear allowed action set.
- Require scoped OAuth 2.1 tokens Issue authorization tokens that are tied to the user, the session, and the exact tool scope needed for each invocation.
- Preserve session context for multi-step workflows Design MCP interactions so the agent can carry state across related actions without rebuilding context from scratch at each call.
Bottom line: MCP is best understood as an agent-facing layer over existing REST APIs, not as a replacement for them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 12:23 pm
Runtime discovery is a governance boundary, not just a protocol feature. The article shows that MCP gives agents the ability to discover tools at the moment of use, which changes who controls access and when. That means API governance can no longer assume the client is a fixed, pre-integrated application. Practitioners should treat capability discovery as part of the authorization model, not as a convenience layer.
A few things that frame the scale:
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
A question worth separating out:
Q: Should organisations keep REST, add MCP, or replace one with the other for AI agents?
A: Most organisations should keep REST for existing applications and add MCP as the agent-facing layer. REST remains the execution backend for traditional clients, while MCP adds discovery, session state, and scoped authorization for non-human consumers. The decision is not binary; it is about aligning each protocol with the type of caller that uses it.
👉 Read our full editorial: MCP and REST together: what AI agent APIs need