TL;DR: XMCP lowers the friction to build and deploy MCP servers with file-system routing, middleware chaining, and one-command production rollout, according to WorkOS’s MCP Night 2.0 demo recap. That convenience expands the MCP attack surface faster than most identity governance programmes can scope, classify, and secure it.
NHIMG editorial — based on content published by WorkOS: MCP Night 2.0 demo recap on XMCP
Questions worth separating out
Q: How should teams govern MCP servers that can be deployed with minimal setup?
A: Teams should govern MCP servers as exposed access surfaces, not just as developer tooling.
Q: Why do file-based MCP routing patterns increase identity governance risk?
A: File-based routing increases risk because a new file can create a new callable capability without a separate authorisation workflow.
Q: What breaks when authentication middleware is inconsistent across MCP tool paths?
A: When middleware is inconsistent, some tool paths may inherit weaker checks, different header handling, or missing policy enforcement.
Practitioner guidance
- Inventory every exposed MCP tool as a governed access path Create a register of all tools surfaced by each MCP server, including file-based routes, middleware dependencies, and downstream resources touched by the tool.
- Gate production deployment before credentials are attached Block MCP servers from reaching production endpoints until the tool list, transport, authentication chain, and secret sources have been approved.
- Verify middleware consistency across every route Test whether all tool paths inherit the same authentication checks, header handling, and policy enforcement.
What's in the full article
WorkOS's full recap covers the live demo mechanics this post intentionally leaves for the source:
- The exact XMCP tool syntax shown in the demo, including schema and metadata structure for LLM-friendly tool discovery
- The middleware chaining example used to add authentication and request handling to individual tools
- The production deployment flow from local build to Vercel endpoint and Cursor configuration
- The internal Express.js and Next.js integration pattern for teams extending an existing application
👉 Read WorkOS's recap of XMCP and the MCP Night 2.0 demo →
XMCP and MCP servers: what changes for identity governance teams?
Explore further
XMCP exposes the governance gap between tool creation and tool authorisation. The framework makes MCP server development feel lightweight by collapsing routing, scaffolding, and deployment into a simple workflow. That ease is the problem for identity teams, because every new tool is also a new permissioned action surface. The implication is that MCP governance cannot be bolted on after developers have already published capabilities.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: What is the difference between local MCP development and production trust?
A: Local development is about speed and iteration, while production trust requires identity, access, and logging controls that survive external exposure. A server that works on a laptop may still be unsafe to connect to real credentials or data sources. The difference is not technical complexity but governance scope: production adds accountability, inventory, and approval requirements.
👉 Read our full editorial: XMCP makes MCP server creation easier, but governance risk remains