Topic starter
06/06/2026 11:18 am
TL;DR: MCP has become the de facto protocol for connecting AI systems to tools and data, with roughly 97 million monthly downloads across the Python and TypeScript SDKs and a 2026 roadmap focused on enterprise readiness, according to WorkOS. The governance question is no longer whether MCP will spread, but which identity, consent, and session controls can keep up when AI clients reach into many systems at once.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Everything your team needs to know about MCP in 2026”.
By the numbers:
- The Python and TypeScript SDKs alone see roughly 97 million monthly downloads.
Key questions
Q: What breaks when MCP sessions rely on persistent client secrets?
A: Persistent client secrets create a standing-access model that is hard to reconcile with MCP’s stateful sessions and multi-step workflows.
Q: Why do MCP tools create a governance problem for IAM teams?
A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login.
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions.
Practitioner guidance
- Define MCP client trust boundaries Map every MCP host, client, and server to an owner, an access purpose, and a revocation path before approving production use.
- Prefer session-scoped authorization Replace durable OAuth secrets with task-bound sessions where the agent cannot renew access without an explicit new approval.
- Inventory remote MCP servers List every server that exposes tools or resources, then classify whether it is local subprocess, remote HTTP, or user-facing UI enabled.
Bottom line: MCP is no longer just an integration layer, it is an access model that needs identity governance, session control, and clear ownership across hosts, clients, and servers.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 12:01 pm
MCP is becoming an identity architecture problem, not just a protocol choice. Once AI clients can discover tools, hold sessions, and invoke actions across multiple systems, the control point shifts from integration logic to delegated identity governance. That puts MCP squarely into the same decision space as service accounts, OAuth clients, and workload identities. Practitioners should treat the protocol as an access substrate that needs lifecycle ownership, not as a neutral transport layer.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between MCP integration and normal API integration?
A: Normal API integration usually connects one application to one service with bespoke code and narrow, predefined calls. MCP standardises that interaction so models can discover tools and invoke them through a shared protocol, which improves portability but also expands the governance burden. Practitioners must add identity, scope, and approval controls around the protocol.
👉 Read our full editorial: MCP in 2026: architecture, auth, and enterprise readiness