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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds two genuine behavioral details beyond that: the tokens are an estimate computed as chars/4, and only the top-5 tools are reported (an explicit truncation rule). It does not say whether counts are cumulative for the session or since the last call, which is the main remaining gap.

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?

It is short and front-loaded with no filler, but it is written as a compressed noun phrase rather than a sentence, with no verb and no leading statement of what the tool returns. Brevity here shades into under-specification rather than efficiency.

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?

An output schema exists, so return values need not be explained, and with no parameters the surface area is small. Still, for a session-scoped metrics tool the description omits whether measurements are cumulative, per-session or reset, and how it relates to the sibling status tools, so it is only minimally complete.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly introduces no argument concepts.

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 the resource loosely ('Session tool-output') and lists three reported metrics (chars, estimated tokens at chars/4, top-5 tools), so an agent can infer this is a stats/introspection tool. However, there is no verb and no differentiation from siblings such as guard_status, which likely also reports session state, leaving the exact purpose ambiguous.

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?

There is no guidance on when to call this versus guard_status or the other guard_* introspection tools, and no stated trigger such as 'call when you need to check context budget usage'. The agent must infer usage entirely from the fragmentary noun phrase.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds genuinely non-obvious behavior: the model cannot delete its own seed-injected guardrails, which explains why a remove call may be rejected. It does not say whether adds persist across sessions, whether non-seed removals are irreversible, or how failures surface.

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?

The action enumeration is front-loaded in the first sentence, and the seed-constraint restriction follows as the one behavioral caveat that matters. The parenthetical example (02-evidence-before-success) is illustrative rather than filler, though the sentence is slightly dense.

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?

For a three-parameter store tool with an output schema, the description covers the action vocabulary, per-action parameter needs, and the important ownership restriction on seed constraints. It leaves minor holes around persistence and error behavior, but nothing that would cause an agent to call it incorrectly.

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 description coverage is 0%, so the description carries the full burden and mostly succeeds: it enumerates the legal action values and binds text to add and id to remove. Remaining gaps are nullability (text and id default to null but the action-specific requirement is only implied) and the id format or source of valid ids.

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 concrete resource (a contract store) and enumerates its three operations (list, add with text, remove with id), so an agent can tell what the tool does at a glance. It is distinguishable from siblings like guard_evidence or guard_note by the word "contract," though it does not explicitly contrast itself with them.

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?

Each action carries an inline precondition — add needs text, remove needs id — which is actionable routing guidance. It also states an exclusion: seed constraints cannot be removed by the model and must be handled by the owner via CLI or /guard-contract. It stops short of saying when to prefer this store over sibling tools such as guard_note or guard_journal.

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

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

Annotations already declare idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds that a verdict is computed against thresholds, but it never says where thresholds come from, whether the call can fail or block, or why readOnlyHint is false for what reads like a pure analysis operation.

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?

One short sentence with no filler, and the diff target is front-loaded before the outputs. It is dense to the point of being cryptic ('numstat stats + verdict vs thresholds'), but nothing is wasted.

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?

An output schema exists, so return values need not be described, and the single optional parameter is covered. Still missing is how thresholds are configured or overridden and what the verdict values mean, which matters for an auditing tool whose whole purpose is producing a pass/fail judgment.

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 0% for the single `baseline` parameter, so the description carries the burden. It does so usefully by explaining that baseline is a git ref and that HEAD is the implicit default, which is meaning the bare nullable string schema does not convey.

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 action and output: it diffs against HEAD or a baseline ref, produces numstat statistics, and yields a verdict compared against thresholds. That distinguishes it reasonably from siblings like guard_status or guard_verify, though 'audit' and 'thresholds' remain jargon without a stated meaning.

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?

There is no guidance on when to call this versus guard_verify, guard_status, or guard_preflight, nor any stated prerequisite. The only implied usage is 'when you want a diff-based verdict', which is thin for a family of twelve guard_* tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral information: the two-mode behavior (list vs. full record) and what a full record contains ('digest tail, why, fix'), which tells an agent it can retrieve remediation detail rather than just a count.

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?

Two short sentences, zero filler, and the primary behavior (recent runs) is front-loaded before the id-mode caveat. The parenthetical 'digest tail, why, fix' is terse but each item conveys a distinct payload field.

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?

The tool is simple (2 optional params, output schema present), so return-value detail need not be spelled out. The one real gap is the undocumented limit parameter; otherwise an agent has enough to call both modes 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 0%, so the description carries the burden. It explains evidence_id well ('one run in full by evidence id'), but says nothing about 'limit' — neither its default of 5 nor what it bounds (run count vs. record size). Half the parameters are therefore undocumented anywhere.

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 the resource precisely — 'recent verification runs' for the list mode and 'one run in full by evidence id' for the detail mode — so an agent knows exactly what comes back. It does not name any sibling (guard_journal, guard_status, guard_recall are adjacent in scope) to differentiate itself, keeping it short of a 5.

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?

The second sentence implies the selection rule: pass an id when you need to 'read back' a past failure rather than just count it. That is real but implicit guidance, and there is no explicit statement of when to use guard_journal or guard_status instead, nor any note that both modes are optional (0 required params).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — that limit is silently clamped — but does not state the range or whether a warning is returned, so the disclosure is vague rather than actionable.

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?

Two short sentences with the main action front-loaded and no filler. The phrase "at the journal boundary" is slightly opaque and could be tightened, but the structure is efficient overall.

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?

An output schema exists, so return values need no explanation, but with 0% parameter coverage the description should have supplied allowed 'type' values and concrete limit bounds; it does neither. Given eleven sibling tools with adjacent semantics, the lack of any disambiguation leaves the definition incomplete for correct tool selection.

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 description coverage is 0%, so both parameters fall entirely on the description. It only restates that 'type' filters by journal type without listing valid values (the field is a bare string with no enum) and says 'limit' is clamped without giving the bounds or the default of 5. Neither parameter gains usable meaning beyond the schema.

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 uses a specific verb and resource ("Read recent journal entries") and adds a scope detail (optional filtering by journal type). It does not distinguish this tool from plausibly overlapping siblings such as guard_recall or guard_evidence, so it falls short of a 5.

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?

There is no when-to-use or when-not-to-use guidance, and none of the eleven siblings are named as alternatives. The phrase "optionally filtered by journal type" hints at a use case but leaves the choice between guard_journal, guard_recall, and guard_note entirely to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. However, the description reads like a passive analysis call while annotations say it is not read-only; it never discloses what state it touches, per-session scope of that state, or rate/cost limits. That is the exact gap the description should close, and it does not.

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?

It is a single short fragment with zero filler, which is efficient. But the terseness is achieved by dropping the verb and the trigger condition, so the brevity costs clarity rather than earning its place.

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 parameters and an existing output schema, the description does not need to explain return values, which lowers the burden. Still, for a non-read-only tool sitting among eleven similarly named guard_* siblings, the description leaves the core question — when to call it instead of the others and what it mutates — unanswered.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the implicit session scoping. Baseline for a 0-parameter tool applies, with a slight mark down because 'this session' is the only semantic hint about what the empty argument list means.

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 resource ('failing-command streaks for this session') plus a secondary output ('change-strategy advice'), so the agent can infer it reports on repeated failures. But it is a noun phrase without a verb, and it never distinguishes itself from the eleven sibling guard_* tools (guard_status, guard_verify, guard_loop_check being easily confused).

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?

There is no when-to-use guidance at all: no trigger condition (e.g. 'call after two consecutive failures'), no exclusion, and no pointer to an alternative such as guard_status or guard_verify. The agent must guess when this tool is appropriate versus its very similar siblings.

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

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

Annotations already mark this as a non-read-only, non-destructive, non-idempotent write, and the description adds behavior the annotations cannot convey: an 'agent' provenance tag is attached automatically, entries are durable, and 'lesson'-tagged entries survive the recent-entry cap by being re-injected into the session brief every turn. That persistence/rotation distinction is exactly the kind of effect an agent needs to know before writing. It stops short of saying whether repeated identical calls duplicate entries, which matters given idempotentHint=false.

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?

The purpose is front-loaded in the first clause, and the two tag-behavior sentences each add distinct information. Minor waste from reStructuredText double backticks and the trailing rationale 'so the next similar situation starts from that outcome,' which restates the value of recording an outcome.

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?

An output schema exists, so return values need no explanation, and the tag semantics are handled well. Still missing are the semantics of the required 'type' field and any statement separating this tool from guard_journal, which leaves real ambiguity for a three-parameter write tool.

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 description coverage is 0%, so the description must carry the parameter load. It explains the 'tags' parameter well by naming the values 'lesson', 'satisfied', and 'dissatisfied' and their effects. But the required 'type' parameter is never mentioned at all, and since no parameter has an enum, an agent must guess its valid vocabulary — a significant residual gap.

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 opens with a specific verb and resource: journaling an agent-authored entry with a durable 'agent' provenance tag. That is far more concrete than the tool name alone. However, it never distinguishes this from the sibling guard_journal, which reads like it could do the same thing, so an agent cannot fully disambiguate on the description.

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?

There is real guidance on how to use tags: 'lesson' for precedents that get re-injected each turn, 'satisfied'/'dissatisfied' for recording owner reactions. But that is guidance on tag choice, not on when to call guard_note rather than guard_journal or guard_recall, so the when-to-use signal is only implied.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful content scope by saying the tree is 'bounded' and that language counts and conventions files are included, but it does not explain the bounds, size limits, or whether conventions files are optional. This is helpful but not rich behavioral disclosure beyond the annotations.

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?

The description is extremely concise and contains no wasted clauses. However, it is a sentence fragment rather than a structured statement, and the single phrase does not front-load an action or usage cue.

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 parameters, read-only annotations, and an output schema present, the description does not need to explain return structure in detail. It sufficiently names the main outputs, though it could better explain what 'bounded' means and when an agent should call this rather than another guard tool.

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?

The tool has zero parameters, so there are no parameter meanings for the description to clarify. The baseline for no parameters is 4, and nothing in the description creates confusion about inputs.

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 specifies the resource content clearly: a bounded repository tree, language counts, and conventions files. It does not use a verb such as 'returns' and does not differentiate this orientation step from siblings like guard_status or guard_preflight. Still, an agent can infer the tool's output scope more specifically than the name alone.

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?

There is no guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. The description only lists returned artifacts, leaving the agent to infer whether this is an initial orientation call or a prerequisite for other guard tools.

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

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

The annotations already declare idempotent, non-destructive, closed-world, and not read-only behavior, so the description only needs to add domain context. It adds the scope of what is checked, but does not explain side effects, failure behavior, or what 'configured tools' means; the apparent inspection framing sits somewhat awkwardly with readOnlyHint=false without explicitly contradicting it.

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?

The description is a single compact fragment with no wasted sentences and the scope is front-loaded. However, the telegraphic phrasing ('Tool presence/versions... + git-repo check') is terse enough to reduce immediate clarity.

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?

Because there are no parameters, an output schema exists, and annotations cover safety traits, the description does not need to explain return values. Still, with many sibling guard tools and no guidance on when preflight should be invoked or what it gates, the definition is only minimally complete.

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?

The tool takes zero parameters, so parameter semantics are largely moot and the baseline is 4. The description appropriately does not waste space documenting nonexistent inputs.

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 the resources being checked: configured tools, their presence/versions, and a git-repo check. This is clear enough to understand the tool's purpose, but it does not explicitly distinguish it from siblings such as guard_status or guard_verify.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The word 'preflight' implies an early check, but the description does not operationalize that for an agent choosing among many guard_* siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description still adds real value beyond them: match ranking ('match strength, then recency'), the trusted/agent provenance labels on hits, the 0–20 clamp with default 5, and the side effect that a tag filter silently excludes evidence rows. 'Does not create the store' partially restates the read-only hint but clarifies behavior on a missing store.

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?

The purpose is front-loaded and the remaining sentences are dense with non-redundant facts. The phrasing is telegraphic and the keyword sentence is a run-on that takes a second read, but almost nothing is wasted.

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?

For a six-parameter, zero-schema-coverage query tool, the description covers every parameter, the filtering interaction between tags and evidence rows, ranking and provenance of results, and the limit clamp. With an output schema present, return-shape documentation is correctly omitted.

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 description coverage is 0%, so the description carries the full burden and does so: it defines query keyword matching as case-insensitive substrings over text/cmd/digest with AND semantics, states that ev-NNNN keywords also match evidence ids, explains tags are AND and exclude tagless evidence rows, enumerates the type values, and notes evidence_id tolerates zero-padding (ev-7 == ev-0007). Every one of the six parameters gains meaning not present in the schema.

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 opening line gives a concrete verb+resource ('Search the retained journal and evidence window') plus a distinguishing constraint ('No embeddings'), so an agent knows exactly what class of retrieval this is. It does not explicitly contrast itself with the closely related siblings guard_journal and guard_evidence, which would have made the differentiation airtight.

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?

Usage is only implied through the parameter semantics — e.g. directing exact-id lookups to evidence_id, verify-run lookups to cmd, and category filtering to type. There is no explicit statement of when to pick this over guard_journal or guard_evidence, and no stated exclusions.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is partly covered. The description adds only the content inventory; it does not explain the notable readOnlyHint=false (what state does a "dashboard" mutate?) or whether calling it resets counters such as loop streaks. 'Dashboard' leans toward a passive read but does not explicitly contradict the annotation, so no contradiction is flagged.

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?

Nine words, front-loaded with the category label, no filler or repetition. The telegraphic field list is efficient, though the fragment style ('diff delta', 'loop streaks') costs a little readability.

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?

An output schema exists and there are no parameters, so the bar is low and the description is close to sufficient. The gap is that several listed fields are project-specific jargon an agent cannot interpret, leaving it unsure what the dashboard actually tells it.

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?

The tool takes zero parameters, so the baseline is 4 and the description has no parameter semantics to carry. Nothing is misleading about the empty schema.

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 identifies the tool as a "Dashboard" and enumerates the telemetry it surfaces (session, diff delta, loop streaks, evidence count, contract size, last verify), so an agent can guess it aggregates run state. However, there is no verb and no statement of what the tool actually does or returns, and nothing distinguishes it from siblings like guard_orientation or guard_recall, which likely also summarize state.

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?

There is no guidance on when to call this versus the eleven sibling guard_* tools. An agent facing guard_orientation, guard_verify and guard_recall simultaneously gets no signal about which is the orientation entry point and which is the verification step.

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

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

Goes well beyond the annotations: discloses shell=True verbatim execution with the caller's privileges, that nonzero exits never raise, that masked success (`|| true`) is labelled UNTRUSTED, and that stdin is closed to protect the MCP protocol. The destructive/openWorld hints are reinforced rather than contradicted; the only gap is what gets recorded when the timeout 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?

Five dense sentences, front-loaded with the primary action and artifact, then safety caveats. No filler and no restatement of the tool 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 an output schema present, return shape need not be spelled out, and the description still previews the recorded tuple and the failure text. Near-complete for a destructive, open-world execution tool; the timeout path is the one behavior left undescribed.

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 0%, so the description carries the burden and largely does: `command` is explained as running verbatim under a shell with the caller's privileges and closed stdin, and `timeout_s` is bounded to [1, 900] with a stated default of 180 in the schema. Missing is the consequence of hitting the timeout (kill semantics, recorded exit value).

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 (run a command) plus the side effect and artifact (records id, exit, digest into verify_runs.jsonl), which is a distinct role from the read-side siblings like guard_evidence and guard_status. An agent can tell this is the execute-and-attest tool without opening the 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?

Usage is implied rather than stated: the 'evidence ledger, not a sandbox' framing tells the agent this is for commands whose outcome must be attested, but no sibling is named and there is no explicit when-not-to-use (e.g. use guard_preflight before, guard_evidence to read back).

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