PlanExe

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

Annotations cover safety profile (readOnly/idempotent/destructive), so description burden is lighter. It adds valuable context not in annotations: 'No API key required' (auth prerequisites) and specifics about downloadable artifacts (reports and zip bundles). 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?

Four sentences structured as: purpose → usage guidance → specific trigger condition → auth requirements. Every sentence earns its place; no redundancy. Front-loaded with the core function (Returns...).

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 has 0 parameters, good annotations, and output schema exists (so return details need not be exhaustively described). Description adequately covers prerequisites (no API key) and use case context given the low 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?

Zero parameters present per schema. Per rating guidelines, 0 params = baseline 4. No parameter documentation required.

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?

Description opens with specific verb (Returns) + resource (curated list of example plans) + scope (with download links for reports/zip bundles). It clearly distinguishes from siblings like plan_list (user's own plans) by positioning this as 'preview what PlanExe output looks like before creating your own plan.'

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: 'Use this to preview... before creating your own plan' and 'Especially useful when the user asks what the output looks like before committing to a plan.' This clearly delineates when to invoke this tool versus plan_create or plan_list.

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

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

While annotations confirm read-only/idempotent safety, the description adds crucial behavioral context: what the output contains (examples), how to use them (~300-800 word baseline, prose style constraints), and workflow dependencies. It explains the expected content structure (objective, scope, constraints, etc.) and formatting requirements (flowing prose, no markdown headers).

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 lengthy but information-dense and well-structured for a complex multi-step workflow tool. It is front-loaded with the critical 'Call this first' instruction. Every sentence provides necessary guidance on sequencing, content requirements, formatting constraints, or system limitations—no 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?

Given the presence of an output schema (covering return structure) and annotations (covering safety), the description provides complete workflow context: preconditions, post-actions, content requirements, and sibling tool relationships. It adequately prepares the agent to integrate this tool into the larger PlanExe 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 tool has zero input parameters (schema coverage 100% of empty set). Per scoring rules, this establishes a baseline of 4. The description appropriately does not invent parameter documentation where none exist.

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

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

The description clearly states the tool 'Returns example prompts that define what a good prompt looks like' using specific verb+resource. It positions the tool as 'Call this first' in the workflow, distinguishing it from siblings like plan_create (which it explicitly says not to call yet) and model_profiles (which is optional).

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 sequential guidance: 'Call this first,' 'Do NOT call plan_create yet,' and 'Optional before plan_create: call model_profiles.' It defines the complete workflow (tool call → non-tool step → user approval → plan_create) and clarifies system limitations ('PlanExe is not for tiny one-shot outputs').

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 cover safety profile (readOnly, idempotent). Description adds valuable behavioral context: content of returns ('plain-language guidance', 'currently available models') and specific error condition ('MODEL_PROFILES_UNAVAILABLE') not inferable from 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 sentences with zero waste. First establishes purpose and relationship to plan_create; second documents error condition. 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?

Appropriately complete for a zero-parameter read-only helper. Mentions error codes and return content. Output schema exists (per context signals), so detailed return documentation is not required in description.

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?

Zero parameters present, warranting baseline score 4. Description correctly focuses on behavior rather than inventing parameter documentation where none exist.

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

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

Specific verb 'Returns' with clear resource 'model_profile options'. Explicitly positions itself as an 'Optional helper before plan_create', effectively distinguishing from siblings like plan_create, plan_list, 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?

Clearly indicates temporal context ('before plan_create') and optional nature. Lacks explicit 'when not to use' or comparison to other helpers like example_prompts, but provides sufficient context for 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?

Beyond annotations (idempotentHint, readOnlyHint), adds critical behavioral details: execution time (10-20 min), deduplication logic ('same prompt + model_profile... short window'), specific error codes (INVALID_USER_API_KEY, INSUFFICIENT_CREDITS), and SSE streaming mechanism for completion detection.

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?

Information-dense but the exhaustive enumeration of 20+ section names consumes significant tokens and could be summarized. The SSE curl command and full list of adversarial sections are useful but reduce front-loading efficiency. Appropriately complex for the tool's capability level, yet structurally heavy.

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?

Comprehensive coverage for a complex asynchronous operation: duration, polling strategy, error recovery paths, deduplication behavior, and credit requirements. Output schema exists, so description appropriately focuses on invocation workflow rather than return value structure.

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 67% (prompt lacks description). Description compensates by specifying 'approved prompt' for the prompt parameter and adding workflow context for model_profile ('call model_profiles first'). Adds note about user_api_key for credit deployments, though this parameter isn't visible in the provided schema properties.

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 specific transformation (approved prompt → strategic project-plan draft with 20+ sections), duration (~10-20 min), and distinguishes from siblings by listing specific output sections and return value (plan_id) used by plan_status/plan_stop.

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?

Excellent explicit prerequisites: 'Call only after example_prompts and after you have completed prompt drafting/approval.' Names specific alternatives for common problems: 'If you lose a plan_id, call plan_list,' 'If you are unsure which model_profile to choose, call model_profiles,' and 'poll plan_status at reasonable intervals' for progress tracking.

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

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

While annotations declare readOnly/idempotent hints, the description adds critical behavioral context: async/pending states (ready:false), URL expiration (15 minutes), polling strategy (check download_url), error codes (generation_failed, content_unavailable, PLAN_NOT_FOUND), and file size (~700KB). 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?

Despite length, every sentence delivers value: return structure, artifact semantics, async behavior, expiration logic, alternative tool preference, and error codes. Well-structured with logical flow from inputs to outputs to error handling, though slightly dense.

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

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

Excellent coverage for a complex async file retrieval tool. Without an output schema, the description comprehensively documents success responses (metadata fields), pending states, expiration behavior, error conditions, and integration patterns with sibling tools (plan_create, plan_download).

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 basic definitions, but the description adds substantial semantic value: explains that 'report' is an interactive HTML file with embedded JS/Gantt charts for browser viewing, while 'zip' contains raw intermediary files (md, json, csv). This goes far beyond the schema's basic 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 explicitly states it 'Returns file metadata' for artifacts, lists the specific fields (content_type, download_url, etc.), and distinguishes between 'report' and 'zip' artifacts with detailed content descriptions. It clearly differentiates from siblings like plan_create (creation) and plan_download (preferred for saving).

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?

Contains explicit guidance: 'Use artifact=report...' vs 'Use artifact=zip...' for different use cases, and explicitly states 'If your client exposes plan_download... prefer that to save the file locally.' Also explains the polling workflow for checking readiness via download_url presence.

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 cover safety profile (readOnlyHint, destructiveHint), but description adds crucial behavioral details: ordering (newest-first), pagination constraints (default 10, max 50), and specific output fields with formatting (ISO 8601 dates, 100-char prompt_excerpt truncation). 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 well-structured sentences: first establishes purpose and detailed output format, second provides usage guidance. Every clause earns its place—no redundancy. Front-loaded with action, includes specific constraints (default/max) inline without bloat.

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?

Fully complete for tool complexity: single optional parameter with 100% schema coverage, good annotations, and output schema exists. Description appropriately details return fields despite external output schema, covering use cases, limits, and data format.

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 'limit' parameter is fully documented in the schema itself. Description references the parameter ('Returns up to `limit` plans') reinforcing the schema, but does not add semantic meaning beyond what the schema already provides. Baseline 3 appropriate for 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?

Excellent specificity: 'List the most recent plans for an authenticated user' provides exact verb (List), resource (plans), scope (most recent, authenticated), and distinguishes from siblings like plan_create or plan_resume by emphasizing read access to 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?

Provides clear contextual guidance with 'Use this to recover a lost plan_id or to review recent activity,' implicitly differentiating from plan_status (which requires a known plan_id) and plan_create. Would be a 5 if it explicitly named alternatives like 'instead of plan_status when you lack an ID'.

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 (readOnly=false, destructive=false), description details exact execution behavior (restarts from first incomplete step, skips completed steps), data preservation guarantees, and three specific error return codes (PLAN_NOT_FOUND, PLAN_NOT_RESUMABLE, PIPELINE_VERSION_MISMATCH) with remediation guidance for the latter.

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?

Six sentences covering purpose, mechanics, usage conditions, alternatives, constraints, and error handling. Every sentence carries distinct information. No redundancy with schema or annotations.

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

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

Comprehensive for a complex stateful operation. Covers preconditions (failed/stopped status), side effects (file preservation), error scenarios, and sibling tool relationships. Output schema is implied by documented return values in description.

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 clear field descriptions. Description adds usage context for model_profile (guiding users to plan_retry for profile changes) and plan_id (linking it to specific error conditions). Could explicitly confirm if model_profile changes are honored on resume, but provides strong implicit 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?

States specific action (resume) on specific resource (failed/stopped plan) with key behavioral distinction (without discarding intermediary files). Clearly differentiates from sibling plan_retry by contrasting 'full restart' vs resumption from incomplete 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?

Explicitly defines when to use ('plan_status shows failed or stopped', interruption scenarios like network drop/timeout) and when NOT to use ('For a full restart or to change model_profile, use plan_retry instead'). Names the specific sibling alternative.

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?

Adds critical behavioral details beyond annotations: state transition (reset to pending), side effect (prior artifacts cleared), and specific return codes. Annotations indicate non-idempotent write operation; description explains the mechanics (requeuing same ID after clearing) without contradicting 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?

Three dense sentences covering purpose, usage pattern, behavioral mechanics, and error cases. No redundancy—every clause conveys distinct information not repeated in structured fields.

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?

Comprehensive for a state-transition tool: covers preconditions, mutation effects (artifact clearing), post-state (pending), and error outcomes. Output schema exists per context signals, so detailed return documentation in description is bonus coverage.

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 complete parameter descriptions. Description paraphrases this ('Pass the plan_id and optionally model_profile') but adds no additional syntax constraints, validation rules, or semantic relationships beyond the schema 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?

Specific verb 'Retry' with clear resource 'plan' and qualifying condition 'in failed or stopped state' distinguishes it from siblings like plan_create (new plans) and plan_resume (likely doesn't clear artifacts).

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?

Implicit usage guidance via precondition 'failed or stopped state' and explicit error returns (PLAN_NOT_FAILED, PLAN_NOT_FOUND) signal when tool invocation will fail. Lacks explicit sibling comparison (e.g., vs plan_resume).

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?

Extensive behavioral disclosure beyond annotations: documents full response structure (progress_percentage, steps_completed, timing fields, error dict), stall detection logic (>10 minutes gap), file listing behavior (last 10 files), and error semantics (recoverable vs non-recoverable). No contradiction with readOnly/idempotent 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?

While every sentence contains valuable operational details (state machine, field semantics, troubleshooting), the description is extremely long and monolithic. Given the single parameter and straightforward input, the verbosity is justified by lack of output schema but pushes against conciseness ideals.

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?

Comprehensive compensation for missing output schema: documents all return fields (nullable status, timing timestamps, file arrays, error dictionaries), state transitions, polling protocol, and links to 4 sibling tools. Complete for an async polling endpoint.

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% (plan_id fully documented in schema). Description references plan_id only in error handling context ('Unknown plan_id returns error code'), adding minimal semantic value beyond schema since the schema already defines it as 'Plan UUID returned by plan_create'.

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?

Description opens with specific verb+resource ('Returns status and progress of the plan') and distinguishes itself from siblings by stating it's the 'primary way to check progress' while referencing plan_stop, plan_resume, and plan_retry for other states.

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?

Exceptional guidance including explicit polling intervals ('every 5 minutes'), timing expectations ('10-20 minutes'), complete state contract (pending/processing/completed/failed/stopped), and specific troubleshooting actions ('call plan_stop then plan_retry' when stalled).

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?

Excellent disclosure beyond annotations: explains asynchronous nature ('stop flag set immediately but plan may continue briefly'), state transition ('transition to the stopped state'), and return value logic ('stop_requested returns false'). No contradictions with destructive/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?

Perfectly structured with logical progression: command → parameter → async behavior → state outcome → error conditions. Every sentence provides unique value with zero 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?

Comprehensive for a destructive mutation tool. Accounts for output schema existence by still documenting key return value behaviors (false for completed plans, error code). Covers async complexity, error states, and state transitions.

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 description largely repeats schema information ('Pass the plan_id...'). Baseline score appropriate since schema fully documents the single required 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?

Specific verb 'stop' with clear resource 'plan generation' and scope. Explicitly links to sibling plan_create via 'UUID returned by plan_create', distinguishing it from other plan operations (resume, retry, status).

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 prerequisite (plan_id from plan_create) and explicit edge-case guidance ('If the plan is already completed or failed...'). Lacks explicit comparison against plan_resume/plan_retry siblings, but edge-case coverage is strong.

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 cover idempotency and safety (idempotentHint=true, destructiveHint=false), but the description adds crucial operational context: 'fire-and-forget, never blocks' explains the async nature not captured in annotations. It also discloses specific technical issues to report (queue delays, SSE closures), adding domain-specific behavioral context 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?

Seven sentences, each delivering distinct value: purpose, invocation timing/behavior, category semantics, plan attachment, rating scale, specific use cases, and reporting best practices. Front-loaded with core purpose. Slightly dense but no wasted words; structure follows logical progression from what → when → how → specifics.

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 annotations (safety hints), 100% schema coverage, and an output schema, the description achieves completeness by explaining PlanExe-specific taxonomy (categories mapping to system components) and concrete troubleshooting scenarios. It adequately covers the feedback domain without needing to describe return values (handled by 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?

While schema coverage is 100% (baseline 3), the description significantly enriches the 'category' parameter by defining domain-specific values: 'mcp (MCP tools, SSE, plan_status, workflow)' and 'plan (the generated output files)'. It also adds content guidance for 'message' ('Include specific details...when reporting issues') that exceeds the schema's generic description.

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

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

The description opens with a specific verb-resource pair ('Submit feedback about PlanExe') and enumerates specific content types ('issues, impressions, or suggestions'). It clearly distinguishes from sibling tools like plan_create or plan_status by focusing on meta-level reporting rather than plan management operations.

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 temporal guidance ('Callable at any point in the workflow') and behavioral mode ('fire-and-forget'). Lists specific scenarios for use ('SSE streams that close before plan completion,' 'plan_status returning stale data'), implicitly guiding users to invoke this when sibling tools malfunction. Lacks explicit 'do not use for X' exclusions, but the positive guidance is strong.

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