MCP workflows are overfitting AI models to rigid tooling

At a glance

What this is: TENZIR argues that its MCP setup over-engineered model workflows, with custom wrappers adding cost and context overhead while delivering little beyond what simpler Skills and shell access could already do.

Why it matters: For IAM and NHI practitioners, the relevant lesson is that control design should separate true capability from workflow ceremony, especially when AI agents or tooling can execute tasks directly through simpler, auditable interfaces.

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.

Context

MCP becomes inefficient when it is used to preserve a workflow that the model can already execute with basic shell, file, and documentation access. In that case, the control problem is not capability exposure but orchestration overhead, because every extra wrapper increases token consumption, maintenance burden, and the chance that the interface ages faster than the model.

For identity and access governance, the important distinction is between tools that grant a system real external authority and tools that merely script how a model should behave. When AI workflows are wrapped in rigid steps, teams can mistake process friction for control strength, even though the actual enforcement often sits elsewhere in validation, execution boundaries, or underlying infrastructure.

TENZIR’s example is typical of teams that optimize for reliability before measuring whether the model still needs the scaffolding they built.

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. You get more tool calls, more cached context, and more maintenance, but not more security or reliability. At that point the better design is to keep only the parts that change authority or enforce execution, and remove the rest as workflow overhead.

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. That increases cached-token load, adds latency, and makes the interface age faster than the model capability it was meant to support. The cost is not just compute, but governance debt from keeping obsolete scaffolding in place.

Q: How do teams know whether an AI tool is actually adding control value?

A: Look for a real change in the authority model. If the tool only restates a task the model can already perform through shell, files, or documentation, it is probably narrative control rather than enforcement. If it adds sandboxing, validation, or authenticated access to live systems, it is doing real work.

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.

Technical breakdown

Why MCP wrappers become workflow debt

MCP is useful when it connects a model to external systems it cannot otherwise reach, such as stateful services, live infrastructure, or sandboxed execution. It becomes workflow debt when the server mainly repackages shell commands, documentation lookups, and scripted task sequencing. At that point the model is not gaining new authority or reach, only a more expensive path to the same outcome. The deeper problem is that the server starts to encode old assumptions about how much guidance the model needs. As model capability rises, those assumptions decay quickly, but the wrapper remains in place and keeps charging operational overhead.

Practical implication: Prune MCP tools that only restate basic developer actions and keep only the interfaces that add real external capability.

Context bloat versus capability gain in AI toolchains

Structured tool responses can inflate the context window because every schema, metadata block, and documentation chunk must be read and often cached again across turns. That makes a toolchain look disciplined while quietly increasing the compute cost of every interaction. In practical terms, the AI is paying to re-ingest infrastructure it did not need to see in the first place. This is different from deterministic validation, where strict checks happen in the engine and create real control value. The architectural question is whether a given tool reduces uncertainty at execution time or merely adds more text for the model to process.

Practical implication: Measure cached-token growth alongside tool-call counts so you can remove wrappers that create context load without reducing risk.

External capabilities belong in the engine, not the recipe

The article draws a clean line between capabilities the model cannot replicate and recipes it can now compose on its own. Sandboxed execution, schema validation, live system access, and persistent connections are legitimate engine functions because they enforce or expose something outside the model. By contrast, step-by-step orchestration, local documentation bundling for online workflows, and other prompt-like guidance are increasingly just instructions in disguise. This is the key design shift: move control enforcement downward and let the model decide sequencing where the risk is only workflow order, not authority or safety.

Practical implication: Keep deterministic validation and authenticated execution in the backend, and let the model handle task sequencing from documented capabilities.

NHI Mgmt Group analysis

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.

MCP overfitting creates governance debt because the control age differs from the model age. The tool may be reliable on day one, but the model capability curve changes faster than the interface contract. That means control design can become stale even when the implementation still works, which is a classic governance failure mode in fast-moving AI environments. The named concept here is workflow overfit, where process structure survives after its original justification has disappeared. Practitioners should periodically test whether the model still needs the scaffolding.

Deterministic validation remains the part of the stack that actually earns its keep. The article is persuasive precisely because it does not argue for abandoning control, only for moving the control to the layer that can enforce it. Validation that checks schema, execution safety, or output constraints is materially different from guidance that simply tells the model how to think. In identity terms, the lesson maps to boundary enforcement: do not over-invest in instructions when the real assurance belongs at the point of execution. Practitioners should preserve engine-level controls and strip away redundant workflow narration.

The intersection with NHI governance is real when AI tooling becomes a proxy identity for system access. Once the model is invoking commands, reading docs, or delegating tasks, the practical question becomes what authority that non-human actor actually has and how much of it is embodied in wrappers rather than policy. This is especially relevant for environments that already manage service accounts, workload identities, or agent privileges. The control problem is no longer just model quality. It is whether the AI’s effective permissions are transparent, bounded, and revocable. Practitioners should govern AI toolchains as identity-bearing systems, not as harmless automation.

Portable workflow knowledge should live outside connected infrastructure. The article’s distinction between skills and MCP is a useful governance pattern because it separates reusable instructions from authenticated runtime access. That reduces the temptation to bury process logic inside stateful integrations that are harder to audit and easier to overgrow. For AI programmes, this is a useful way to think about maintainability as well as control: documentation carries the portable knowledge, while the engine holds the privileged capabilities. Practitioners should keep those layers separate so review and change management stay tractable.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Workflow overfit: AI control layers age quickly when they encode a recipe the model can already infer, so teams should keep only wrappers that change authority or enforce execution. That is the governance lesson here, and it applies equally to AI tooling, service orchestration, and other non-human workflows that drift from their original purpose.

For identity-led programmes, the useful question is whether an AI tool has a bounded permission set or whether its privileges are implicit in a pile of orchestration logic. The more the system relies on scripted steps instead of explicit execution boundaries, the harder it becomes to audit, revoke, or explain what the non-human actor can actually do.

For practitioners

• Cut redundant orchestration tools Review MCP servers for tools that only wrap shell commands, documentation reads, or scripted step ordering. Retain them only if they materially change authority, safety, or access boundaries.
• 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.
• Separate portable knowledge from connected access Store workflow instructions in documentation or skills, and reserve MCP for live connections, authenticated state, and stateful external systems.
• Re-test workflow scaffolding regularly Revalidate any AI tool that encodes a fixed recipe whenever model capability changes, because controls built for older models can become pure overhead.

Key takeaways

• 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.
• The article’s evidence shows that faster execution is not the same as better control, especially when cached context and tool calls rise sharply.
• The strongest design choice is to keep deterministic validation and external capability access in the engine, while removing workflow recipes that the model can now infer on its own.

Key terms

• Workflow Overfit: A condition where a control layer encodes a task sequence that was useful for an earlier model capability level but no longer adds real value. The result is extra cost, extra context, and slower governance decisions without a corresponding gain in safety or authority clarity.
• Capability Layer: The part of a system that exposes real external actions to an AI model, such as execution, validation, or authenticated access to live services. In governance terms, it should change what the model can do, not merely tell the model how to do it.
• Deterministic Validator: A deterministic validator is a rule-based check that returns the same result for the same input. In GenAI governance, it is used for objective conditions such as secrets exposure, PII leakage, jailbreak attempts, toxicity, or gibberish, where repeatability matters more than interpretive nuance.
• Cached Tokens: Previously processed context that a model reuses during a session, often making structured workflows more expensive than they first appear. When tool responses are large or repetitive, cached tokens can become a hidden cost driver and a signal of over-engineered orchestration.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security practitioners design controls that stay effective as tooling, workflows, and delegated access patterns change.