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

With no annotations, the description carries the full burden and does so thoroughly. It discloses Pyodide WASM sandboxing, streaming behavior, reactive state mechanics, data injection as globals, and per-call sandbox creation.

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 long but well-structured: purpose, code examples, state handling, charts, layout patterns, then args. Each code sample earns its place for a code-generation tool, and the core instruction is front-loaded.

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?

It covers setup, state, pipes, charts, and layout guidance, which is unusually complete for a two-parameter tool. The lack of an output schema is acceptable since the output is a rendered UI, but the phantom 'sandbox' parameter and lack of explicit error/return behavior keep it from a perfect score.

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%, and the description compensates by explaining 'code' as building a Prefab component tree and 'data' as injected sandbox variables, reinforced by extensive examples. However, it documents a 'sandbox' argument that does not appear in the input schema, which could mislead an agent into passing an unsupported parameter.

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 sentence states a specific action and resource: 'Execute Prefab Python code in a sandbox and render the result.' This clearly distinguishes the tool from the sibling search_prefab_components, which is for lookup rather than execution/rendering.

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 description gives concrete conditions: use the components tool for lookups, wrap with PrefabApp for streaming, use .rx for interactive UIs, and choose Grid vs Row based on layout needs. It does not explicitly contrast with sibling search_prefab_components, but the tool's role is evident from context.

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=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the data is stale by design (last snapshot, not live), and the tool is equivalent to reading a file directly. This is useful transparency about what the tool does and does not reflect.

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?

Three short sentences, each earning its place: the first states the action and resource, the second adds the critical staleness caveat, and the third offers an equivalent alternative. No fluff, and the most important caveat is front-loaded.

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 zero-parameter, read-only, idempotent tool with an output schema, the description is nearly complete. It explains what the tool returns, its staleness limitation, and an alternative. The only minor gap is not describing the structure of the artifact integrity map, but the output schema likely covers that, so the description does not need to.

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 is no parameter semantics burden. The description still clarifies what the returned artifact integrity map represents, which is the closest relevant semantic context. Baseline 4 for zero params is appropriate.

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 states a specific verb ('Return') and resource (the artifact integrity map from .rrt/artifacts.lock.toml), and immediately distinguishes it from a live check by noting it reflects the last snapshot, not current state. This clearly separates it from siblings like rrt_drift and rrt_validate_branch.

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 description explicitly says when to use it (to get the last snapshot) and when not to rely on it ('not current state; run the CLI check to compare against the working tree'). It also names an alternative approach (Read .rrt/artifacts.lock.toml) for clients that can read files directly, which is strong usage guidance.

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?

destructiveHint=true is already declared, and the description aligns with it rather than contradicting it by disclosing the safety default: 'dry_run=True by default' and 'When dry_run=False, checks it out.' This adds real context beyond the annotation — destructiveness is conditional and off by default. It also truthfully discloses that 'nothing enforces that the caller actually uses' the returned commit title.

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?

Roughly four sentences, front-loaded with the core action, and every line earns its place — the git checkout -b comparison and the commit-title caveat add genuine value. The final line packs the commit_type list and dry_run default densely but remains readable.

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 description covers purpose, the two key inputs, the conditional destructive behavior, and even the returned commit title, so the existing output schema need not be elaborated. The remaining hole is the scope parameter — what it maps to in the branch name — which is a minor gap for a moderate-complexity 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 coverage is 0%, so the description carries the full burden and largely delivers: it enumerates the allowed commit_type values (feat|fix|chore|docs|refactor|test|ci|perf|style|build), which the schema omits as an enum, and explains dry_run's effect and default. The one gap is scope, a nullable string whose role in the branch name is never clarified.

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 concrete action — 'Derive a compliant branch name from a type + description' — and names the exact resource (branch) plus the two key inputs. The title reinforces it as a branch-creation tool, and 'Use instead of git checkout -b' explicitly separates it from the standard git approach. None of the many rrt_* siblings competes as a branch-creation tool, so the purpose stands clearly on its own.

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?

'Use instead of git checkout -b with a hand-written name' gives the agent an explicit, actionable comparator that selects this tool over a common alternative. It also prescribes a follow-on usage by returning a Conventional Commit title 'to use for the first commit.' It stops short of exclusions — no guidance on when not to use it, such as when a branch already exists.

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?

With only destructiveHint=true in annotations, the description carries the behavioral burden and does so thoroughly: it states dry_run writes nothing, and an apply touches version targets, pins, changelog, lockfiles, generated assets, and git branch/commit. It also promises changed_paths on every result, so the agent knows what side effects to expect.

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 front-loaded with the purpose, default, and parameter semantics, and every paragraph is information-dense. The final paragraph largely repeats the pipeline stages and adds a defect-history note that is not needed for invocation, so it is not perfectly concise.

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 destructive tool with an output schema, the description covers all parameters, defaults, scoping behavior, side effects, and result fields. Nothing an agent needs to select or invoke it correctly is missing.

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%, and the description fully compensates by enumerating valid level values, defining dry_run's default and effect, and explaining group as a [tool.rrt] version group that can be omitted to bump all groups. This is exactly the semantic information the bare schema lacks.

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 first sentence names a specific action and resource: preview or apply a version bump. It also establishes that this is the full rrt bump pipeline rather than a manual version-string edit, so an agent can tell it apart from inspection tools like rrt_version and from hand-editing.

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?

It explicitly says to use the tool instead of editing version strings by hand, gives the dry_run=True default for safe previews, and explains the group parameter for restricting vs bumping all configured groups. The equivalence to the rrt bump CLI also clarifies when the same repo-wide result is expected.

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 provide readOnlyHint and idempotentHint, but the description adds valuable behavior beyond those tags: the section modes return different shapes (parsed pending entries vs raw file), and it discloses the hook-managed state of the changelog so the agent understands why hand-editing is unsafe. No contradiction with 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?

Four tightly written sentences with no filler: core action first, then when to use it, then the parameter behavior, then the read-only caveat. Each sentence adds distinct information that is not available from the schema or annotations.

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 single-optional-parameter read tool with an output schema, the description covers all decision-relevant context: when to call it, which section value to request, and why it must not be used for writing. Given the large sibling set, the explicit usage triggers and write-route pointer are sufficient to select and invoke this tool 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?

The schema defines only a single `section` string with a default and has 0% description coverage, so the description carries the entire semantic burden. It fully explains the meaningful values ('unreleased' and 'full') and what each returns, which is precisely the missing information an agent needs.

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 an explicit action—'Read the changelog'—and identifies the resource and scope: the Unreleased changelog, with parsed pending entries by default or the raw file in full mode. It also differentiates itself from write workflows by explicitly saying it is read-only, which helps distinguish it from bump and write-oriented siblings.

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 concrete triggers: use before adding an entry to avoid duplication, and before a bump to see what will be promoted. It also tells the agent when not to use it by directing writes to the CLI/hook workflow and warning against hand-editing the [Unreleased] section while that hook is active.

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=true and idempotentHint=true, and the description adds valuable behavioral context: it returns structured data, error handling (typed ConfigError instead of nonzero exit), and explicitly states it does NOT run validation. This goes beyond the annotations and helps the agent understand what to expect from the call.

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 well-structured: it opens with the main purpose, then details what the policy includes, explains the return behavior and error handling, and closes with what it does NOT do and the alternatives. Every sentence earns its place; no redundant or filler content. The most critical info (purpose and when to use) is front-loaded.

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 read-only config reader with zero parameters and an output schema, the description is highly complete. It covers the purpose, the scope of the policy, error behavior, and what it does not do, and provides routing guidance to sibling tools. The output schema presumably documents the return structure, so no further return-value details are needed.

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, and the schema is an empty object with no properties. The baseline for 0 params is 4, and the description doesn't need to add parameter semantics. It does add context about the output being structured data, but that's not parameter-related, so a 4 is appropriate.

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 states the specific verb 'Read' and the resource 'resolved [tool.rrt] policy', enumerating the key contents (version targets, pin targets, changelog file, release branch pattern, folder rules). It clearly distinguishes itself from validation tools by explicitly noting it does not run per-target checks, which separates it from siblings like rrt_release_check, rrt_folder_check, and rrt_docs_check.

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?

It gives an explicit 'when to use' directive: 'Call this before proposing any release-related change' so the agent acts on configured policy. It also states when not to use it (for validation) and names the alternative tools (rrt_release_check, rrt_folder_check, rrt_docs_check) that should be used for those checks, leaving no ambiguity about routing.

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 and idempotentHint. The description reinforces these by stating 'Read-only — never regenerates or writes files' and adds valuable behavioral details: it only covers a specific lockfile, reports skeleton_issues when configured, and mentions CI failure. No contradiction; the description enriches the annotation context.

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 ~100 words and well-organized: it starts with the core purpose, then usage timing, read-only nature, remediation, scope, and additional output. Each sentence earns its place, though it could be slightly tighter. It's not overly verbose and is front-loaded with the essential check action.

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?

Given the tool has no parameters and annotations cover read-only/idempotent, the description provides all necessary context: what it checks, when to run, what to do if stale, scope limitations, and extra output. An output schema exists, so return values need not be described. The description is complete for correct invocation.

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 the input schema is trivially complete (coverage 100%). Per guidelines, a zero-parameter tool gets a baseline of 4. The description adds no parameter-specific semantics because none exist, but this is appropriate.

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 states a specific verb ('Check') and resource ('.rrt/docs.lock.toml') and distinguishes it from sibling tools by explicitly naming what it covers and what it does not (e.g., 'rrt docs map --check has no tool here'). It also mentions additional output (skeleton_issues), making its purpose unambiguous.

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 description gives explicit when-to-use context ('Use after editing any source docstring... before opening a PR'), explains CI failure, and provides an alternative command ('rrt docs generate --format toml') and notes which sibling is not available. This fully routes the agent to the correct action.

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 and idempotentHint, and the description adds useful behavioral detail: it returns one CheckResult per component with ok and severity, and states 'no output parsing.' This gives agents actionable expectations beyond the annotation metadata.

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 compact and front-loaded: purpose, covered components, usage triggers, and return behavior appear in three tight sentences. Every sentence adds useful information with no filler.

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 zero-parameter, read-only diagnostic with an output schema, the description covers what it checks, when to use it, and what the response looks like. Nothing critical is missing for an agent to invoke or interpret this tool 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?

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. Per the 0-parameter baseline, the description does not need to compensate for schema gaps.

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 ('Check') and clearly names the scope: hooks, workflows, and CI artifact-protection. It is not a tautology and gives a concrete sense of what the tool inspects, though it does not explicitly differentiate itself from sibling diagnostics like rrt_doctor_dashboard.

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 description provides explicit trigger conditions: use before recommending a hook or workflow change, and when a hook did not fire as expected. It lacks explicit when-not-to-use guidance or named alternatives, so it stops short of a 5.

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=true and idempotentHint=true. The description adds meaningful context beyond that: it renders a visual UI widget rather than returning data for programmatic processing. This clarifies the human-facing behavior of the tool.

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 sentences with no filler. The first sentence front-loads what the tool displays; the second clarifies its human-facing purpose and routes to the sibling tool for data needs.

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 zero-parameter, read-only dashboard tool, the description is complete: it describes the result contents, the invocation purpose, and the correct alternative if the wrong tool would be selected. No output schema or additional context is 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?

The tool has zero parameters and schema coverage is 100%, so parameter documentation is not needed. The description appropriately explains that the tool renders a UI widget, which is the only invocation-relevant semantic.

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 ('Doctor check results') and specific content (pass-rate Ring, per-check Metrics, status cards, detail table). It also contrasts itself with rrt_doctor, making the purpose and boundary unmistakable.

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?

Explicitly states when to use this tool: when a human needs a UI widget to look at. It also names the alternative (rrt_doctor) for when an agent needs values to reason over, providing a clear when-not condition.

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 and idempotentHint, so the safety profile is clear. The description adds meaningful behavioral context beyond that: the result is stale by design, it reflects the last 'rrt drift generate', and reading the file directly is equivalent. This is exactly the kind of caveat an agent needs.

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?

Three short sentences, each earning its place: the result and source, the staleness caveat with the comparison command, and the direct-file alternative. The key scoping information is front-loaded.

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 zero-parameter, read-only tool with an output schema, the description is complete. It covers what the tool returns, the source file, the staleness semantics, and how to get the same data more directly. Nothing an agent needs to invoke it correctly is missing.

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 and the schema coverage is 100%, so there are no parameter semantics to document. Per baseline rules for 0-param tools, this is appropriately handled; the description focuses on output meaning rather than input details.

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 ('Return'), the resource ('.rrt/drift.lock.toml'), and the content ('file hashes and symbols'). It distinguishes itself from a current-state check by explicitly saying it reflects the last snapshot, and it names the sibling 'rrt drift check' as the alternative.

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?

Explicitly says when to use it (to inspect the recorded snapshot) and when not to (when current state is needed, run 'rrt drift check'). It also provides an alternative via direct file read, which gives an agent clear routing guidance.

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 description goes beyond the readOnlyHint/idempotentHint annotations by explicitly stating 'Read-only — never writes to .rrt/health.lock.toml' and by explaining the fetch_live behavior with endoflife.date versus the bundled snapshot. This adds meaningful behavioral detail without contradicting 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?

Three sentences front-load the core purpose, then provide usage timing, a safety guarantee, and a mode switch. Every sentence adds information without repeating schema or annotations.

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 simple two-optional-parameter read-only tool with an output schema, the description covers purpose, timing, safety, and fetch_live. However, the missing semantics for 'language' and the lack of any mention of alternatives leave small but real gaps for correct invocation and sibling 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 the description carries the burden of parameter explanation. It defines fetch_live clearly, but the 'language' parameter is left unexplained; an agent must guess whether it refers to the host runtime language, project language, or something else. This partial compensation is insufficient.

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 action: 'Check the host runtime and project minimum versions against EOL policy.' This clearly differentiates it from sibling validation/health tools by focusing on EOL policy and version minimums. The title reinforces the purpose without ambiguity.

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?

Explicitly says 'Use before raising or lowering a minimum supported version, and when deciding whether to drop a version from a CI matrix,' giving concrete decision contexts. It does not list exclusions or alternative sibling tools, but the context is clear enough to route an agent.

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=true and idempotentHint=true, so the safety profile is covered. The description reinforces this with 'Read-only — never scaffolds files,' but adds little beyond what annotations provide. It does add context about the check being policy-based, but that's more about purpose than behavior. No contradictions.

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 concise: two sentences with the primary purpose in the first and usage guidance in the second. It is front-loaded and contains no filler or repetition. Every sentence earns 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?

The tool is simple (one optional parameter) and has an output schema, so the description need not explain return values. It covers the tool's purpose and its intended use case. It could mention what happens when no policy or template is found, or explicitly name siblings, but the core context is sufficient for correct invocation.

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 schema has zero description coverage for the single 'template' parameter (array of strings or null). The description clarifies that the check can be against 'named built-in templates', implying the parameter selects those templates, but it does not specify formats or provide concrete examples. It adds meaning but doesn't fully compensate for the schema 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 states a specific action ('Check the repo layout') against a specific resource ('[tool.rrt.folders] policy or named built-in templates'), which is clear and actionable. It implicitly distinguishes from siblings like rrt_tree (which would display layout) and rrt_drift (which detects drift), but it does not explicitly name an alternative. The purpose is unambiguous and not a tautology.

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 description provides explicit use-case guidance: 'Use before creating a new top-level directory or moving a module, so you place it where policy expects.' This tells the agent exactly when to invoke the tool. It does not mention exclusions or alternatives, but the trigger scenario is specific enough.

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=true and idempotentHint=true, and the description adds meaningful behavioral context beyond those: the result is stale by design ('not current state'), the lock file can aggregate three different snapshot commands, and it suggests comparing against the working tree via the CLI. This gives the agent an accurate mental model of what the tool returns.

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 front-loaded with the core purpose in the first sentence, and every subsequent sentence adds essential context: staleness, file-read equivalence, multi-command lock behavior, and live-check alternatives. It is dense but not bloated, with no wasted words.

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 zero-parameter tool with an output schema and safety annotations, the description covers all necessary operational context: what the result represents, how it differs from a live check, which siblings to prefer, and a direct-file alternative. Nothing critical for selecting and invoking this tool correctly is missing.

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 input schema has no parameters, so there is nothing for the description to clarify about parameters. Per the baseline for zero-parameter tools, a 4 is appropriate; the description does not need to compensate for undocumented parameters because none exist.

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 ('Return') and identifies the exact resource ('.rrt/health.lock.toml') plus the result type ('health check results'). It also distinguishes this tool from siblings by explicitly noting it reflects the last snapshot-writing run, not current state, which separates it from live-check tools like rrt_doctor.

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 description gives explicit when-to-use guidance: use this tool for the last recorded snapshot, and use rrt_doctor, rrt_eol, or rrt_folder_check for a live check of a specific part. It even notes that reading the file directly is equivalent and warns that the lock can combine results from three commands, preventing misuse.

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=true and idempotentHint=true, so the safety profile is established. The description adds valuable behavioral context beyond annotations by stating that this renders a human-facing UI widget and is not meant to provide data values for programmatic reasoning, which is important for agent selection.

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 two tight sentences: the first front-loads the dashboard contents in a compact list, and the second adds the crucial routing caveat. Every sentence earns its place, with no redundant or filler language.

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 zero-parameter, read-only, idempotent UI-rendering tool, the description fully covers what the agent needs to know: what the widget contains, that it is for humans, and which sibling tools to use when the actual values are needed. No output schema is present, but the return value is a rendered UI widget, so detailed return-value documentation is not necessary.

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 and the schema description coverage is 100%, so there is nothing for the description to clarify. Per the baseline for zero-parameter tools, a 4 is appropriate; no parameter semantics are missing.

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 a specific resource (health dashboard) and a concrete action ('Renders a UI widget'), then enumerates its contents: metric summary, health Ring, status chart, check cards, detail table. It also explicitly distinguishes itself from rrt_health and rrt_doctor by noting those are for data reasoning rather than visual display.

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 description gives explicit routing guidance: use this tool when a human needs to look at the UI widget, and use rrt_health / rrt_doctor instead when the values are needed for reasoning. This is a clear when-to-use versus when-not-to-use statement with named alternatives.

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 and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by disclosing that the tool renders a UI widget for a human and that the 'apply' step is part of the human workflow, not the agent's tool invocation.

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 two short, front-loaded sentences. Every sentence serves a purpose: the first explains the form flow, the second explicitly warns agents to use the CLI instead. No wasted words.

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 zero parameters, no output schema, and annotations covering read-only/idempotent behavior, the description fully covers what an agent needs: the tool's purpose, its human-only nature, and the direct shell alternative. Nothing is missing.

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, and schema coverage is 100%, so there is no parameter gap for the description to fill. The description mentions 'target format' and 'preview' as conceptual steps, but since no parameters exist, the baseline of 4 is appropriate.

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 clearly states a specific verb and resource: it initializes rrt configuration via an interactive form. It even distinguishes itself from sibling tools by explicitly noting it is a UI widget for a human, not a shell action.

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 description gives explicit when-not-to-use guidance: if you are an agent working from a shell, run `rrt init` directly. This clearly routes the agent to the correct alternative, which is the strongest possible usage guidance.

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?

While destructiveHint already signals destructive potential, the description adds useful context: it shells out to a specific Python command, returns captured output, and defaults to dry_run=True for safety. It does not detail side effects when dry_run is false, but the added context is meaningful beyond the annotation.

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 compact and front-loaded with the core action and safety default. The second sentence explains the mechanism, and the final sentence provides routing advice without unnecessary filler.

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 tool with three optional parameters, defaults, an output schema, and a destructive annotation, the description covers invocation mechanism, output capture, safety default, and usage context. The main gap is undocumented parameter semantics for `force` and `target`, but the overall picture is sufficient for selection and invocation.

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 should compensate for the three undocumented parameters. It only hints that `target` refers to a target format and implies `dry_run` controls safety; `force` is not explained, and valid target values or force/dry_run interactions are absent.

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 concrete action and resource: 'Run rrt init with the given target format.' It also identifies the tool as the submit target of the rrt_init form, which distinguishes it from the shell-oriented rrt_init sibling and makes its role clear.

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 guidance is explicit: this tool is the submit target of the rrt_init form, and agents working from a shell should run `rrt init` directly instead. It names the alternative and gives a clear when-not-to-use condition.

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 and idempotentHint, so safety is covered. The description adds important behavioral context: this tool renders a UI widget for a human, not structured data for computation. It could go further in describing exact output shape, but given the zero-parameter UI nature this is strong.

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 two tight sentences: the first summarizes the widget's contents, the second states its human-facing purpose and routes to alternatives. Every sentence earns its place; no filler or repetition.

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 zero-parameter, read-only UI widget, the description is complete: it explains what is rendered, for whom, and when not to use it. Annotations cover side-effect safety, and the sibling list plus explicit alternative names cover routing. Nothing needed to invoke this tool correctly is missing.

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 semantics to document beyond the schema. With 100% schema coverage and no params, the description's lack of parameter detail is not a gap. The baseline for zero-parameter tools is applied.

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 clearly states this tool renders a UI widget showing all lock files at a glance, including a status donut chart, Carousel, and detail table. It also differentiates itself from sibling tools by explicitly naming rrt_health / rrt_tree / rrt_artifacts / rrt_drift for cases where machine-readable values are needed.

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 description gives an explicit use case ('for a human to look at') and an explicit exclusion: if the agent needs values to reason over, it should call rrt_health / rrt_tree / rrt_artifacts / rrt_drift instead. This tells the agent when to select this tool versus its siblings without 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?

The description goes well beyond the destructiveHint annotation by explaining the two-signal confirmation (dry_run=False AND confirm=True), the default dry-run behavior, and the explicit warning about history-rewriting. This is critical operational detail that prevents accidental destructive actions. No contradiction with 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 compact yet detailed, front-loading the core action before explaining the confirmation logic. The length is justified by the safety-critical nature of the operation. No fluff, though it could be slightly tightened by removing the CLI reference.

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?

Given the complexity and destructive nature, the description covers the essential operational context: default dry-run, confirmation requirement, and the fact it rewrites history. The output schema is present (not shown) so return values are likely covered. It does not explain 'squashed snapshot' or 'tracked content', but these are domain-specific and acceptable.

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 compensate. It thoroughly explains dry_run and confirm, including their interplay. However, it leaves branch, remote, exclude, and message unexplained; though these are fairly self-explanatory from names and defaults, the description does not add value for them. Partial compensation.

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 clearly states the verb (force-push), resource (a single-commit snapshot), and target (a secondary/mirror remote). It distinguishes itself from sibling tools like validation or health checks by emphasizing the destructive publish action. The title adds further clarity with 'destructive' and 'mirror remote'.

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 description provides strong context about when to use it (publishing a snapshot) and implicitly contrasts with non-destructive tools like rrt_validate_branch or rrt_health. It does not explicitly name alternatives or state 'when not to use', but the destructive nature and unique purpose make the intended usage clear.

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=true and idempotentHint=true, and the description mainly reaffirms this with 'Read-only — never modifies files.' It adds the useful consequence that pin drift is silent otherwise, but does not disclose additional behavioral context beyond what annotations already cover.

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?

Three sentences, each with a clear job: define the check, state when to use it, and reassure about side effects. The description is front-loaded with purpose and contains no filler.

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 zero-parameter, read-only, idempotent tool with an output schema, the description supplies everything needed to invoke it correctly: the exact verification scope and the usage trigger context. Nothing material is missing.

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?

There are zero parameters, and the instructions establish a baseline of 4 for such cases. The description still usefully clarifies what the parameterless check examines, even though the empty schema leaves no parameter meaning to supplement.

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 states a specific action—verify—and a precise resource scope: every version target, pin target, and changelog file, organized per version group. This clearly differentiates it from sibling tools like rrt_drift or rrt_sync_check by framing it as a release gate.

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 description gives explicit timing: use as a pre-release gate and after any edit touching a version string in docs or config. It does not name alternative tools or spell out when not to use, so it misses the explicit exclusion dimension for a 5.

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=true, so the safety profile is covered. The description adds genuine behavioral value: the mechanism (reads [tool.rrt.upstream] config), the supported registries (PyPI/npm/NuGet/crates.io/Packagist), and a real failure prerequisite (network access). These traits are not visible in annotations and help an agent predict behavior and failure modes. The 'never applies a bump' line reinforces the read-only nature with concrete meaning.

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?

Three sentences, roughly 55 words, perfectly front-loaded: sentence one states the operating result, sentence two the mechanism, sentence three the constraints. Every sentence earns its place with non-redundant information, and no structured-field content is repeated.

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 tool this simple (one optional parameter, output schema present, read-only annotation), the description is nearly complete: purpose, data source, supported registries, and a network prerequisite are all covered. The only real gap is the undefined 'group' parameter semantics; return values are already handled by the output schema.

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% and the description never explicitly explains the 'group' parameter — what it selects, its format, or what the null default does. The phrase 'Reads the group's [tool.rrt.upstream] package config' weakly implies group chooses which package config to read, but that is indirect and insufficient as parameter documentation. With coverage zero, the description was expected to compensate and largely doesn't.

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 sentence, 'List upstream package versions newer than the current project version,' states a specific verb, resource, and scope. It also internally distinguishes itself from siblings like rrt_bump (which would apply the change) and rrt_version (which tracks current versions), so an agent can tell them apart without opening any other 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?

The description gives clear context — this checks upstream registries for newer versions and is explicitly read-only ('never applies a bump'). That implies a when-not-to-use boundary against mutation tools like rrt_bump, and it states prerequisites (network access, upstream config present), but it never explicitly names an alternative tool or a conditional that routes to one. Usage is implied rather than stated.

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 the call read-only and idempotent; the description adds the crucial behavioral caveat that the result may be stale and that running this tool does not execute rrt tree --check. This is exactly the kind of beyond-schema context the dimension asks for, and it contradicts nothing.

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?

Three short sentences front-load the core purpose and limitation, then give the alternative paths. No sentence is redundant; even the direct-read equivalent earns its place by giving agents a cheaper option.

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 zero-parameter, read-only tool with an output schema, the description covers the data source, the staleness limitation, the absence of a live check, and fallback alternatives. Nothing an agent needs in order to invoke or interpret this tool is missing.

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 and schema coverage is vacuously complete, so there are no parameter semantics to document. The rubric's baseline for a zero-parameter tool is 4, and the description does not need to compensate for any missing schema detail.

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 states a specific verb ('Return') and resource (the repository tree snapshot from .rrt/tree.lock.toml), and the title/description explicitly frames it as the last recorded snapshot rather than a live check. This prevents confusion with any current-state tree tool, even without naming a sibling.

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?

It explicitly says when not to use the tool (when you need to know whether the working tree still matches) and gives the alternative: use the CLI because no MCP tool provides that check. It also offers the direct-file-read equivalent, so an agent has clear routing guidance.

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 and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: this tool renders a human-facing UI, returns a snapshot, and is not a live data check.

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 compact and front-loaded: a scannable contents list followed by one sentence explaining the human-facing purpose. The sibling guidance is included without wasting words or repeating structured annotation data.

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 zero-parameter, read-only, idempotent UI-rendering tool, the description provides what an agent needs: what is rendered, for whom, snapshot semantics, and the closest alternative for data retrieval. The absence of an output schema is acceptable given the tool's explicit human-viewing purpose.

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?

There are zero parameters and the schema is fully specified with additionalProperties false, so there is nothing to document. The no-parameter baseline of 4 applies; the description wisely adds no parameter-related content.

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 starts with 'Repository tree' and enumerates the exact components: snapshot Metric cards, per-directory bar chart, and clean file table. It states the specific verb 'Renders' and distinguishes the tool from rrt_tree by clarifying it produces a UI widget rather than data values.

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 description explicitly tells the agent when to use this tool: when a human needs to look at a UI widget. It names the alternative, rrt_tree, for when values are needed for reasoning, and warns that the data is still a snapshot, not a live check.

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 state readOnly and idempotent. The description adds that it uses 'configured type allow-list' and honors 'extra_branch_types from config', which tells the agent that behavior depends on repo config, not a fixed regex. This goes beyond the annotations by clarifying the underlying logic.

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 sentences, the first directly states the action, the second adds rationale. No redundancy, front-loaded with the primary purpose. Each sentence earns 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?

For a simple one-parameter read-only tool, the description covers purpose and usage. An output schema exists to document return values, so it's not needed here. It might mention edge cases, but given the simplicity, it's complete enough.

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 schema has a single parameter branch_name with no description (0% coverage). The description clarifies that the parameter is the branch name to validate against the repo's allow-list, which gives it meaning. However, it doesn't specify any format or constraints beyond that, so it only partially compensates for the missing schema description.

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 states 'Check a branch name against this repo's configured type allow-list before you create it', which is a specific verb (check), resource (branch name), and context (allow-list). It clearly distinguishes from siblings like rrt_validate_commit (commits vs branches) and rrt_branch_new (creating a branch). The title reinforces the purpose.

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 description says 'before you create it' and explains it's 'Cheaper than creating it and having the pre-commit hook reject it', which tells the agent to use this as a pre-flight check. It also notes it honors config, implying it's more accurate than hardcoded checks, but doesn't explicitly name alternatives; however, it's clear enough.

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=true and idempotentHint=true, so the safety profile is covered. The description adds context about repo-specific enforcement and the shell-escaping advantage, but it does not go further into return behavior or failure semantics. With the annotations in place, this is adequate but not unusually rich.

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 two sentences, front-loads the core purpose, and then adds a compact usage recommendation. Every clause earns its place, and there is no redundant restating of the tool name or input schema.

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?

Given a single string parameter, read-only and idempotent annotations, and the presence of an output schema, the description covers everything an agent needs to invoke the tool correctly. It explains the purpose, when to use it, and why it is preferable to the shell alternative.

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 meaning of the single parameter. It does so by clarifying that `subject` is a commit subject passed as a string argument, and by explaining that special characters are not mangled. For a one-parameter tool, this is sufficient compensation for the missing schema documentation.

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 states a specific verb and resource: 'Check a commit subject against Conventional Commits as this repo enforces it.' The 'before you commit' framing makes the tool's role clear, and it is easily distinguishable from sibling tools like rrt_validate_branch, which targets branches rather than commit subjects.

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 description explicitly says when to use it ('before you commit') and directly recommends it over the shell alternative `rrt-hooks commit-msg`, with a concrete reason: shell quoting can mangle special characters. This gives the agent actionable selection guidance.

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=true and idempotentHint=true, lowering the bar. The description adds genuine context beyond them: the tool reads from a 'primary target' rather than from file contents, and the value it returns is canonical. The 'Read-only' tag restates the annotation but does not contradict 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?

Two sentences plus a short tag, with the core action front-loaded and the usage guidance immediately after. The only mild waste is 'Read-only,' which duplicates the readOnlyHint annotation, but it is a two-word cost and the overall density is excellent.

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 zero-parameter tool with an output schema and annotations already covering the safety profile, the description covers when to call it, what it reads, and the authority of the result. The only meaningful gap is not explicitly routing the agent away from the nearest sibling rrt_version_overview, though the purpose statement partially handles that.

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?

With zero parameters, the baseline is 4 and there is nothing for the description to document. It still adds semantic value by defining what 'version' means in this tool's scope ('configured version groups'), which helps an agent interpret the empty input schema correctly.

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+resource pair: 'Read the current version of every configured version group from its primary target.' The 'authoritative value, not whatever a file happened to say' framing distinguishes it from the similar-sounding sibling rrt_version_overview, so an agent can tell it apart without opening any schemas.

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?

'Use whenever a version number is about to appear in a commit message, changelog heading, docs string, or release note' is an explicit, concrete when-to-use trigger. It also gives an implied when-not ('not whatever a file happened to say'). However, it never names alternative tools explicitly (e.g., rrt_version_overview or rrt_bump), so it falls just short of a full 5.

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 readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds useful behavioral context: this tool renders a UI widget intended for humans and reads every configured target, as opposed to rrt_version's narrower primary-target return. This goes beyond the structured annotations without contradicting 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?

The description is compact: a one-line summary, a statement of output nature, and two sentences of sibling routing. Each sentence earns its place, key information is front-loaded, and there is no fluff or repeated structured data.

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 no output schema, the description supplies everything needed for correct selection and invocation: what the tool displays, that it is human-oriented rather than data-oriented, and which sibling tools to use for different needs. The read-only and idempotent behavior is already covered by annotations, so no critical context is missing.

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 input schema has zero parameters and 100% schema description coverage, so there is no parameter semantics to add. Per the baseline for zero-parameter tools with complete schema coverage, a score of 4 is appropriate; the description correctly focuses on behavior and alternatives rather than inventing param guidance.

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 phrase, 'Version target map,' and names exactly what is represented: each configured file, kind, and current version. It also distinguishes this dashboard from rrt_version and rrt_release_check, and contrasts with rrt_version's narrower primary-target return, so an agent can select it correctly among siblings.

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 description explicitly routes the agent: call rrt_version when primary-target values are needed, and rrt_release_check for secondary/pin target consistency. It also implies the intended use case—rendering a dashboard for a human to inspect—while explaining that this tool reads every configured target, giving clear selection guidance.

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?

With no annotations, the description carries full behavioral burden and succeeds. It discloses OR-matching semantics for space-separated terms, automatic detail vs compact mode behavior (≤5 matches threshold), the detail override, and the limit default in detail mode. This is substantial behavioral context beyond just stating 'search.'

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 front-loaded with the core purpose, then adds usage context, then matching/override behavior, then an Args block. Every sentence earns its place, and the structure makes the nuanced automatic-mode behavior easy to parse.

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 description covers query semantics, detail behavior, and limits, and an output schema is present, so return values need no explanation. The only meaningful omission is the 'components' parameter, which is left entirely undocumented. For a mostly simple search tool this is a minor but real gap.

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 75%, so the baseline is 3. The description reinforces the schema's explanations of query, detail, and limit, but adds little semantic value beyond what the schema already provides. The 'components' parameter has no schema description and is never mentioned in the description, leaving a real gap for an agent trying to understand what to pass.

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 states a specific action ('Search the Prefab component library') and clarifies the tool's niche: 'this tool has the API details' while 'the skill covers patterns and layout.' This clearly distinguishes it from the sibling generate_prefab_ui and makes the search intent unambiguous.

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 description explicitly says to use the tool 'before writing component code' to look up argument names, accepted values, and usage examples. It also contrasts the tool with the broader skill. It does not explicitly name generate_prefab_ui as an alternative, but the usage context is clear enough for an agent to route correctly.

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