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

Annotations already indicate non-read-only, idempotent, non-destructive behavior. The description adds valuable context: it writes a normalized BrandProfile to a specific file path and auto-detects from known file types, which goes beyond the annotations. No contradictions 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?

Five short, information-dense sentences. The first sentence states the core purpose, followed by specifics on detection, optional scraping, output, and consumers. No filler or redundancy.

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

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

With no output schema, the description partially covers return behavior by stating the output file and its consumers. It could also explain the mode parameter's effect and error handling for website_url, but given the tool's moderate complexity and good annotations, it is reasonably 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?

Schema coverage is 100%, so the description need not explain each parameter. It does add context for project_path (auto-detects from tailwind config, CSS variables, constants/) and website_url (optional), but the mode parameter's strict/infer semantics are not elaborated. Baseline 3 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 the tool imports brand assets during Phase 1 (Illuminate) with specific actions (auto-detects colors, fonts, design tokens; optionally scrapes URL). It names the exact output file and downstream consumers, distinguishing it from siblings like design_research_brief.

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 scoped to Phase 1 and mentions that the profile is consumed by design_research_brief, ux_design, and copy_generate, giving clear when-to-use context. However, it does not explicitly state when not to use it or name alternative tools for other phases.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations: the automatic loading of COPY-SYSTEM.md and the detailed weighted scoring with verdicts, which enhances transparency.

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 and well-structured: a one-sentence purpose explanation, a detailed list of scoring categories, and a final sentence covering usage order and verdicts. No wasted words, all information is relevant.

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's moderate complexity (one param, no output schema), the description is quite complete: it covers purpose, scoring methodology, verdict thresholds, usage sequencing, and artifact loading. Minor gaps include how to interpret the score in practice and a more explicit link between project_path and the artifact.

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 100% coverage for the single parameter project_path, so baseline is 3. The description indirectly suggests project_path is used to locate COPY-SYSTEM.md, but it does not explicitly elaborate on parameter semantics 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 clearly states the tool's function: 'Self-critique the generated copy system against conversion heuristics.' It provides specific details on the 7 scoring categories and verdict thresholds, making it distinct from sibling tools like copy_generate and copy_iterate.

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 instructs 'Call AFTER copy_generate,' providing a clear usage sequence. However, it lacks any when-not-to-use guidance or explicit alternatives, which would elevate it to 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?

The description discloses a key side-effect: it saves to a specific file path (rc-method/copy/COPY-SYSTEM.md), which adds context beyond the openWorldHint=true annotation. It also mentions the prerequisite screen inventory. This aligns with annotations (readOnlyHint=false) and provides useful behavioral transparency without contradiction.

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 exceptionally concise (around 30 words) and well-structured. The first sentence states the core purpose, the second gives usage order, and the third covers requirements and output. Every sentence provides necessary information without any redundancy, earning a top score.

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 fully covers the tool's purpose, prerequisites, input requirements, and output destination. With no output schema, it lists the concrete deliverables and the save path, allowing an agent to understand exactly what will happen. It is complete for decision-making 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 coverage is 100% and both parameters are already described clearly in the schema (project_path, screen_inventory). The description's mention of 'screen inventory' is redundant with the schema and adds no new details about parameter formatting, constraints, or relationships. Thus, it adds minimal value beyond the structured input 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 clearly states the tool generates a full Content Strategy & Copy System with a specific list of deliverables (voice/tone, page-level copy, microcopy library, CTA matrix, SEO content map). It uses a specific verb 'Generate' and resource, and the mention of 'Call AFTER copy_research_brief' distinguishes it from sibling tools like copy_iterate and copy_critique.

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 an explicit sequencing cue ('Call AFTER copy_research_brief') and states a prerequisite (screen inventory), giving clear guidance on when to use this tool. It does not explicitly list when-not-to-use scenarios or alternatives, but the ordering and prerequisites are sufficient for typical usage.

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 indicate readOnlyHint=false and destructiveHint=false, so the agent already knows it mutates. The description adds specific behavioral detail by stating 'Updates the COPY-SYSTEM.md in place,' which names the exact file affected. It does not contradict any 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 two sentences long and front-loaded with the main purpose. Every sentence provides useful info — the core action, the specific file updated, and the optional scoping — 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?

The description covers the essential action and side effect, but with no output schema, it does not mention return values or confirmation behavior. It also lacks details on failure conditions (e.g., missing project path). For a mutation tool, this is a noticeable gap, though the core context is present.

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 100%, so parameters are fully documented. The description adds minimal extra value by mentioning 'Optionally target specific screens,' but this is already captured in the schema's description of target_screens. Thus, it stays at the baseline of 3.

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: 'Iterate on the generated copy system with user feedback' and 'Updates the COPY-SYSTEM.md in place.' This clearly differentiates it from sibling tools like copy_generate and copy_critique by emphasizing in-place modification of an existing system.

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 clearly implies when to use this tool: when user feedback exists for an already generated copy system, and it mentions optional targeting of specific screens. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.

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=false, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds workflow context (phase, sequence, downstream tools) and prerequisite information, which is valuable beyond annotations. It does not contradict the annotations and provides enough behavioral context for an agent.

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, using a colon to list deliverables efficiently, and then two short sentences for timing and prerequisites. Every sentence adds value, with no redundancy or fluff. It is well-structured and 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 complex tool with no output schema, the description covers the essential context: what it generates, when to call it, what it depends on, and what it feeds. It does not detail output format or return values, but that is not critical given the lack of an output schema and the richness of the description. Overall, it is complete enough for an agent to use effectively.

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 description for project_path is clear ('Absolute path to the project directory') and coverage is 100%. The description merely reiterates that project_path is required and mentions PRD context, which is not a parameter. Since the schema handles parameter semantics, a baseline score of 3 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 the tool 'Generates a Copy Research Brief' and enumerates its specific outputs (VOC phrase bank, awareness mapping, JTBD extraction, etc.), providing a precise verb+resource+scope. It also distinguishes itself from sibling tools like design_research_brief by specifying it is for copy and feeds into copy_generate/ux_design.

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 ('Call during Phase 2 (Define) AFTER the Design Research Brief') and workflow context ('The brief feeds into copy_generate and ux_design'). It also states prerequisites ('Requires project_path and PRD context'), making it clear when to use this tool instead of 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?

With no annotations, the description carries the transparency burden. It discloses the evaluation process (5 lenses), the output structure (findings by severity with fixes), and the expected post-success actions. It does not explicitly state whether the tool is read-only or if it modifies state, which is a minor gap, but the disclosed behavior is substantially informative.

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 four short sentences, each with a distinct purpose: stating the core function, specifying when to call, describing the output, and outlining follow-up steps. There is no redundancy or filler; every sentence adds necessary information.

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 the tool's purpose, timing, output, and next steps, which is fairly complete given the simple schema and lack of output schema. It does not mention error conditions or side effects, but for an analysis/evaluation tool embedded in a clear workflow, the provided 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?

Schema coverage is 100%, with both parameters already described in the schema. The tool description does not add any new detail about the parameters themselves; it focuses on the tool's behavior and workflow. Since the schema fully documents the parameters, the baseline of 3 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 uses a specific verb 'Stress-test design options' and enumerates five distinct lenses, making it clear what the tool evaluates. It also distinguishes itself from siblings by naming the exact workflow position (after ux_design, before design_select/design_iterate) and its unique output ('findings by severity with specific fixes').

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 states when to call it ('Call after ux_design generates options') and what to do after success ('present findings to user, then proceed to design_select or design_iterate'). It provides clear workflow context but does not mention when not to use it or any alternative tools, 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?

The description discloses that the tool saves to rc-method/design/DESIGN-INTAKE.md and returns an alignment score, verdict, and extracted constraints. This adds meaningful behavioral context beyond the annotations, which only provide boolean hints. It does not explain side effects like idempotency, but that is already covered by 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-loaded with the action and pipeline position, then lists captured inputs, then outputs/save behavior. Every sentence contributes useful information with 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?

Given the tool has 34 parameters and no output schema, the description does well to explain return values (alignment score, verdict, constraints) and the destination file. It also mentions the prerequisite (after PRD) and evaluation against ICP expectations. It does not detail every parameter, but the schema covers all of them, so this is adequate.

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 100% description coverage for all 34 parameters, so the baseline is 3. The description summarizes high-level input categories (colors, typography, layout, etc.) but does not add parameter-level semantics beyond what the schema already provides.

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 tool runs the Design Intake Assessment, identifies it as the first step after PRD, and distinguishes it from siblings by noting it feeds extracted constraints into every downstream design tool. It lists the comprehensive categories it captures, making its scope specific and 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?

It explicitly states this is the FIRST step of the Design Intelligence pipeline after PRD, giving clear temporal context for when to invoke it. It does not explicitly name alternative tools or exclusion scenarios, but the pipeline positioning implies it should be used before downstream design 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 provide minimal behavioral hints (readOnlyHint false, destructiveHint false, idempotentHint false), and the description adds context by stating it loads the current design spec, regenerates wireframes, and maintains design system consistency. This covers the core behavior without contradicting annotations, though it could disclose more details about overwriting or side effects.

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 three sentences, front-loaded with the primary purpose. Each sentence adds value: what it does, how it works, and a key prerequisite. No filler or redundant content.

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 4 parameters and no output schema, the description covers the essential context: purpose, input (feedback), scope (screens/options), and a prerequisite. It is complete enough for an agent to understand when and how to invoke it, though return values and error conditions are not mentioned.

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 100%, with each parameter fully described in the schema. The description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 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 the tool iterates on existing wireframes based on user feedback, with a specific verb ('Iterate') and resource ('existing wireframes'). It distinguishes itself from siblings such as ux_design (initial generation) and copy_iterate (copy iteration) by focusing on design wireframes and requiring prior ux_design execution.

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 clear usage context by specifying the precondition that ux_design must have run first, and explains the behavior of targeting specific screens or all screens. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full 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?

Beyond the annotations, the description explains the pipeline behavior: captures preferences via design_intake, generates real copy, produces research-backed options with wireframes, and returns a combined report. It also notes the sequential dependency on a PRD. No contradictions 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 front-loaded with the core purpose, then uses a compact list of steps and key behaviors. It is dense but not wasteful; every sentence adds a distinct piece of information (prerequisite, behavior, output, alternatives).

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 complex orchestration tool with 10 parameters and no output schema, the description is remarkably complete: it states prerequisites, step sequence, inputs (preferences), outputs (combined report), and customization (individual step alternatives). The only minor gap is a detailed return format, but 'combined report with all artifacts' is sufficient.

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 70%, with most parameters already described. The description adds contextual nuance (e.g., preferences go to design_intake, copy is generated) but does not explain individual parameters beyond what the schema provides. This is a minimally adequate contribution.

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+resource: 'Run the full Design Intelligence pipeline in sequence', and enumerates the exact sequence of steps. This clearly distinguishes it from sibling tools that focus on individual steps (ux_design, design_challenge, copy_generate).

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 provides an explicit prerequisite ('Requires PRD to exist (run rc_define first)') and an explicit alternative ('Each step can also be called individually for more control'). This tells the agent exactly when to use this tool and when to prefer individual steps.

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, and destructiveHint=false. The description adds valuable context by stating it saves to a specific file path (rc-method/design/DESIGN-RESEARCH-BRIEF.md) and that it analyzes ICP, competitors, and brand constraints. This clarifies side effects and data usage beyond the structured hints.

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, with the first front-loading the core action and the second listing outputs and the destination file. Every sentence carries meaningful information with no filler or redundancy.

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 one parameter and no output schema, the description is remarkably complete. It covers purpose, the phase of use, the dependency on PRD, the detailed list of outputs, and where the output is saved. The annotations handle safety and idempotency, leaving no significant gaps.

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 is only one parameter (project_path) and the schema already provides full coverage with a clear description ('Absolute path to the project directory'). The tool description adds no additional parameter semantics, but none are needed given the schema's completeness.

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 action ('Generate') on a specific resource ('Design Research Brief') during Phase 2. It enumerates concrete outputs (ICP design profile, competitive landscape, etc.) that distinguish it from other research or design tools. This is a clear, non-tautological statement of 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 specifies when to use the tool: during Phase 2 (Define) and explicitly says 'Call AFTER prd is created.' This provides timing and a dependency condition. It does not name alternative tools or explicitly state when not to use it, but the context is sufficient for an agent to place it correctly.

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 indicate a write operation (readOnlyHint=false), destructive=false, and idempotent=true. The description adds transparency by explicitly stating that it 'Saves the selected option ID to project state', which is a side effect beyond the annotations. It also mentions the Deep Dive requirement, providing additional behavioral context 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?

The description is two sentences, tightly packed with essential information: the action, the target output, the state update, the downstream consumers, and the required mode. No filler or redundancy.

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 has only two simple parameters and no output schema, so the description covers the key aspects: purpose, side effect, and usage context. It could mention that selected options come from a finite set (already in schema) but not necessary. Overall, it is sufficiently complete for an AI agent to invoke correctly.

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

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

Schema coverage is 100% with both parameters described (option_id gives allowed values, project_path gives absolute path). The tool description adds no further parameter meaning beyond referencing 'selected option ID', so the baseline score of 3 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 the action ('Select a design option') and the resource (design option from ux_design output). It further explains the effect on project state and ties to downstream tools, distinguishing it from siblings like design_iterate and design_challenge.

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 specifies when to use this tool: after reviewing ux_design output and as a required step in Deep Dive mode (UX score >= 7) before Gate 2. It implicitly positions it as a prerequisite for design_iterate, design_challenge, and code generation, but does not explicitly mention alternatives or when not to use it.

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 indicate this is a write operation (readOnlyHint=false). The description adds valuable context beyond annotations by specifying the output location ('Saves the HTML to rc-method/exports/') and the two-step user process (open in browser, print to PDF). It does not mention overwriting or error behavior, but the key side effect and workflow are disclosed.

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 four sentences, front-loaded with the primary purpose, and every sentence adds value—purpose, mechanism, workflow, file support, and output location. No redundancy or fluff.

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 four parameters, no output schema, and annotations present, the description covers the main aspects: what it does, how to use it, where it saves output, and what input files it accepts. Minor gaps like error handling and exact overwrite behavior are not addressed, but the description is sufficiently complete for typical use.

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 100%, so parameters are already fully documented. The description adds context about output styling and supported file types but does not add meaning beyond the schema's parameter descriptions. The baseline of 3 applies when schema does the heavy lifting, and this is the case here.

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: 'Export project artifacts as a professional, print-ready HTML document.' It further clarifies it converts markdown files into styled HTML with cover page and print rules, making the tool's function unmistakable and distinct from sibling process/status tools.

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 clear context on when to use the tool: 'Supports any markdown file in the project (PRDs, playbook, design briefs, reports)' and explains the browser workflow (open HTML, Cmd+P / Ctrl+P). It implicitly covers usage scenarios but does not explicitly mention when not to use it or name alternatives. Since no sibling tool competes with this export function, the guidance is adequate.

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 adds valuable context beyond the annotations by stating the exact output file path (rc-method/PLAYBOOK-{name}.md) and the fact that it aggregates all pipeline outputs. Since annotations already declare idempotency and non-destructiveness, the description's additional detail about file output and prerequisites is sufficient and does not contradict 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 concise and well-structured over three sentences. The first sentence states the purpose, the second details the content scope, and the third gives the output location and prerequisite. Every sentence adds necessary information with no redundancy.

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 simple schema (2 params, no enums) and the idempotency annotation, the description covers the essential aspects: what it aggregates, the output file, and the requirement. It does not discuss overwrite behavior or return values, but these are not critical given the annotations and the lack of an 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?

The input schema already fully describes both parameters (project_name with default behavior, project_path as absolute path) with 100% coverage. The description indirectly references project_name in the file path template but does not add substantial meaning beyond what the schema provides, so it meets the baseline.

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 identifies the tool's purpose: generate the Project Playbook/ARD. It lists all the input sources (research, PRD, decisions, etc.) and describes the output as the master deliverable for development teams, distinguishing it from sibling tools that focus on individual pipeline phases.

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 states a concrete prerequisite ('Requires at least one pipeline phase to have been completed') and implies the appropriate use case by describing the deliverable as something a non-technical user hands to a development team. It does not explicitly name alternatives or exclusions, but the guidance is 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 indicate idempotent and non-destructive behavior. The description adds useful context: persistence to 'post-rc/ state' and that defaults are reasonable, implying calling it changes state. No contradictions 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?

Three sentences, front-loaded with '[Pro] OPTIONAL', and every sentence carries essential information (what it sets, when to use, state persistence). 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?

With 21 parameters and no output schema, the description provides enough high-level context for an agent to understand when and why to invoke this tool. It does not enumerate all parameters, but the schema does; the description's grouping is sufficient for this configuration 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?

Input schema covers all 21 parameters with descriptions (100% coverage), so baseline applies. The description groups parameters into categories (modules, blocking, suppressions, etc.) but adds no detail beyond 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 clearly states the tool's function: 'configure validation policy BEFORE running postrc_scan'. It specifies the resources affected (modules, block thresholds, CWE suppressions, monitoring, legal review) and distinguishes it from siblings by noting its optional, pre-scan nature.

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: 'OPTIONAL... BEFORE running postrc_scan' and when not to: 'Defaults are reasonable - only call this if the user has specific compliance or risk tolerance requirements.' This provides clear guidance without ambiguity.

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 mark the tool as destructive (destructiveHint: true). The description adds context by explaining the PASS/WARN/BLOCK outcomes and the requirement to present findings first. It doesn't contradict annotations and provides behavioral details beyond them, such as the need for user review and the consequences of each status.

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 information-dense but every sentence earns its place: it covers when to call, safety guidance, return values, fallback actions, and next steps. It is well-structured and avoids redundancy.

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

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

With no output schema, the description adequately explains the return statuses and their meanings. It also places the tool within the pipeline lifecycle (after postrc_scan, before trace_map_findings). Some nuance about 'reject' and 'question' decisions is left to the schema, but the overall workflow is clear.

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 fully describes all three parameters (100% coverage). The description adds context around the decision parameter by explaining the statuses (PASS/WARN/BLOCK) and the user's options on BLOCK, but doesn't introduce new parameter-level meanings 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 clearly states the tool's purpose: 'Final checkpoint - ship/no-ship decision.' It identifies the resource (the build) and the action (final gate). It differentiates from siblings by specifying 'Call after postrc_scan completes' and referencing postrc_override, making it distinct.

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?

Explicit when-to-use guidance is provided: 'Call after postrc_scan completes and user has reviewed findings.' Alternatives are given for BLOCK cases ('use postrc_override to accept risks') and a follow-up tool is suggested ('trace_map_findings next'). The strong warning 'NEVER auto-approve' sets clear usage boundaries.

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 declare idempotent and non-destructive; description adds workflow context (pre-flight, feeds into rc_architect) and output contents. No contradictions, and given annotations cover safety profile, the added behavior context earns a 4.

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 sentences, all informative, front-loaded with the PRE-FLIGHT label and purpose. 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?

Tool is simple (2 params, no output schema), and description covers why, when, what, and where output goes. The lack of output schema is compensated by describing the document contents. Complete for the complexity.

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 covers 100% of parameters with descriptions; description adds no additional parameter semantics beyond mentioning PRD input, which is already in schema. Baseline of 3 applies.

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 tool 'Generates an observability requirements document from the PRD' and enumerates contents (error tracking, analytics events, SLOs, dashboards, alerting). It distinguishes itself by labeling 'PRE-FLIGHT tool' and noting it feeds into rc_architect, separating it from 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?

Provides explicit timing ('run BEFORE RC Method build phase, ideally after rc_define') and context ('PRE-FLIGHT tool'). Notes optionality and recommendation, but does not name alternatives or exclusions, so slightly below perfect.

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 destructive (destructiveHint: true), and the description adds valuable detail by stating it 'Creates an immutable audit record.' This goes beyond the annotation and warns about user communication, enhancing transparency beyond what structured data provides.

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, front-loaded with the purpose, and each sentence adds value. It covers required parameters, usage context, warning requirements, optional expiration, and post-override action without redundancy.

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 mutation tool, the description covers key aspects: what it does, when to use it, prerequisites, and next steps. It doesn't detail error handling or return values, but given the clean schema and annotations, the overall context is sufficient for an agent to proceed.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by specifying that finding_id comes from 'postrc_scan results' and clarifies that 'justification' maps to the 'reason' parameter. It also mentions the optional expiration date, aligning with expires_days, which provides extra context.

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 tool's function: 'Override a specific scan finding when the user accepts the risk.' It uses a specific verb and resource, and it distinguishes from siblings by referencing the postrc_gate blocked scenario, making the tool's purpose 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?

Explicit 'when' guidance is provided: 'Use when postrc_gate is blocked by a finding the user wants to accept.' It also gives follow-up instructions ('After override: re-run postrc_gate to re-evaluate ship decision') and a necessary warning for high/critical findings. It lacks an explicit 'when not to use' statement, but the context implies it.

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 destructiveHint=false, and the description adds that the report is 'Saved to post-rc/' and 'does not modify scan state.' This complements the annotations without contradiction, though it does not detail file naming or permission requirements.

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 concise sentences with the core purpose front-loaded. Every sentence provides valuable context: purpose, call order, report content, output location, and read-only safety. No filler or redundancy.

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 strong annotations and full schema coverage, the description explains the output type (markdown document) and key sections, fitting well within the postrc_* workflow. It omits file naming details and error scenarios, but these are not critical for a reporting 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 100% for the two parameters (scan_id and project_path), so baseline is 3. The description mentions 'scan results' and the report's location, but it adds little meaning beyond what the schema already provides for parameter semantics.

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 ('Generate a formal validation report from scan results') with a clear resource (report from scan results). It distinguishes from siblings by specifying the call order ('Call after postrc_scan') and enumerating report contents (findings summary, severity breakdown, override records, remediation recommendations).

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 usage context: 'Call after postrc_scan' and lists target audiences (stakeholders, compliance, audit trails). It does not formally name alternatives or exclusions, but the context is clear enough to guide tool selection.

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 provide idempotentHint, openWorldHint, and readOnlyHint, but the description adds critical behavioral details: 'LONG-RUNNING: involves LLM analysis', generation of a 'REMEDIATION-TASKS file' on critical findings, and return format 'findings by severity (critical/high/medium/low) with CWE/legal references.' This goes beyond the structured metadata and informs the agent of side effects and latency.

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 dense but well-organized: it starts with the main purpose, then lists return format, timing, follow-up steps, and side effects. All sentences contribute meaningful information. While it's slightly long, it avoids fluff and is structured with clear separators, making it 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?

Given the tool's complexity (security scanning, LLM analysis, multiple modules) and lack of an output schema, the description covers essential aspects: use case, return format, workflow, configuration, side effects, and duration. It gives the agent enough context to invoke correctly and handle results, though it could mention behavior after success in more detail, but the existing guidance is sufficient.

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

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

Schema coverage is 100% for all three parameters, so the baseline is 3. The description adds value by instructing the agent to 'Pass code_context with the actual project code', clarifying the intended use of that parameter. It also mentions the optional legal module configuration, which helps understand the modules parameter. However, modules are not fully explained individually, so the gain is moderate.

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 tool's function: 'Scans code for security vulnerabilities, checks monitoring instrumentation, and optionally runs legal compliance review.' The verb 'scans' and the target 'code' make the purpose specific. It also distinguishes itself from sibling tools by mentioning a follow-up with postrc_gate, showing its role in the pipeline.

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 ('Run AFTER building (Phase 6 Forge complete)'), prerequisites ('Pass code_context with the actual project code'), and workflow ('After success... call postrc_gate'). It also notes the Pro tier requirement and configuration via postrc_configure with legal_enabled=true, providing context for when to use the optional legal modules.

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 the tool read-only, idempotent, and non-destructive. The description reinforces this with 'Read-only, safe to call anytime' and adds value by disclosing the exact return fields and its role as a pre-check for postrc_gate. It doesn't contradict annotations, and the extra context about return contents exceeds what annotations provide.

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 and front-loaded, starting with 'Check Post-RC validation progress' followed by actionable return values and usage guidance. Every sentence earns its place with no redundancy, and the structure is easy to scan.

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 read-only tool with one parameter and no output schema, the description is complete: it states the purpose, lists return values, gives usage context, and differentiates from sibling tools. It covers all necessary aspects without requiring additional information.

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 100% coverage for the single parameter project_path, with a clear description ('Absolute path to the project directory'). The tool description does not add additional parameter semantics, so the baseline of 3 is appropriate since the schema already fully documents the 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 description clearly states the tool's purpose: 'Check Post-RC validation progress' with a specific verb and resource. It distinguishes itself from siblings by listing the exact return values (active modules, latest scan ID, findings count, override count, gate status) and explicitly positioning itself relative to postrc_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 usage context: 'Use this to orient yourself when resuming a session or when the user asks about validation status.' It also provides a direct alternative/order guidance: 'Call before postrc_gate if you need to verify scan results are available.' This clearly indicates when to use this tool versus 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?

With no annotations provided, the description carries the full burden. It discloses 'Read-only analysis, no side effects beyond state update,' which clarifies the safety profile and side-effect scope. It also lists return values (complexity domain, specialist list, cost budget, stages), adding behavioral context. However, it doesn't mention permission requirements or failure behavior, so it's strong but not fully comprehensive.

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 three sentences, front-loaded with the critical precondition, and immediately states the core function. It efficiently packs purpose, usage, return values, and next step without redundancy. Every sentence contributes unique value.

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 a single parameter and no output schema, the description is exceptionally complete: it explains the framework, the activation action, the return data, and the follow-up action. It fully covers the tool's role in the pipeline and leaves no significant ambiguity for the agent.

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 100%, with project_path described as 'Absolute path to the project directory' in the schema. The description adds no additional parameter-level meaning, so it meets the baseline but doesn't go beyond the structured field information.

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 tool's verb and resource: 'Classifies the product idea using Cynefin framework' and 'activates the appropriate subset of 20 research specialists.' It distinguishes itself from siblings by specifying its role in the pipeline, including the precondition 'Call AFTER prc_start' and the checkpoint handoff to prc_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?

Explicitly provides when to use: 'Call AFTER prc_start' and after success, 'call prc_gate with their decision.' This frames the tool as a required step between two sibling tools, offering clear sequencing and an explicit next action, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes the precondition (must present checkpoint context first), valid decisions and their consequences (approve/proceed, reject/revise, question/pause), and the follow-up actions. It does not detail internal state mutations, but for a gate tool this level of disclosure is strong, though not perfect.

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 yet information-dense, organized with an action statement, a critical usage warning, checkpoint enumeration, decision meanings, and post-action behavior. Every sentence earns its place, with no fluff or redundancy, and the most important constraint 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?

Despite having no output schema and no annotations, the description is fully self-contained for a gate tool: it names the three checkpoints, explains valid decisions and their downstream effects (including linking to prc_synthesize after Checkpoint 3), and references the current Pre-RC research stage, which situates it within the broader workflow. It leaves no obvious questions about when or how to use 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?

Schema coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining what each decision entails ('approve' means proceed, 'reject' means revise with feedback, 'question' means pause for clarification) and how these map to workflow steps. This is richer than the schema's simple string examples.

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 tool's action ('Submit a checkpoint decision') and resource ('current Pre-RC research stage'), and delineates the three checkpoints (Checkpoint 1, 2, 3) with their specific contexts. This distinguishes it from sibling tools like 'rc_gate' or 'postrc_gate' by explicitly anchoring it to the Pre-RC research stage.

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 usage directives: 'NEVER call without presenting the checkpoint context to the user first and getting their explicit decision' and explains exactly what to do after each decision type ('After approve: proceed to next stage or prc_synthesize... After reject: re-run the relevant stage with user feedback'). This gives clear when-to-use and when-not-to-use guidance, exceeding the baseline.

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?

No annotations are provided, so the description carries the burden. It discloses side effects (web search for stage-3), prerequisites, and return format (success/failure markers). However, it doesn't explicitly state whether re-running overwrites existing results or any other mutation side effects.

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. Each sentence earns its place: purpose, normal-flow contrast, valid stages, prerequisites, and return format. No fluff or redundancy.

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 no output schema, the description adequately covers return markers. It also provides prerequisites, side effects (web search), and the full list of valid stages, making the tool's role in the pipeline clear. The context is complete for a re-run 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 100%, providing baseline of 3. The description adds the full list of valid stage values and notes that stage-3 uses web search, enriching the schema's examples and improving parameter understanding.

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 ('re-run') and resource ('specific research stage'), clearly distinguishing from automatic flow via prc_gate. It also enumerates valid stage names, making the purpose 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 ('ONLY to re-run a failed or incomplete stage'), and contrasts with normal flow through prc_gate. It also lists prerequisites (prc_classify complete, checkpoints approved), giving clear decision 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 provided, the description carries the full burden and does well: it discloses the side effect of creating a directory and initializing state, and it clearly instructs the agent to call prc_classify next. It also resolves ambiguity about sequencing by forbidding skipping directly to prc_run_stage.

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 three sentences, front-loaded with the most important positioning ('FIRST STEP'), and contains no filler. Every sentence adds value: when to call, what it does, prerequisites, and next-step constraints.

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 initialization tool with no output schema, the description fully covers the workflow context: the entry-point role, required state creation, prerequisites, and mandatory follow-up. Given the low complexity and rich schema, no additional details are 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?

Schema description coverage is 100% and each parameter (brief, project_name, project_path) already has a clear description. The tool description does not add further detail about parameter formats or values, but it does align the 'product idea' context with the brief parameter. This meets the baseline expected from high schema coverage.

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 identifies prc_start as the 'FIRST STEP of Pre-RC research' with a specific verb+resource: creates the pre-rc-research/ directory and initializes project state. It distinguishes itself from sibling tools by positioning itself as the entry point and explicitly names the next step (prc_classify).

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?

Provides explicit when-to-use guidance: 'Call when the user describes a product idea and you want deep research before building.' It also states prerequisites ('none - this is the entry point') and warns against skipping to prc_run_stage before classifying, giving clear workflow 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'Read-only, safe to call anytime' and lists the specific information returned. It does not mention edge cases (e.g., invalid project_path), but for a status tool this is sufficient and adds strong behavioral context beyond structured data.

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, front-loaded with the core purpose, followed by return values and usage guidance. Every sentence is informative, and there is no redundant content.

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 status tool with one parameter and no output schema, the description fully covers what it does, what it returns, when to use it, and its safety characteristics. It leaves little ambiguity for the agent to select and invoke it correctly.

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

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

Schema coverage is 100% since the only parameter operation is project_path, which is described as 'Absolute path to the project directory.' The description does not add any extra meaning to the parameter, so it relies on the schema. Baseline of 3 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 the tool's verb ('Check') and resource ('Pre-RC research progress'), and it enumerates the exact return contents. It also distinguishes itself from sibling tools by focusing specifically on PRC progress, versus rc_status or postrc_status, and by positioning itself as an orientation tool.

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: 'when resuming a session or when the user asks "where are we?"' and even directs the agent to call it 'BEFORE deciding which prc_ tool to call next if you are unsure of the current state.' This is clear, actionable, and differentiates it from action-oriented 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool is long-running (3 LLM calls), optional, and Pro-tier, and explains its analysis steps (challenges assumptions, fact-checks with web data, evaluates business model). It also states the output verdict types. However, it doesn't explicitly address potential side effects or state mutations, though it's likely an analysis-only tool. Still, it provides substantial behavioral context beyond a simple 'runs analysis'.

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 somewhat long but every sentence adds value: prerequisites, after-success flow, and internal steps. It is structured and front-loaded with the most important information. Minor redundancy with 'stress-test' repeated, but overall efficient.

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 only one parameter and no output schema, the description covers all needed context: purpose, usage order, prerequisites, output, and next steps. It is fully self-contained for an agent to select and invoke correctly, especially with the rich sibling context.

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

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

Schema coverage is 100% for project_path, which is clearly documented as 'Absolute path to the project directory'. The description adds no additional parameter-specific semantics, but with full schema coverage, the baseline of 3 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 the tool's function: stress-testing the product idea after synthesis. It uses specific language ('VC-level devil's advocate analysis') and names the verdict output (GO/NO-GO/CONDITIONAL), distinguishing it from sibling tools like prc_synthesize and rc_import_prerc.

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 the prerequisite chain ('Call AFTER prc_synthesize', 'Gate 3 approved', 'prc_synthesize complete') and describes the post-success decision flow (proceed to rc_import_prerc on GO/CONDITIONAL, discuss alternatives on NO-GO). This gives clear when-to-use and alternatives 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 disclosure. It warns that the tool is LONG-RUNNING due to multiple LLM calls, specifies post-success actions (present deliverables), and outlines the pipeline sequence. This provides substantial transparency, though it could go further by mentioning potential side effects like file overwrites.

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 paragraph with strong front-loading, starting with the step position and condition. Each sentence provides distinct information (deliverables, runtime, optional flag, next step, stopping point), and while it's moderately long, it avoids redundancy.

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?

Although there is no output schema, the description thoroughly covers all relevant aspects: preconditions, deliverables, runtime behavior, optional parameter effect, and follow-up actions. It provides enough context for an agent to invoke the tool correctly and understand the workflow.

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 already fully describes both parameters (project_path and include_task_deck) with complete coverage. The description adds only a slight rephrasing of include_task_deck as 'visual task breakdown deck,' but does not significantly enhance understanding 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 clearly identifies the tool as the synthesis step that converts persona research into specific deliverables (PRD, HTML deck, task list, DOCX, index). It uses a specific verb ('synthesizes') and distinguishes this from sibling tools by noting it's the final step of Pre-RC after Gate 3.

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 states the precondition ('Call ONLY after Gate 3 is approved (all 6 stages complete)') and provides the alternative for continuing ('To continue into RC Method, call rc_import_prerc'). It also mentions the natural stopping point, giving clear when-to-use 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?

There are no annotations, so the description carries the full burden. It states the return value ('architecture document + gate prompt') and the gating prerequisite, which is useful. However, it does not disclose side effects (e.g., whether files are written), required permissions, or what happens if the gate is not approved. This leaves behavioral uncertainty for a pipeline 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?

The description is two sentences long with no fluff. The first sentence establishes the phase and core functions; the second covers input guidance, return value, and prerequisites/next steps. Every sentence contributes essential information.

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 no output schema, the description adequately explains what it returns (architecture document + gate prompt) and situates it in the broader pipeline (Phase 3, previous gate, next phase). It could be more complete by noting failure conditions or what the gate prompt entails, but the core context is covered.

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 already provides 100% coverage with descriptions for both parameters. The description adds meaningful value by explaining architecture_notes with concrete examples ('use Next.js and Supabase', 'must integrate with Stripe') and clarifying that it carries the user's technical preferences/constraints. project_path is adequately handled by 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 clearly identifies the tool as 'Phase 3 (Architect)' and specifies its function: defining technical architecture including tech stack, data models, API design, integrations, and infrastructure. This distinguishes it from siblings like rc_define (likely earlier definition) and rc_sequence (next phase), and the 'Phase 3' label provides explicit pipeline context.

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 guidance on what to supply (architecture_notes) with examples, and states prerequisites (Phase 2 gate approved or auto-approved via rc_import_prerc) as well as the follow-on step (Phase 4 Sequence). It does not explicitly name alternative tools to use instead, but the phase-based sequencing implies when this tool is appropriate.

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?

No annotations are provided, so the description carries full burden. It discloses auto-approval of checkpoints, the important exception (Post-RC ship decision), failure behavior ('stops and reports where it stopped'), and prerequisites. This is comprehensive behavioral 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?

Four sentences, each earning its place: main action, auto-approval behavior, critical exception, failure and usage guidance. Information is front-loaded and no redundant wording exists.

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 batch automation tool with one simple parameter, the description covers prerequisites, failure handling, auto-approval exclusions, and usage context. No output schema exists, but the description sufficiently sets expectations for what the tool does and when to use 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?

Schema description coverage is 100% for the single parameter (project_path already described as 'Absolute path to the project directory'). The description adds no additional parameter meaning, so baseline 3 applies.

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 'Run' with a clear resource ('remaining RC Method steps'), and defines the exact scope ('from the current step through Step 8'). It distinguishes itself from sibling step-by-step tools by describing batch automation and auto-approval.

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 ('when the user wants to fast-track the build pipeline'), provides alternatives ('prefer step-by-step flow' for first-time users), and lists prerequisites ('at least rc_start or rc_import_prerc must have been called').

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 provided, the description discloses key behaviors: it cross-references the Phase 7 integration report, produces a ship checklist and go/no-go assessment, and requires Phase 7 approval. It does not explicitly state whether it writes state, but the assessment-oriented language makes side effects unlikely.

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 pack all essential details—phase, purpose, prerequisites, and next step—without redundancy. The description is front-loaded with the phase identifier and immediately communicates the tool's role.

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 is self-contained: it explains inputs (via schema), outputs ('ship checklist and go/no-go assessment'), dependencies on Phase 7, and the successor tool. No output schema exists, but the description adequately conveys what the tool produces.

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?

Input schema coverage is 100% with clear descriptions for both parameters. The description adds context by framing code_context as 'included in the hardening assessment' and tying the tool to Phase 7 output, which helps clarify parameter purpose 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 clearly states the tool's function: 'Assesses production readiness' and enumerates specific areas (NFR compliance, error handling, observability, performance, security hardening, deployment configuration). It further distinguishes itself as 'Phase 8 (Compound). Final phase before ship' and references postrc_scan as a subsequent step.

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?

Provides explicit when-to-use context: 'Prerequisites: Phase 7 gate approved' and 'After gate approval: pipeline complete, proceed to postrc_scan for security validation.' This establishes sequencing relative to sibling phases and gives a clear pointer to the next tool.

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 provided, the description carries the burden of behavioral disclosure. It states that the tool 'reads forge artifacts automatically,' requires no user input, and 'generates an integration report with gaps and recommended integration tests.' It also notes the transition to Phase 8. It does not explicitly mention if files are modified, but the read/report behavior is reasonably transparent.

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 four sentences, front-loaded with 'Phase 7 (Connect)'. Each sentence provides useful information: purpose, process, autonomy, and next step. There is slight redundancy in 'Prerequisites: Phase 6 gate approved' and 'After gate approval,' but overall it is efficient and well-structured.

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 one parameter and no output schema, the description covers purpose, process, prerequisites, and next phase. It explains what the tool reviews, that it generates a report, and its automatic behavior. It does not specify report format or return values, but the given context is sufficient for an agent to select and invoke the 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 single parameter project_path is described in the schema with 100% coverage, so the description adds little to parameter meaning. The claim 'No user input needed' could confuse because a required parameter exists, but the parameter itself is well-defined. Given the high schema coverage, a baseline of 3 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 the specific verb and resource: 'Verifies that all built components integrate correctly.' It further details the scope (API wiring, authentication flows, data model alignment, dependencies) and the output (integration report). This distinguishes it from sibling tools like rc_validate by focusing on integration and phase 7.

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 clear usage context: it is Phase 7, with prerequisite 'Phase 6 gate approved' and a next step ('moves to Phase 8'). It also states that no user input is needed, implying it should be used after phase 6 in the pipeline. It does not explicitly exclude alternatives, but the phase structure is sufficient for a pipeline tool.

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?

Despite no annotations, the description discloses important behaviors: it produces and saves a PRD, returns PRD content and a gate prompt, instructs the user to present the PRD for review, and notes the workflow transition. This fully informs the agent of side effects and expected actions.

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, using three sentences to convey purpose, prerequisites, workflow, and output. Every sentence adds value without redundancy.

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

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

With no output schema, the description explains return values ('PRD content + gate prompt') and next steps. It lacks details on error conditions or file overwrites, but is sufficient for the tool's complexity and parameter richness.

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

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

Schema coverage is 100% with both parameters described. The description adds context by specifying that operator_inputs contains 'feature descriptions, user stories, and requirements' and that the output is an 11-section PRD, enriching the schema's basic definitions.

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 tool's function: 'Generates a Product Requirements Document from user-provided feature descriptions, user stories, and requirements.' It specifies it is Phase 2 (Define), distinguishes it from siblings like rc_architect (Phase 3), and mentions the output format (11-section PRD) and location (rc-method/prds/).

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 usage context: 'Prerequisites: Phase 1 gate approved' and 'After gate approval: moves to Phase 3 (Architect).' It also suggests considering ux_score and ux_generate for UX-heavy products, offering clear guidance on when to use this tool and related 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?

With no annotations, the description carries the burden. It discloses dependency ordering, failure handling ('If a task fails, it is recorded as failed and the next task continues'), and return summary. However, it does not mention side effects, permissions, or idempotency, leaving some behavioral gaps.

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 dense yet every sentence adds value: purpose, equivalence, error handling, return, prerequisites, and next steps. It is front-loaded with the main action 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?

Despite having only one parameter and no output schema, the description covers the tool's purpose, failure behavior, return format, prerequisites, and subsequent steps. This is a complete guide for an agent in the workflow context.

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

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

Schema coverage is 100% and the only parameter, project_path, has a clear description. The tool description repeats the requirement about containing rc-method/tasks/ but adds no new meaning beyond the schema. Baseline 3 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 the tool's action: 'Builds ALL pending tasks from the approved task list in one call'. It differentiates from sibling rc_forge_task by noting it is equivalent to calling rc_forge_task sequentially, making the scope obvious.

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 explicit workflow context: 'Phase 6 (Forge) BATCH MODE', prerequisites ('Phase 5 gate approved, task list must exist'), and postconditions ('proceed to rc_gate to approve Phase 6, then rc_connect'). This clearly indicates when to use this vs. single-task execution.

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?

No annotations exist, so the description carries the transparency burden. It discloses what the tool loads ('PRD, architecture, and task context') and what it produces ('implementation guidance'), plus the operational requirement to 'Present each task result to user.' It doesn't explicitly state whether it modifies files, but the generation nature is clear enough; a 4 reflects the useful context without contradiction.

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 and front-loaded with the core purpose, then adds essential sequencing and follow-up actions. Every sentence contributes value, with no redundant phrasing or 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?

Given the tool's role in a multi-phase pipeline and the lack of an output schema, the description is thorough: it covers preconditions, per-task invocation, dependency order, and next steps (rc_gate, postrc_scan). It provides sufficient context for an agent to invoke the tool correctly without needing further clarification.

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 100%, so the baseline is 3. The description repeats the task_id format and adds the constraint 'valid task_id from the task list,' but this is minor. It does not meaningfully extend the parameter meanings beyond the schema, so a 3 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 the tool's function: 'generates implementation guidance' for a specific task_id, distinguishing it as a per-task Phase 6 (Forge) step. It explicitly contrasts with siblings by saying 'Call once per task' and mentioning alternatives like rc_gate and postrc_scan, eliminating 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?

The description provides explicit when-to-use and sequencing: 'Call this for EACH task in sequence, respecting dependency order,' with prerequisites 'Phase 5 gate approved, valid task_id from the task list.' It also names follow-up tools (rc_gate, postrc_scan), making alternatives 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the need for user consent, the state transitions after each decision, and the special timing for Step 6 checkpoints, which goes beyond a simple 'submit decision' statement.

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 succinct but information-dense, with the main purpose stated in the first sentence and the critical usage caution immediately following. All sentences add value, though the checkpoint schedule could be more condensed; still, it is well-structured and 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?

Given the complexity of a gate tool with multiple decision paths and no output schema, the description covers the essential workflow: user approval, decision meanings, and follow-up actions. It also notes the special case of Step 6, making the behavior fairly complete for an agent to use 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 covers all 4 parameters with descriptions, but the description adds meaningful context to the decision parameter by explaining that 'approve' advances the step, 'reject' stays and requires a reason in feedback, and 'question' pauses for clarification. This clarifies the impact of each choice beyond the schema's type descriptions.

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 tool's function: submitting the user's checkpoint decision for the current RC Method step. It distinguishes itself from sibling gate tools by referencing the RC Method step count (all 8 steps) and specific step 6 behavior, indicating it is not for PRC or post-RC phases.

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 instructs to NEVER call without first presenting step output and getting user approval, providing a clear precondition. It also details the consequences of each decision (approve advances, reject stays, question pauses), giving the agent guidance on how to proceed after the call.

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?

Beyond annotations (idempotent, non-destructive, not read-only), the description discloses output location (rc-method/diagrams/), the three file types, and that results are browser-viewable. It also notes the prerequisite. This adds useful behavioral context, though it does not mention failure handling or whether files are overwritten, but the idempotent annotation covers rerun safety.

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: the first establishes the primary action, the second details concrete outputs and prerequisites, the third states the save location and result. Every sentence earns its place, and the structure front-loads the most important information.

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's moderate complexity and lack of an output schema, the description sufficiently explains what is generated, where it is saved, and prerequisites. It does not explain return values or error scenarios, but for a file-generating tool with these annotations, the provided information is nearly 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?

Schema description coverage is 100%, with both parameters (project_path and project_name) already well-documented in the schema. The description adds no extra parameter semantics, so the baseline of 3 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 'Generate architecture diagrams from the task list' and enumerates the three specific diagram types (dependency graph, Gantt timeline, architecture layers). This distinguishes it from sibling workflow tools like rc_sequence or rc_architect, making its purpose immediately 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 provides a critical prerequisite: requires rc_sequence to have been run first, and specifies where task data must reside (rc-method/tasks/). It implies when to use by mentioning the dependency, though it does not explicitly name alternatives or exclusions. The context is clear enough for correct selection.

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?

No annotations are present, so the description carries the burden. It discloses the prerequisite (Phase 1), the return of a report and gate prompt, and the post-approval phase transition. It lacks details on side effects or error handling, but the key stateful behavior is revealed, warranting a 4 rather than a 3.

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, dense paragraph that front-loads the phase and provides a step-by-step sequence. Every sentence contributes necessary workflow information with no filler, making it efficient and well-structured.

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 no output schema, the description explicitly states the return value (report + gate prompt), the required input (user answers), the prerequisite, and the next action (rc_gate). This fully contextualizes the tool within the larger pipeline, leaving no critical gaps.

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 covers 100% of parameters, so baseline is 3. The description adds value by explaining that discovery_answers come from rc_start, providing source context and clarifying when to pass them, which goes beyond the schema's basic property descriptions.

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 identifies the tool as Phase 1 (Illuminate), specifies the verb 'Generates an Illuminate Report' summarizing problem space, users, and constraints, and distinguishes it from sibling phase tools by explicitly sequencing the workflow relative to rc_start and rc_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?

Explicitly states to call after rc_start, requires Phase 1, instructs to use rc_gate for approval, and describes the transition to Phase 2. This provides clear when-to-use and next-step guidance, effectively differentiating from 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?

With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: auto-approves Phases 1-2, advances to Phase 3, and skips certain steps. However, it does not detail filesystem side effects or whether existing RC files are overwritten, a minor gap for a transformation 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?

Every sentence earns its place: usage timing, transformation summary, prerequisites, next step, and skipped tools. The description is information-dense without fluff, and the purpose is front-loaded in the first sentence.

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 process-step tool with one parameter and no output schema, the description provides all necessary context: when to call it, prerequisites, what it does, what to do next, and what not to call. An agent can select and invoke this tool correctly based on the description alone.

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 already covers the single parameter (project_path) with 100% coverage, including the note about 'pre-rc-research/ subdirectory'. The description reinforces this prerequisite but adds no new syntax or parameter-level details, so the baseline of 3 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 the tool 'converts the 19-section Pre-RC PRD to 11-section RC format', naming the specific resource and transformation. It also distinguishes itself from siblings by positioning as a bridge between Pre-RC and RC phases, and explicitly says it skips rc_start/rc_illuminate/rc_define.

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 context is explicit: 'Call after prc_synthesize completes and user wants to continue building.' Prerequisites are listed ('pre-rc-research/ directory must exist with Gate 3 approved'), and the next step is given ('call rc_architect'). It also names the tools to skip and why, providing clear when-to-use vs 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?

The description adds context beyond the annotations: it reveals that the tool detects project state across all domains, routes to the next tool, and defaults to Pre-RC research. The annotations already declare it read-only, idempotent, and non-destructive, so the added behavior about state detection and routing is valuable. It does not contradict 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 front-loaded with 'START HERE' and organized into a clear purpose statement, usage scenarios, trigger phrases, and default behavior. It is concise for the amount of context provided, with no filler or redundant phrasing. Every sentence contributes to the agent's ability to understand the tool.

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's role as a complex gateway with no output schema, the description adequately explains what the tool does and what to expect (it tells you exactly which tool to call next). It covers the key user intents and default behavior. It could be slightly more explicit about the return format, but the combination of description and annotations is sufficient for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100% with clear parameter descriptions for project_path, brief, and skip_research. The description does not add significant parameter-level detail; it only implies that 'brief' is for new projects and 'skip_research' relates to the default behavior. The schema already carries the semantic weight, so a baseline score of 3 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 identifies rc_init as the 'START HERE' gateway for the RC Engine pipeline, with explicit verb+resource ('Call this when starting a new project, resuming where you left off, or checking project status'). It distinguishes itself from sibling tools by positioning itself as the unified entry point and routing tool, not a domain-specific 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?

It provides explicit when-to-use scenarios (new project, resume, status check) and even lists trigger phrases. It explains the default behavior for new projects and directs the user to prc_start, effectively naming an alternative. This gives clear guidance on when to invoke rc_init over the many 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only, safe to call anytime,' which is a valuable safety guarantee. It also describes the output content (token usage totals, registered domain summary). While it doesn't cover every edge case (e.g., potential delays or failures), the key behavioral trait of safety is well conveyed.

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 appropriately sized at five short sentences, each serving a distinct purpose: what it is, safety, output summary, primary use case, and alternative tools. It is front-loaded with the core purpose and contains no redundant or filler content.

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 read-only tool with one parameter and no output schema, the description fully covers its purpose, usage context, safety profile, and relationship to sibling tools. It provides enough context for an agent to know exactly when and how to invoke it, and what to expect.

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 100% coverage for the single parameter (project_path), so the baseline is 3. The description does not add any additional meaning about how to use the parameter, but the schema's description ('Absolute path to the project directory') is sufficient. There is no extra semantic value from the description, but no deficit either.

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 tool's purpose: 'High-level overview of the entire pipeline' and specifies what it shows ('token usage totals and registered domain summary'). It distinguishes itself from sibling status tools by positioning as the high-level counterpart to domain-specific ones.

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?

Explicit guidance is provided: 'Call this FIRST when starting a new session... or when the user asks for a big-picture status.' It also names specific alternatives for detailed per-domain progress (prc_status, rc_status, postrc_status, trace_status), clearly identifying when not to use this tool.

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?

Since no annotations are provided, the description fully discloses the destructive nature: 'DESTRUCTIVE - requires explicit confirmation.' It details what gets cleared (checkpoint store and markdown state file) and the state after success, providing transparency about side effects without relying on 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 concise and well-structured: it leads with the action and resources, then states destructive nature, usage context, and subsequent steps in three efficient sentences. No redundant or filler content.

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 reset tool with no annotations and no output schema, the description provides a complete picture: purpose, affected state, safety requirement, when to use, and what to do next. It covers all necessary context for an agent to select and invoke the 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 input schema already covers both parameters with 100% coverage, including the necessity of confirm being true and project_path being an absolute path. The description adds minimal parameter meaning beyond schema, only reinforcing the confirmation requirement already described 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 description clearly identifies the tool's purpose: resetting RC Method pipeline state. It specifies the exact resources affected (checkpoint store and markdown state file), distinguishes it from sibling tools like rc_start and rc_init, and uses an imperative verb ('Reset') that matches the tool name.

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: 'Use when the user wants to start over or abandon current progress.' It also provides clear post-conditions and next steps ('After success: pipeline is clean, call rc_start or rc_init to begin again'), giving actionable 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?

No annotations are present, so the description carries the full disclosure burden. It explains the file destinations for each artifact type and the passthrough nature. It does not mention overwrite behavior or return values, but covers the core semantics well.

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 and front-loaded with 'PASSTHROUGH MODE ONLY'. Each sentence serves a purpose: scope, usage, type mapping, and exclusions. It is slightly dense but not wasteful, earning a strong score.

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 3 required parameters, no output schema, and no annotations, the description covers purpose, usage, types, and destinations. It doesn't explain overwrite behavior or success confirmation, but these are minor for a passthrough save operation. Overall it is quite 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?

Schema coverage is 100%, giving a baseline of 3. The description adds meaningful context by mapping artifact_type values to concrete paths (prd->rc-method/prds/, etc.) and clarifies that content is the full artifact text. This goes beyond the schema's enum descriptions.

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 tool saves host-IDE-generated artifacts into the RC Method file structure. It differentiates from siblings by specifying 'PASSTHROUGH MODE ONLY' and naming tools that auto-save, such as rc_define, rc_sequence, and ux_generate.

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?

Provides explicit when-to-use guidance ('Use when the IDE's own AI generated a PRD, UX PRD, or task list') and when-not-to-use ('Do NOT use for artifacts already saved by rc_define, rc_sequence, or ux_generate'). This clearly steers the agent away from redundant usage.

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 the full burden of behavioral disclosure. It explains the automation ('No user input needed - reads PRD artifacts automatically'), output location ('Saved to rc-method/tasks/'), and follow-up action ('Present the task list to user for approval'). It does not detail error conditions or idempotency, but covers the primary behavior thoroughly.

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 multi-sentence but each sentence adds a discrete piece of information: phase, action, output details, automation, approval step, prerequisites, and next phase. It is front-loaded with the core purpose and remains efficient without redundancy.

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 one parameter and no output schema, the description is remarkably complete. It covers inputs (PRD and architecture), process (auto-generation), outputs (task list saved to a path), user interaction (present for approval), and workflow position (Phase 4, after Phase 3 gate, moving to Phase 5). An agent receives enough context to invoke and act on the result.

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

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

The input schema has one parameter (project_path) with a clear description ('Absolute path to the project directory'), giving 100% schema coverage. The tool description does not add meaning beyond the schema—it mentions reading PRD artifacts and saving tasks, but does not explicitly tie these to project_path. Baseline of 3 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 the tool auto-generates a 'sequenced, dependency-ordered task list' from the approved PRD and architecture. It specifies the output format (task IDs, effort, dependencies) and distinguishes itself as 'Phase 4 (Sequence)' within a multi-phase workflow, separating it from sibling tools like rc_architect or rc_validate.

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 clear context: prerequisites ('Phase 3 gate approved'), the action to take after ('Present the task list to user for approval'), and the next phase ('After gate approval: moves to Phase 5 (Validate)'). It lacks explicit alternatives or when-not-to-use statements, but the phase-based positioning and prerequisites serve as adequate 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?

No annotations are provided, so the description carries the full burden. It discloses side effects (creates rc-method/ directory, project state, begins Phase 1) and return behavior (returns discovery questions). It does not cover error conditions or idempotency, but the key behaviors are disclosed well.

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 four sentences, each earning its place: initial purpose, usage condition, side effects/return value, and post-success action. Front-loaded and free of fluff.

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's complexity and absence of an output schema, the description explains the return value (discovery questions), the user interaction required, and the follow-up tool call. Minor gaps (e.g., error handling) are acceptable because the pipeline context is clear.

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 100% for all 3 parameters, so the schema already documents them. The description adds context about project state but no additional parameter-level meaning beyond what the schema provides, so baseline 3 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 the tool starts the RC Method without Pre-RC research, using a specific verb ('Start') and resource ('RC Method'). It explicitly contrasts with rc_import_prerc, distinguishing it from sibling tools.

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?

Provides explicit when-to-use ('when user wants to go straight to building'), when-not-to-use ('Do NOT use this if Pre-RC was run'), and names the alternative (rc_import_prerc). It also instructs the next step after success (call rc_illuminate).

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 the full burden. It explicitly states 'Read-only, safe to call anytime' and details the return structure (phase, gate statuses, artifacts, UX score). It adds context about conditional UX score and gate verification, though it doesn't discuss error conditions or format details.

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 slightly longer than the minimal two-sentence example but every sentence adds value: purpose, safety, return values, and use cases. It is front-loaded with the main action and well-structured, though not as terse as the ideal.

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?

Despite no output schema or annotations, the description sufficiently explains the return values and provides rich usage context. It covers the key decision points and verification workflow, making it complete for a status-check 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 100%, so the parameter is fully documented in the schema ('Absolute path to the project directory'). The description does not add additional parameter-specific meaning beyond what the schema provides, so the baseline 3 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 the verb 'Check' and resource 'RC Method progress', and specifies the return values (phase, gate statuses, artifacts, UX score). It also differentiates itself from siblings by framing as an orientation/status tool for RC methods, with use cases like resuming a session or verifying a 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 provides explicit usage contexts: resuming a session, answering 'where are we?', before deciding which rc_ tool to call next, and verifying a gate after rc_gate. It lacks explicit mention of when NOT to use or naming alternatives, but the context is clear enough for a 4.

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 the full transparency burden. It discloses that the tool runs automated checks, catches problems before code, requires no user input, and presents findings with severity ratings. However, it does not state whether the tool modifies project state or is read-only, which is a minor gap for a quality gate.

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 phase and purpose, and structured logically. The sentence 'This catches problems BEFORE code is written - saving significant rework' is beneficial but slightly contributes to length; still, almost all content 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?

Given the simple input schema (single param) and no output schema, the description provides good pipeline context: phase, preconditions, checks, output (findings with severity), and next step. It lacks an explicit statement about return structure or side effects, but is otherwise complete enough for an agent to use it correctly.

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

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

Schema coverage is 100%: the only parameter 'project_path' is described as 'Absolute path to the project directory'. The description adds no parameter-specific information, so baseline 3 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 explicitly labels the tool as 'Phase 5 (Validate)' and 'QUALITY GATE before building', then enumerates four specific automated checks (anti-pattern scan, token budget audit, scope drift detection, UX quality assessment). This clearly distinguishes it from building/synthesis tools like rc_forge_task.

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?

Provides clear sequencing: 'Prerequisites: Phase 4 gate approved' and 'After gate approval: moves to Phase 6 (Forge) - begin building with rc_forge_task'. Also states 'No user input needed', which handles the interaction model explicitly.

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 fully discloses behaviors: auto-discovery in two directory paths, deterministic ID categories, autonomous-mode acceptance criteria, creation of a traceability matrix, and a guarantee that the original PRD is not modified. This exceeds typical transparency and includes a helpful post-action instruction.

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 dense but well-organized, opening with the core action and following with execution timing, discovery paths, ID format, mode-specific behavior, and post-action guidance. Each clause adds value; 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 tool with no output schema or annotations, the description is quite complete: it covers when to call, what it does, where artifacts are created, what the user should be told, and the critical non-mutation guarantee. It lacks error handling details or explicit return format, but these are not essential for 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 coverage is 100%, so the baseline is 3. The description enriches prd_content by naming the exact auto-discovery directories and explains the ID-generation logic, giving the agent a clearer mental model of how the parameters are used.

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 ('Assign tracking IDs to every requirement in the PRD') and resource (PRD), then distinguishes itself from sibling tools by specifying its pipeline position (after rc_define/prc_synthesize, before building) and its non-mutating behavior. It clearly separates from trace_status and trace_map_findings.

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?

Explicit timing guidance is given: 'Call after PRD is created (rc_define or prc_synthesize) and BEFORE building.' The description also indicates the tool is appropriate when a PRD exists in standard locations. It does not explicitly name alternatives or exclusions, but the context is sufficient.

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 provided, the description carries the full burden of behavioral disclosure. It reveals that the tool generates an HTML report, calculates coverage metrics, and presents gaps to the user, including the assertion that orphan requirements are the most critical signal. It does not mention side effects or return format, but these are likely expected for a reporting 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?

The description is information-dense and well-structured. It opens with the most critical usage instruction ('Run AFTER...'), then details functionality and outputs, and closes with a user-facing directive. Every sentence adds value, and the text is appropriately sized for the tool's complexity.

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 one parameter, no output schema, and no annotations, the description covers all essential aspects: prerequisites, what it does, what it calculates, what it generates, and what action to take with results. It is fully self-contained.

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 already has 100% coverage for the single parameter (project_path) with a clear description ('Absolute path to the project directory'). The tool description does not add additional meaning about the parameter, so the baseline of 3 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 the tool's purpose: it maps Post-RC findings and RC task completions back to requirement IDs from trace_enhance_prd, and calculates specific metrics. It uses specific verbs ('maps', 'calculates', 'generates') and distinct resources, making it easy to differentiate from sibling tools like trace_status or postrc_report.

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 states when to run the tool ('Run AFTER both building and scanning') and lists prerequisites (trace_enhance_prd must have been run, ideally postrc_scan completed). It provides clear sequencing context, though it does not explicitly name alternative tools for exclusion, which prevents a perfect score.

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 provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'Read-only, safe to call anytime' and lists the exact return values (coverage percentages, orphan lists). It also notes the prerequisite dependency on trace_enhance_prd, giving the agent a complete safety and dependency picture.

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 three sentences, front-loaded with the purpose, then usage scenarios, then return contents. Every sentence earns its place with no repetition or fluff. It is tightly structured and highly scannable.

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

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

Given the tool's simplicity (one parameter, no output schema), the description provides complete context. It explains what the tool does, when to use it, what it returns, and its prerequisite. The usage guidance and return listing make it fully self-contained for an agent.

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 100% description coverage for the single parameter 'project_path', so the baseline is 3. The description adds no additional parameter-specific context beyond implying the tool operates on a project. It neither enriches nor contradicts the schema, so a baseline score 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 opens with a specific verb and resource: 'Check traceability coverage.' It also lists concrete outputs (total requirements, implemented count, etc.), making the tool's function unmistakable. While it doesn't explicitly name sibling alternatives, the unique focus on coverage percentages and orphan lists distinguishes it from trace_enhance_prd and trace_map_findings.

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 states when to use the tool: 'Use when user asks "what percentage is done?" or "what did we miss?"' It also gives a temporal constraint ('after trace_enhance_prd') and a secondary use case ('mid-build to track progress'). This provides clear guidance on both when and when not to use it.

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 provided, the description carries the full burden. It discloses that the tool returns findings with severity, rule citations, and fix suggestions, and that task_type routes to specialist modules. However, it does not explicitly state whether the audit is read-only or if it has side effects, which would be valuable for an agent.

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 composed of four sentences that flow logically: purpose, usage timing, parameter semantics, and output. It is front-loaded with the main action and provides necessary details without excessive fluff. A slightly tighter wording could be achieved, but it remains concise and 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 tool has moderate complexity with specialist modules and rich output, and the description covers purpose, usage, routing, and output. There is no output schema, but the description mentions findings with severity and citations, which is sufficient. It could benefit from explicit differentiation from sibling tools like ux_score, but overall it is complete enough for an agent.

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

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

Schema coverage is 100%, so the schema already describes both parameters. The description adds context by explaining that task_type controls which specialist modules load and lists possible values, but this largely mirrors the schema description. The description does not add substantial new 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 clearly states the tool audits UI code or screen descriptions against 42 core UX rules plus specialist modules, using the verb 'Audit' with a specific resource and scope. It distinguishes itself from sibling tools like ux_score and ux_generate by focusing on audit and rule compliance.

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?

Provides clear timing guidance ('during or after Forge (Phase 6)') and suggests using it before postrc_scan to catch UX issues. It does not explicitly list exclusions or alternatives beyond postrc_scan, but the context is sufficient for an agent to decide when to invoke it.

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 provided, the description carries the full burden. It discloses the tool's output (design spec + HTML wireframes, lo-fi and hi-fi), the basis for generation (ICP, competitor gaps, design trends), and the file system side effect ('Saves to rc-method/design/'). It does not describe the return format or potential overwrites, but it is reasonably transparent for a generation 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?

The description is three sentences, each serving a distinct purpose: stating the core function, describing the output and context, and providing parameter guidance. It is front-loaded with the primary verb and resource, with no filler or redundancy.

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?

There is no output schema, but the description covers the essential context: what the tool produces, the filesystem destination, the phase in which it should be called, and the parameter choices. It lacks details about the return value and error conditions, but for a design-generation tool that saves files, the provided information is largely sufficient for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the practical use of option_count ('budget-conscious' vs 'full comparison'), which goes beyond the schema's simple description. It also ties the inspiration parameter to 'design references' implicitly through the mention of design trends. This is meaningful extra 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 uses a specific verb ('Generate') with a concrete resource ('visual design options with HTML wireframes'), and clearly states what it produces: 1 or 3 design options including design specs and lo-fi/hi-fi wireframes. It distinguishes from sibling tools by specifying the output format (HTML wireframes) and the phase context (after PRD creation).

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 guidance ('Call after PRD is created (Phase 2+)') and provides conditional usage advice for the option_count parameter ('Pass option_count=1 for budget-conscious, option_count=3 for full comparison'). It does not explicitly state when not to use the tool or mention alternative tools, but the context is 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?

No annotations are provided, so the description carries the full burden. It discloses the output file location (rc-method/prds/), the list of generated artifacts, and downstream usage. However, it does not mention whether the tool overwrites existing files or requires the main PRD to already exist, which is a minor transparency gap for a file-generation 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?

The description is dense but each sentence serves a purpose: what it does, when to use it, what it produces, where it saves, what input to pass, and downstream usage. There is no redundant content; every sentence adds essential context, making it appropriately sized and front-loaded with the core purpose.

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's complexity and lack of an output schema, the description covers all essential aspects: the generated artifacts, file location, input requirements, and how the output integrates with subsequent phases and tools. It is complete for an AI agent to understand the tool's role and execute it correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning by restating 'Pass descriptions of the screens and user flows,' which closely mirrors the screens_description schema description. It does not introduce new syntax, format, or parameter-specific constraints beyond the schema, so the baseline of 3 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 the tool generates a UX child PRD with a specific filename pattern (PRD-[project]-ux.md), enumerates the artifacts it produces (screen inventory, state contracts, etc.), and distinguishes itself from sibling tools by referencing ux_score and its downstream consumers.

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 specifies when to call the tool: during Phase 2 (Define) and only when ux_score returns selective or deep_dive_mode. It also mentions prerequisites (passing descriptions of screens and flows) and provides context on how the output is consumed later (rc_validate, rc_forge_task), clearly indicating the tool's role in the overall workflow.

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 provided, the description fully carries the transparency burden. It explicitly states 'Read-only analysis' and 'Does NOT require project_path - works on any feature list,' disclosing safety and scope constraints. It also details the return value structure (numeric score, mode, modules) and the absence of hidden side effects.

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 and well-structured. Each sentence contributes: purpose, input, return values, decision guidance, and a note on portability. It is front-loaded with 'OPTIONAL - call during Phase 2' and is free of fluff 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?

Given the tool's simple one-parameter design and lack of output schema, the description is complete. It explains when to use it, what to pass, what it returns, and how to interpret the result within the pipeline (calling ux_generate or skipping). No additional information is needed 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 already describes the sole parameter 'feature_list' at 100% coverage, so baseline is 3. The description adds meaningful context: 'Pass the feature list from the PRD' and 'works on any feature list,' which clarifies the origin and flexibility of the input. This extra semantic guidance justifies a 4.

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 tool's purpose: 'call during Phase 2 (Define) to assess UX complexity.' It specifies the input (feature list) and output (numeric score, mode, modules), and distinguishes itself from sibling tools like ux_generate by explaining how results guide the next step. The verb 'assess' and resource 'UX complexity' are specific and 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 provides explicit when-to-use guidance: 'call during Phase 2 (Define)' and 'Pass the feature list from the PRD.' It also gives alternative handling: 'Use the result to decide whether to call ux_generate (for deep_dive/selective) or skip UX child PRD (for standard).' This directly addresses decision-making and differentiates from siblings.

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