Skip to main content
Security 2026-07-04

How to Enforce Tool Order in MCP Sessions (Tool Sequence Policies)

MCP Trail

MCP Trail Team

Security Team

How to Enforce Tool Order in MCP Sessions (Tool Sequence Policies)

How to Enforce Tool Order in MCP Sessions (Tool Sequence Policies)

Plenty of operational rules aren’t about whether a tool may run — they’re about when. Deploy only after the test tool succeeded. Delete only after a backup ran. Send externally only after a review step. Humans internalize these; agents follow them right up until a long context, a distracting instruction, or a prompt injection makes them skip straight to the destructive step. Each individual call still looks legitimate — the allowlist can’t help you, because the tool is allowed. Just not yet.

Tool sequence policies on MCP Trail encode order as an enforced rule: per MCP session, you declare which tools must have run successfully before another tool may execute. The gateway tracks each session’s history and blocks (or escalates) out-of-order calls.

What a sequence rule looks like

A rule names a guarded tool and its prerequisites, matched against the session’s actual call history:

  • deploy_service requires a prior successful run_tests
  • drop_table requires a prior successful create_backup
  • send_external_report requires a prior successful review_summary

“Successfully” matters — a failed prerequisite doesn’t count. And the scope is the session, so an agent can’t satisfy a prerequisite with something another session did last week.

Step 1: Create your free MCP Trail account and add a server

Sign up at app.mcptrail.com and route the server (or bundle — rules can span member servers’ tools) through the gateway.

Step 2: Open the Tool order section

Under Guardian servers, open your server → Security tab → Tool order. Build rules in the visual editor, picking tool names from the server’s synced catalog so they exactly match upstream tools/call names — no typos silently disarming a rule.

The tool sequence policy editor with a prerequisite rule

Step 3: Sanity-check the dependency graph

The editor renders your rules as a dependency graph — worth a look before saving. Two things to catch: accidental chains (A requires B requires C when you only meant one hop) and cycles that would make a tool unreachable.

The dependency graph visualizing tool prerequisites

Step 4: Choose what a violation does

Per policy, an out-of-order call is either denied with an explicit error (the model reads it, runs the prerequisite, retries — self-correcting in practice) or routed to the approval queue, for rules where a human should decide whether the skip is legitimate.

Step 5: Verify with a session

From the playground or a client, call the guarded tool cold — it should bounce with the sequence violation. Run the prerequisite, call it again — it should pass. The Audit log shows both, which doubles as documentation of the control for anyone auditing later.

Audit entries showing a sequence violation and the subsequent allowed call

Sequence policies vs. workflows

Related, different jobs — and they compose:

  • A sequence policy is a constraint: “X must not run before Y.” The agent still drives.
  • A composite workflow is an automation: the fixed pipeline runs as one tool.

Wrap the happy path in a workflow; keep the sequence rule as the backstop for when the agent goes off-script.

FAQ

Does a prerequisite from a previous session count?

No — rules are evaluated per MCP session. Each new session starts with an empty history, which is exactly what you want for rules like “backup before delete.”

What if the prerequisite ran but failed?

It doesn’t count. Prerequisites must have run successfully — a failed run_tests doesn’t unlock deploy_service.

What does the agent see when a call is blocked?

An explicit policy error naming the violated rule. Models handle this well: the typical response is to run the missing prerequisite and retry.

Can rules reference tools from different servers?

Within one Guardian server’s catalog, yes — and on a bundle, the merged catalog means rules can span member servers.

“Never deploy before tests” shouldn’t depend on the model’s mood. Create your free MCP Trail account and make it a rule.

Share this article