PlanExe

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context beyond annotations: 'No API key required' and that the output is a curated preview. This is useful behavioral disclosure without contradicting 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 three sentences, front-loaded with the core function, then the usage scenario. Every sentence earns its place, with 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?

The tool is simple (0 params, read-only), has an output schema, and annotations describe safety. The description fully covers purpose, usage, and access requirements, making it complete for an agent to decide when and how to invoke it.

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

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

The tool has zero parameters, so the schema covers everything. Per the baseline for 0 params, a score of 4 is appropriate. The description adds no parameter-specific meaning, but none is needed.

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 ('Returns') and resource ('a curated list of example plans with download links for reports and zip bundles'). It distinguishes from siblings like plan_list by emphasizing 'curated' example plans rather than user-created ones, and the preview purpose is clear.

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

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

The description explicitly tells when to use the tool: 'to preview what PlanExe output looks like before creating your own plan' and 'especially useful when the user asks what the output looks like before committing to a plan.' It does not name alternative tools explicitly but implies the alternative is creating a plan, which is sufficient context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral guidance beyond annotations: it mandates the tool to be called first, warns against calling plan_create prematurely, and outlines the exact downstream workflow and prompt-style expectations. This is valuable context that annotations do not convey.

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

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

The description is long but every sentence earns its place. It front-loads 'Call this first' and then provides a logically ordered sequence of actions, prompt shape guidelines, stylistic instructions, and a clear next step. Nothing is redundant or filler; the length is justified by the need to explain the non-tool step and workflow.

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 there are no parameters and the tool has an output schema, the description is fully complete. It explains the tool's purpose, its place in the overall workflow, alternatives, and detailed follow-up actions. The agent has everything it needs to correctly invoke and use this tool.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and it doesn't; it focuses on usage guidance. Since there are no parameters to misinterpret, this 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 clearly states that the tool returns example prompts and defines what a good prompt looks like. It also distinguishes this tool from siblings by positioning it as the first step and explicitly telling the agent not to call plan_create yet, making its unique role 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?

The description provides explicit when-to-use guidance: call this first, do not call plan_create yet, optionally call model_profiles, then follow a non-tool step, and only then call plan_create. It also includes clear exclusions for the overall workflow (PlanExe is not for tiny outputs and doesn't support selecting only some steps), giving an agent all the context needed to decide when this sequence 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by disclosing the specific error code 'MODEL_PROFILES_UNAVAILABLE' when no models are available, which is useful behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary purpose and usage context, with no wasted words. It efficiently covers what the tool does, when to use it, and the error condition.

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 (no params, output schema present, annotations complete), the description fully covers purpose, usage timing, and error behavior. No critical information is missing 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 tool has zero parameters, so per the rubric the baseline is 4. The description does not need to explain any parameters, and the schema coverage is 100% vacuously.

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 ('Returns') and resource ('model_profile options') with specific details about guidance and available models. It also positions the tool as a helper before plan_create, distinguishing it from siblings like plan_create and example_plans.

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 phrase 'Optional helper before plan_create' explicitly indicates when to use this tool, and 'optional' implies it can be skipped. However, it doesn't name alternatives or provide exclusion criteria, so it stops short of a full when/when-not guideline.

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 idempotent/open-world annotations, description adds rich behavioral detail: async ~10-20 min generation, deduplication on repeated prompts, SSE stream auto-close, and credit/api_key handling. No contradiction with annotations.

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

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

A long description, but the section list and operational details are purposeful for a high-stakes async creation tool. It opens with the most critical prerequisite and keeps related considerations in logical order, though a structured layout would improve scannability.

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?

Covers return value (plan_id), subsequent steps (plan_status, plan_retry, etc.), error codes, dedup behavior, and SSE completion detection. Despite no visible output schema, the description gives enough operational context to invoke and monitor the tool successfully.

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 prompt, start_date, and model_profile with descriptions; description adds selection guidance for model_profile ('call model_profiles first') and credential handling (user_api_key for credits). This exceeds schema baseline but doesn't deeply explain start_date or prompt formatting.

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

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

States a specific action: PlanExe turns the approved prompt into a strategic project-plan draft with 20+ sections. It explicitly differentiates the tool from siblings by requiring prior example_prompts and by returning a plan_id for downstream plan_* 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?

Explicitly says 'Call only after example_prompts and after you have completed prompt drafting/approval.' Also tells when to use model_profiles, plan_status, and plan_list alternatives. Provides strong when-to-use and fallback guidance.

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

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

The description discloses important behavioral traits not covered by annotations: returns {ready:false,reason:'processing'} while pending, download URLs expire after 15 minutes, terminal error codes (generation_failed, content_unavailable), and PLAN_NOT_FOUND for unknown IDs. This adds substantial context to the benign read-only/idempotent annotation 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 front-loaded with the core purpose, then systematically covers artifact choices, readiness, URL expiration, and error conditions. Every sentence contributes unique information; length is justified by the tool's complexity and no content is redundant.

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

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

With no output schema, the description fully documents return values (metadata fields, ready:false response), error codes, and expiration behavior. It also explains how to use the results and the relationship to plan lifecycle. This is comprehensive for a 2-parameter, 1-required-parameter tool.

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

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

The input schema already covers both parameters with descriptions (100% coverage). The tool description goes beyond by explaining the semantic difference between artifact options ('report' = interactive HTML with embedded JS; 'zip' = full pipeline bundle of intermediate files), and describes plan_id as returned by plan_create. This adds value beyond the schema's enum and basic types.

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 purpose: 'Returns file metadata (content_type, download_url, download_size, expires_at) for the report or zip artifact.' It clearly distinguishes the two artifact types and the tool's role as a file info/download utility, which is distinct from sibling plan-management tools like plan_status or plan_create.

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?

Detailed usage instructions are provided: when to use artifact='report' vs artifact='zip', how to check readiness by testing for download_url, what to do with the result, and how to handle expired URLs by calling again. This goes beyond simple when-to-use and includes 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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral details: return fields, newest-first ordering, default/max limit, and 100-character excerpt. 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?

Two concise sentences with no fluff. Key purpose is front-loaded, and the second sentence adds practical use cases. Every word earns its place.

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

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

For a simple list tool with one optional parameter and an output schema, the description is complete. It covers purpose, return format, limit behavior, and use cases, 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 coverage is 100% and the schema already describes the limit parameter with default, min, max, and 'newest first' behavior. The description reiterates this without adding significant new 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 clearly states the tool lists recent plans for an authenticated user, with specific resource and scope. It also distinguishes from siblings like plan_create and plan_status by focusing on listing/recovering recent activity.

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 usage guidance is provided: 'Use this to recover a lost plan_id or to review recent activity.' This tells the agent when to use it and implies alternatives for other operations.

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 provides rich behavioral detail beyond the annotations: it explains that completed files are not discarded, generation resumes from the first incomplete step, and it lists specific error codes (PLAN_NOT_FOUND, PLAN_NOT_RESUMABLE, PIPELINE_VERSION_MISMATCH) with guidance for the version mismatch case. This significantly exceeds the annotation flags and gives the agent a clear picture of the tool's side effects and failure modes.

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 solid paragraph of seven sentences, each sentence contributing useful information (purpose, mechanics, usage conditions, alternatives, constraints, and errors). It is not as tight as a two-sentence description, but it remains well-structured and free of filler, 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?

With a 2-parameter schema fully described and an output schema present, the description covers all essential aspects: purpose, when to use, alternative tools, state constraints, and error conditions. It does not describe the exact return structure, but that is adequately delegated to the output schema. Minor gaps like explicit permission prerequisites are absent, but the error handling and context signals make the tool well-understood.

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 (plan_id and model_profile) with clear descriptions, achieving 100% schema coverage. The tool description adds little beyond the schema—it references model_profile only when directing users to plan_retry for changes, which reinforces but does not extend the schema semantics. 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 identifies the tool's purpose: resuming a failed or stopped plan while preserving completed intermediate files. It also distinguishes itself from plan_retry by stating that plan_retry is for full restarts or model_profile changes, which helps an agent differentiate between the two.

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 plan_resume: when plan_status shows 'failed' or 'stopped' and interruption occurred before all steps completed. It also provides a clear alternative, plan_retry, for full restarts or changing model_profile, and specifies that only failed or stopped plans can be resumed.

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?

This description directly contradicts the annotations: the annotation destructiveHint=false indicates the tool is not destructive, yet the description states 'prior artifacts are cleared'. Clearing artifacts is a destructive action. This is a serious inconsistency that fails to provide trustworthy behavioral disclosure, so the score is the minimum.

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 action and state condition, followed by behavior and error results. It contains no fluff and every sentence adds value. However, it is somewhat long and could be tightened without losing information, so it doesn't achieve a perfect 5.

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 main action, preconditions, behavioral effects, and error conditions. An output schema exists, so return value details are not required. The main gap is the contradiction with the destructiveHint annotation, which undermines trust, but the description itself is otherwise complete for an agent to decide and invoke the 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% for both parameters. The description only restates what is already in the schema (e.g., 'model_profile defaults to baseline') without adding extra semantic meaning, such as type constraints, dependencies, or edge cases. Baseline of 3 is appropriate when the schema does the heavy lifting.

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 ('Retry'), the target resource ('a plan'), and the exact condition ('currently in failed or stopped state'). It is specific and unambiguous, but it does not explicitly compare or contrast with the sibling tool plan_resume, so it misses the full 5-point bar for sibling differentiation.

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

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

The description explicitly says the tool should be used when a plan is in 'failed or stopped state', which provides clear context for when to use it. However, it does not mention any alternatives or exclusions (e.g., when to use plan_resume instead), so it lacks explicit 'when-not-to-use' guidance that would earn a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial behavioral context: the full state machine (pending/processing/completed/failed/stopped), exact error dict structure, stall detection heuristics (>10 minutes), queuing threshold (>5 minutes), and the note that progress_percentage is an integer-like float. It even discloses that steps vary in duration, so time estimation is unreliable. No contradiction with annotations.

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

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

The description is long but well-organized into a coherent flow: core purpose, state contract, field explanations, troubleshooting thresholds, and error diagnostics. It front-loads the key message and every sentence carries actionable information. Slight verbosity in repeating timing-related mentions (last_progress_at, updated_at) could be tightened, but the density justifies the length.

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

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

With no output schema, the description fully carries the burden of explaining the response shape, including all progress fields, the error dict, nullable fields, and timing semantics. It covers every state, provides concrete threshold values for detecting stalls/queues, and even links to the issue tracker for troubleshooting. This is complete for a complex state-monitoring tool.

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

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

The single parameter plan_id is fully described in the schema ('Plan UUID returned by plan_create'), giving 100% schema coverage. The description adds only a minor behavioral detail about the PLAN_NOT_FOUND error for unknown plan_id, which is useful but not essential. Since the schema already carries the semantic weight, the description provides no significant additional parameter-level meaning.

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 clear and specific statement: 'Returns status and progress of the plan currently being created.' This names the exact resource (plan status) and the action (returns status/progress), and it differentiates from siblings like plan_list (list plans) and plan_file_info (file info) by highlighting 'currently being created' and 'primary way to check progress.'

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 positions itself as the primary progress-check tool and provides detailed polling guidance (every 5 minutes), state-contract triggers (keep polling, download ready, terminal error), and remediation steps (use plan_stop then plan_retry on stall; plan_resume on recoverable failure). It also advises using file updated_at as a fallback, giving clear when-to-use and when-to-alternate guidance.

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

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

The description discloses asynchronous behavior (stop flag set immediately, plan may continue briefly), state transition to 'stopped', return semantics ('stop_requested returns false' for already finished plans), and error handling (PLAN_NOT_FOUND). These go far beyond the annotations, which only indicate destructive and idempotent 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 four sentences, front-loaded with the core action, and each sentence adds distinct value: usage, async behavior, state transition, and error cases. 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?

With one parameter, complete schema coverage, annotations, and an output schema, the description covers all necessary context: how to invoke, what to expect, edge cases, and error codes. It is fully sufficient for an agent to use 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 schema description for plan_id already explains it as the UUID returned by plan_create. The tool description mirrors this without adding extra details about format or additional constraints. With 100% 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 action 'Request the plan generation to stop' with a specific verb and resource. It distinguishes from siblings by focusing on the stop operation, whereas siblings like plan_create, plan_list, and plan_resume handle other 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 provides clear context on when to use the tool: pass the plan_id from plan_create, and notes that already completed/failed plans don't need stopping. It does not explicitly name alternative tools or list when not to use it, but the behavior is well implied.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds 'fire-and-forget, never blocks' and 'callable at any point', which are useful behavioral traits. These enrich the agent's understanding of side effects and execution semantics without contradicting any annotation.

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

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

The description is a single, well-organized paragraph that front-loads the purpose. Each sentence contributes unique information: what, when, categories, rating, plan_id, use cases, and reporting tips. It is dense but not bloated, with every sentence earning its place.

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

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

Given the presence of an output schema and annotations, the description does not need to explain return values or safety profiles. It thoroughly covers when to use, how to categorize, rating semantics, plan_id linkage, and practical examples of useful feedback. It omits error handling or prerequisites, but these are less critical for a feedback submission 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 baseline is 3, but the description adds significant value by expanding the category values (mcp, plan, code, docs, other) with practical sub-contexts (e.g., mcp includes SSE and plan_status). It also clarifies the rating scale and advises including plan_id and specific details, which goes beyond the schema 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 opens with 'Submit feedback about PlanExe' — a specific verb and resource, which clearly distinguishes it from sibling tools focused on plan management, models, and examples. It also mentions the range of feedback (issues, impressions, suggestions) and states it is callable at any point, making its 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?

It explicitly states when to use the tool ('Callable at any point in the workflow') and enumerates concrete scenarios (SSE streams closing, stale plan_status, queue delays, reviewing plan output quality). While it does not provide explicit exclusions or alternatives, the unique nature of a feedback tool means alternatives are unnecessary; 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.