MCP’s new primitives make agent middleware obsolete

MCP’s new elicitation and structured output features replace a lot of custom agent middleware.

Model Context Protocol just crossed an important line: the work teams have been hand-coding around agents is becoming part of the protocol itself. MuleSoft’s update for its MCP Connector adds elicitation, structured output, and prompt templates, which means the system can ask for missing inputs, constrain responses, and standardize prompts without every workflow carrying its own brittle glue code. That is not a cosmetic upgrade. It is the difference between building agent behavior as an application concern and treating it as infrastructure.

Custom clarification code is a tax, not a feature

For the last year, every serious agent workflow has needed its own clarification layer. If a tool call is missing a region, account ID, approval flag, or date range, engineers have written branching logic to stop, ask, validate, and retry. That code is repetitive, hard to test, and easy to break when a new tool or downstream system appears. Elicitation moves that interaction into the protocol, which matters because the protocol is the only place every tool invocation already passes through.

The practical win is not abstract elegance. It is fewer one-off handlers scattered across services, fewer prompt hacks buried in orchestration code, and fewer failures caused by the agent guessing when it should have asked. MuleSoft’s framing is blunt: the middleware teams have been building per workflow is now a protocol primitive. That is the right direction. If a pattern repeats across agents, it belongs below the application layer, not inside each product team’s custom logic.

Structured output is the difference between a tool call and a usable result

Agents do not fail only when they lack input. They fail when a tool returns a wall of text that is technically correct but useless for the next step. A typical MCP tool response can include status narratives, metadata, protocol summaries, and commentary. That is fine for humans reading logs. It is poison for an agent that needs to extract one field, compare one value, or trigger one follow-up action. Structured output turns the response into something the model can reliably consume instead of interpret by guesswork.

This matters because the agent stack is only as strong as its weakest handoff. If the input is clean but the output is noisy, the system still degrades into prompt parsing and regex patching. Structured output removes that brittle middle layer. It gives the agent a contract, and contracts are what make automation scale. Without them, teams end up overfitting their orchestration to one tool’s phrasing instead of building reusable behavior across tools and domains.

Prompt templates are not a convenience layer, they are governance

Prompt templates are often sold as a developer productivity feature, but the deeper value is control. A shared template standardizes how agents ask, how they frame tool use, and how they handle uncertainty. That reduces drift between teams, which is one of the fastest ways agent systems become unmaintainable. When every workflow invents its own prompt style, the organization does not have a platform. It has a pile of experiments.

Templates also make review and auditing possible. Security teams can inspect one approved pattern instead of chasing dozens of prompt variants hidden in codebases and low-code flows. Product teams can tune behavior centrally instead of rediscovering the same failure modes in every integration. MuleSoft is right to bundle templates with elicitation and structured output, because the three features work as a system: ask better questions, receive cleaner answers, and keep the interaction consistent.

The counter-argument

The strongest objection is that protocol features do not eliminate application complexity, they relocate it. Elicitation still needs product decisions about when to interrupt the user, what data to request, and how much context to reveal. Structured output still depends on schema design, and bad schemas create their own rigidity. Prompt templates can also become a new layer of central control that slows teams down if every change requires platform approval.

That criticism is valid, but it does not defeat the case for these primitives. It only defines the boundary. Teams should not pretend a protocol can replace judgment, policy, or domain design. What it can replace is the endless duplication of clarification, parsing, and prompt formatting logic across every workflow. The right answer is not to keep rebuilding the same middleware in every app. It is to standardize the common mechanics and reserve application code for the decisions that actually differ.

What to do with this

If you are an engineer, stop writing custom retry-and-clarify flows for every agent tool and push those behaviors into shared MCP patterns wherever your stack allows it. If you are a PM, define the moments where the agent must ask, the fields it must return, and the exact shape of the handoff before shipping another workflow. If you are a founder, treat elicitation and structured output as platform features, not nice-to-haves, because the teams that standardize them will ship faster, break less, and spend less time debugging agent folklore.