Should your MCP tool router use interaction history in 2026?

Use interaction history in an MCP tool router only as versioned, observable input: resolve the current authorized tool set first, record the history and candidates behind the choice, retain a stateless fallback, and prove the added state improves accepted outcomes on your workload. History can supply useful task context, but it is not permission, truth, or a substitute for a current tool-policy decision.

Start with the current tool surface, then add history

The router should make two separate decisions:

1. What tools are currently available and authorized for this request?
2. Which of those candidates best fits the work already completed?

The first comes from the current discovery and policy path. The second is where a bounded history window may help. MCP clients discover tools through tools/list; the available set may change over time and may vary with request authorization. Servers that advertise listChangedshould notify connected clients when that set changes. Refresh or invalidate a cached candidate set at that boundary rather than letting yesterday's selection record resurrect a tool that is no longer present for the request.

Tool descriptions and annotations do not change that rule. The MCP specification requires clients to consider annotations untrusted unless they come from a trusted server. A routing score can prioritize a candidate, but the host still needs its own authorization and policy check before a consequential call.

What the ACL evidence actually shows

The peer-reviewed ACL paper ACE-Router studies a learned history-aware router. It builds a graph of candidate tools, synthesizes multi-turn trajectories, and evaluates the resulting router on the MCP-Universe and MCP-Mark benchmarks.

53% → 48%

MCP-Universe overall score without history

60% → 52%

MCP-Mark overall score without history

Those ablations support testing whether prior task state changes selection quality; they do not establish the same result for a different tool inventory or production workflow. The reported router is fine-tuned from Qwen3-8B with LoRA, so treat the paper as evidence for an experiment design, not a transfer guarantee across model families, hosts, authorization schemes, or tool catalogs.

Make the routing decision replayable

For AgentOps Hardening, make the router's input and outcome inspectable. The following is Bonfire's implementation pattern, not an MCP-required schema:

routing_request_id
tool_set_version              # current discovery/policy snapshot
authorization_context_version # policy or entitlement snapshot
history_window_id             # exact bounded prior events considered
candidate_tool_ids            # after current policy filtering
selected_tool_id
selection_reason              # structured reason, not only prose
fallback_path                 # stateless selector | human escalation | stop
tool_call_outcome
accepted_task_outcome

Compare history against a stateless baseline

Do not compare a new router only with its own previous release. Run the same versioned evaluation set through two explicit selectors:

Measure accepted task outcome, wrong-tool calls, policy rejections, fallback use, and selector cost for your workload. Those measurements are Bonfire guidance; the ACL paper reports benchmark routing accuracy, not a required telemetry model or your production acceptance metric.

Add freshness and failure boundaries before rollout

History is useful only while its references remain valid. Put a hold or fallback between selection and invocation when any of these conditions occurs:

• The tool-set or authorization version changed since the candidate list was created.
• The history record points to a missing, withdrawn, or now-disallowed tool.
• The selected tool cannot explain its relevance using the current request and a structured routing reason.
• The call is consequential and the stateless baseline, a policy check, or a human reviewer disagrees.

These are operating controls, not MCP mandates. The protocol supplies the discovery and change-notification boundary; the host supplies policy, fallback, and escalation behavior.

When history is worth the added machinery

Start with a bounded trial when tool choice depends on prior results, such as a workflow where one lookup narrows the next eligible action. Keep the stateless path as the rollback and comparison route. If history does not improve accepted outcomes or introduces stale-state incidents, remove it from the selection path rather than accumulating an opaque layer.

First, build a custom MCP server that survives production. Then keep the router behind the same authorization, audit, and recovery boundaries used to securely expose a private MCP server, and put router evidence alongside the rest of an agent observability dashboard. That is what makes routing an operable AgentOps decision instead of a clever prompt trick.

Scope and caveats

The ACL result is peer-reviewed benchmark evidence, not proof that a learned history-aware router is better for every deployed MCP system. MCP does not standardize this routing architecture. Do not use a past route as authorization for a current tool call, and do not treat an annotation as a trust boundary without a trusted server behind it.