Topic starter
18/08/2026 2:35 pm
TL;DR: Deterministic validation and sandboxed execution still mattered, even as MCP tooling added cost and context overhead by encoding workflows the model could already execute through simpler skills and shell access, according to TENZIR. The broader lesson is that MCP should expose external capabilities, not preserve brittle orchestration layers that age faster than the models they serve.
Editorial analysis by NHI Mgmt Group, based on content published by TENZIR: “We did MCP wrong”.
By the numbers:
- The MCP approach made 61 tool calls, while the Skills approach made 52.
- TENZIR said 35 of those MCP calls were specialized tools, including 12 run_pipeline calls and 9 docs_read calls.
Key questions
Q: What breaks when MCP tools mainly wrap commands the model can already run?
A: The control stops adding capability and starts adding friction.
Q: Why do over-scripted AI workflows create hidden cost even when they work?
A: Because the model has to re-read structured instructions, schemas, and documentation on every turn.
Q: How do teams know whether an AI tool is actually adding control value?
A: Look for a real change in the authority model.
Practitioner guidance
- Cut redundant orchestration tools Review MCP servers for tools that only wrap shell commands, documentation reads, or scripted step ordering.
- Measure cached-token overhead Track cached tokens, tool-call counts, and context growth for each workflow so you can spot interfaces that are cheap in design but expensive in runtime.
- Preserve engine-level validation Keep schema checks, sandboxed execution, and output validation inside the backend where they enforce behaviour rather than merely instruct it.
Bottom line: MCP becomes inefficient when it is used to preserve model workflows that simpler tooling can already execute, because the wrapper adds cost without changing the underlying authority.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:21 pm
Capability exposure, not workflow scripting, is the right control boundary for AI tooling. The article shows that once a model can already use shell, files, and documentation, a custom MCP layer often adds ceremony rather than security value. In governance terms, the useful boundary is the point where a system gains access to an external capability, not the point where a tool dictates the sequence of steps. Practitioners should treat orchestration-heavy wrappers as candidates for removal unless they change the authority model.
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: How should organisations split skills-style instructions from MCP access?
A: Put portable workflow knowledge in documentation or skills that can travel with the model, and keep MCP focused on connected capabilities such as live system access, stateful orchestration, and execution boundaries. That separation makes review easier and reduces the chance that workflow logic gets mistaken for a security control.
👉 Read our full editorial: MCP workflows are overfitting AI models to rigid tooling