Block an action a signed mandate does not permit: amount, payee, audience, currency, window, intent.
Scored across 3 tools
The three tools have clearly distinct purposes: check a single action, explain the rule order, and check a sequence. Each description explicitly states when to use it and when not to, including cross-references to the others (e.g., 'use drift_check for that').
All tools follow a consistent 'drift_' prefix with a concise noun/verb suffix (check, explain, session), forming a predictable and readable naming pattern tied to the server's name.
With three well-scoped tools, each earns its place: enforcement checking for one action, multi-action sequence checking, and a static rule explanation. Nothing feels redundant or missing for the stated mandate-enforcement purpose.
The surface covers the core enforcement lifecycle: checking single actions, checking sequences, and explaining rules. It explicitly scopes out signature verification and actual execution, which are handled by other systems, so no critical gaps exist within its domain.
Check ONE proposed action against a signed agent mandate BEFORE it happens. Returns {"verdict": "ALLOW"|"DENY", "rule": } plus a report with a ledger fingerprint.
Six rules run in a fixed order, so a refusal names the most important reason rather than an incidental one: amount, payee, audience, currency, window, intent. Anything unclassified is DENY.
Use immediately before any action that spends money, moves a credential or changes state on someone else's behalf.
Do NOT use to: verify mandate signatures (AP2 does that, and this server runs after signature verification), execute the action (it only decides), or certify that an intent is truthful — "intent" arrives from the agent and is untrusted input. An agent that lies within its limits still leaves a ledger entry; proving what really happened is attest's job, not this one's.
Amounts are integer minor units (cents), never floats. Window bounds are inclusive. Fully idempotent: the same inputs always give the same verdict and the mandate is never mutated.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action being proposed. | |
| mandate | Yes | The signed authority being enforced. Treat as read-only input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/non-destructive): deny-by-default for anything unclassified, fixed rule ordering so refusals name the most important reason, inclusive window bounds, integer minor units only, and the explicit warning that 'intent' is untrusted agent input. It also clarifies the mandate is never mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then usage, then exclusions, then numeric conventions. Every sentence carries decision-relevant information; nothing is filler despite the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent what comes back (verdict, rule name, report with ledger fingerprint). Combined with the nested 2-parameter schema and full annotation coverage, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds real semantics on top — amounts are integer minor units never floats, window bounds are inclusive, and the mandate must be treated as read-only input. It doesn't add per-field syntax beyond that, so it stops short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: check ONE proposed action against a signed agent mandate BEFORE it happens. It even specifies the return shape (verdict/rule plus a report with a ledger fingerprint) and the fixed six-rule order, so the agent knows exactly what this tool decides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('immediately before any action that spends money, moves a credential or changes state on someone else's behalf') and three explicit exclusions with named alternatives: signature verification belongs to AP2, execution is not this tool, truthfulness certification belongs to attest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the six enforcement rules in the exact order they are applied, each with a plain-language reason it exists. Takes no mandate and no action.
Use when a refusal did not make sense, or before explaining a denial to someone whose mandate was rejected. A refusal you cannot explain is one nobody will trust.
Do NOT use it to check an action — it performs no check, and cannot predict which rule will fire, only the order they are tried in.
Constant output, fully idempotent, opens no files, contacts no host.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds real value beyond them: 'takes no mandate and no action', 'constant output', 'opens no files, contacts no host', and the key limitation that it cannot predict which rule fires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core behavior, then usage, then exclusions, then side-effect guarantees. Slightly padded by the rhetorical line 'A refusal you cannot explain is one nobody will trust', but overall tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully specifies the return ('six enforcement rules in the exact order... each with a plain-language reason') and its constant nature. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description confirms 'takes no mandate and no action', matching the empty schema, but there are no parameters whose meaning could be enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return the six enforcement rules in the exact order they are applied') and notes the accompanying reason text. It distinguishes itself from 'drift_check' by clarifying that it performs no check and only reveals rule ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('a refusal did not make sense', 'before explaining a denial') and an explicit when-not ('Do NOT use it to check an action'), plus the limitation that it cannot predict which rule fires. This routes the agent cleanly between itself and drift_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a SEQUENCE of proposed actions against one mandate. Returns {submitted, allowed, denied, breach_by_rule, fingerprint}.
Use for a whole plan or batch, not a single action — use drift_check for that. The fingerprint is the point: rewriting or reordering any earlier decision changes the hash, so tampering with history becomes visible instead of silent.
Do NOT use it to execute the actions, or as evidence of what actually happened. It reports what was PROPOSED against a mandate you supply.
Read-only. Idempotent for a fixed action list. Amounts in integer minor units, as in drift_check.
| Name | Required | Description | Default |
|---|---|---|---|
| actions | Yes | Proposed actions in order. Order affects the fingerprint. | |
| mandate | Yes | Same shape as in drift_check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive=false, but the description adds genuinely new behavioral context: the fingerprint's purpose (rewriting or reordering any earlier decision changes the hash, so tampering becomes visible) and the epistemic limit that it reports what was PROPOSED, not what happened. That is substantive disclosure beyond the structured hints, and it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and return shape, then routing, then exclusions, then behavioral notes. Every sentence carries distinct information; nothing is padding or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the return keys ({submitted, allowed, denied, breach_by_rule, fingerprint}), and both nested-object parameters are anchored to drift_check's shape given the rich schema coverage. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds a unit convention not present in the schema ('Amounts in integer minor units, as in drift_check') and reinforces that ordering affects the fingerprint, giving useful extra meaning above the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and scope ('Check a SEQUENCE of proposed actions against one mandate'), states the return shape, and explicitly distinguishes itself from the sibling drift_check ('for a whole plan or batch, not a single action'). An agent can select between drift_session and drift_check without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Both directions are covered: use for a whole plan or batch, and the explicit routing rule 'use drift_check for that' for single actions. It also states what NOT to use it for ('Do NOT use it to execute the actions, or as evidence of what actually happened'), which prevents the most likely misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
drift_checkdrift_explaindrift_sessionCheck an agent action against its operator's mandate before acting: permit, deny or escalate.
Fail-closed action authorization, MCP risk scanning, x402 checks, and signed receipts.
Hosted x402 preflight for action authority, payment mandate, destination, expiry and replay.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
Add one secure layer between your agents and this server.