Notifications
Clear all
Topic starter
18/08/2026 3:00 pm
TL;DR: Scaling MCP adoption creates three compounding problems, configuration sprawl, tool overload, and orchestration inefficiency, and that layered controls can separate connection management, tool discovery, and workflow execution, according to Stacklok. The governance gap is no longer just access to one server, but consistent control over many NHI-like tool connections across developers and AI agents.
NHIMG editorial — based on content published by Stacklok: Optimizing multi-MCP workflows
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern access to MCP registry-discovered servers?
A: Security teams should treat registry-discovered servers as governed non-human access, not as simple developer convenience.
Q: Why do multi-MCP setups create so much operational risk?
A: They multiply credentials, endpoints, and tool definitions faster than teams can govern them.
Q: What breaks when too many tools are exposed to an AI assistant?
A: Selection quality drops because the model must evaluate more options than it can efficiently reason over.
Practitioner guidance
- Centralise MCP connection ownership Move credentials, endpoints, and transport settings into a single governed gateway so every developer and agent inherits the same policy state.
- Reduce exposed tool surface area Limit each assistant or persona to the smallest practical tool set and hide irrelevant tool definitions by default.
- Treat composite workflows as privileged automation Version-control workflow definitions, require review before changes, and separate approval-gated actions from read-only steps.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- The vMCP gateway configuration model for centralised authentication, token exchange, and tool scoping.
- The MCP Optimizer benchmark data showing how just-in-time discovery changes token usage and tool selection accuracy.
- The composite tool YAML pattern for parallel execution, conditional branching, and approval-gated steps.
- The development roadmap for MCP sampling and scripting extensions that change workflow expressiveness.
👉 Read Stacklok's analysis of multi-MCP workflow scaling and governance →
Multi-MCP workflows: what changes when agents and tools multiply?
Explore further
18/08/2026 3:40 pm
Multi-MCP sprawl is now an identity governance problem, not an integration convenience issue. Once assistants and developers rely on dozens of back-end servers, the question is who owns the credentials, who scopes the tools, and who can prove those decisions were applied consistently. That moves the control discussion from developer ergonomics into lifecycle governance for non-human access. Practitioners should treat every new MCP connection as a governed identity object, not a shortcut.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How should teams decide when to use composite tools instead of prompt chaining?
A: Use composite tools when a task involves repeatable multi-step coordination, parallel actions, or approval gates that do not require the model to improvise each step. If the goal is consistent execution across models and teams, declarative orchestration is easier to govern than prompt instructions.
👉 Read our full editorial: Multi-MCP governance needs layers for scale, cost, and control
