Skip to main content
Glama

Guard: would a move be allowed?

guard
Read-onlyIdempotent

Dry-run a task transition before attempting it: verify whether approve, complete, or similar actions are allowed, see refusal reasons, and test proof without writing anything.

Instructions

Simulate whether a task transition would be permitted BEFORE trying it: a dry-run of the workflow gate that writes NOTHING. Use it to answer "may I approve/complete/… this task, and if not, why?" without making the move. It reads the task’s current state and returns the gate’s own verdict: ALLOWED (with the state the move would reach) or REFUSED (with the gate’s reason: an illegal move, missing proof, or who == which). Pass the same proof you would carry (note/reason/feedback) to see if that proof suffices. It also refuses, with the write’s own code and words, what this machine’s key would be refused in the task’s tree: a key protected by a passphrase that is not set, an agent that tree does not enrol where the person’s key that would sign instead is not at hand, an agent retired (AGENT_NOT_ENROLLED, REVOKED_KEY, KEY_IS_PROTECTED, AGENT_NAME_REFUSED, AMBIGUOUS_MEMBERSHIP). It cannot know a wrong passphrase, a record busy at that moment, or another write changing the task before your move; and with no key on the machine yet it says who is missing, though the first write makes the key. The verdict is paired with your current focus. The task is looked for in EVERY project of this workspace, as task_transition looks; an id no tree of it holds is refused, naming the projects searched. Read-only. Runs: thisSession is true only when THIS connection opened it: false means another session on this machine, live or abandoned, which the record cannot tell apart. An OPEN run carries ageSeconds, and idleSeconds only once it has recorded something, so NO idleSeconds means it recorded nothing; both compare this clock with the writer’s. EVERY run, open or ended, carries wrote: one {kind, count} per kind recorded in it, commonest first, never absent, EMPTY meaning nothing was recorded; the run’s own start and end are not counted, and audit_timeline serves the facts. An open run is no proof of a live session; mnema run end <id> --which <agent> closes one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "action": "<action>"
    },
    "name": "guard"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe task id to test.
noteNoSimulate the note (approve, complete).
whichNoSimulate an executing agent (must differ from the session actor).
actionYesThe transition to simulate.
reasonNoSimulate the reason (block, cancel, reopen).
feedbackNoSimulate the feedback (request_changes).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only and non-destructive behavior, and the description adds substantial context: the tool returns ALLOWED or REFUSED, names refusal reasons and key-related error codes, and states its limitations such as not knowing a wrong passphrase or concurrent writes. It also explains that the task is searched across every project and that no key present changes how refusal is reported.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is front-loaded and clear, but the description becomes very long and dense, with extensive parenthetical details and a large paragraph about runs, ageSeconds, idleSeconds, and wrote that is hard to connect to selecting or invoking guard. Much of this wording does not earn its place for the core dry-run purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does explain the core return semantics: ALLOWED with resulting state, or REFUSED with the gate's reason, plus limitations and search scope. It is mostly complete for a complex simulation tool, though the run-related output details are confusing and make the overall return behavior less crisp.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains each parameter. The description adds only modest meaning by grouping note/reason/feedback as proof to test for sufficiency and by mentioning 'who == which' in refusal reasons, but it does not provide syntax or additional parameter constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: simulate whether a task transition would be permitted before trying it, with no write. It clearly distinguishes this dry-run gate from the actual move and from task_transition by saying it writes nothing and returns the gate's verdict.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: use before trying the transition to answer whether a move is allowed and why, and pass the same proof you would carry. It does not explicitly state when not to use the tool or name an alternative to perform the real move, so it falls short of full 5-level guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.