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

No annotations provided, so description carries full burden. Discloses soft archive behavior (keeps history) but does not mention permissions, reversibility, 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?

Two sentences, front-loaded with key action and context, no unnecessary words. Efficient and direct.

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 single-parameter tool with no output schema, description covers essential behavior. Minor gap: no mention of reversibility or constraints.

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 has 0% description coverage; description adds no info beyond parameter name and type. Single 'id' parameter is self-explanatory but still lacks clarification on format or source.

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 clearly states action (archive), target (completed or draft campaign), and effect (removes from list view but keeps history). Distinct from siblings like campaign_complete or campaign_launch.

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?

Describes when to use (completed or never-launched drafts) but lacks explicit when-not-to-use or alternatives. Implicit guidance, not exhaustive.

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, placing full responsibility on the description. It discloses that the state transition is terminal (only archive follows), but lacks details on reversibility, side effects, or permissions. For a state-changing tool, this is insufficient.

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

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

Two short sentences, front-loaded with the core action, no superfluous words. The structure is efficient and 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?

While the description clarifies the tool's purpose and lifecycle, it omits details about the reason parameter, output, error conditions, or integration with sibling tools. Given no output schema and low parameter coverage, the description is not fully complete for an agent to invoke correctly without additional 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 description coverage is 0%, yet the description adds no information about the two parameters (id and reason). It does not explain their purpose, constraints, or usage beyond what the schema provides, which is minimal.

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 ('Move a scheduled / running / paused campaign') and the target state ('to `completed`'), specifying applicable statuses, which distinguishes it from sibling tools like campaign_pause, campaign_resume, and campaign_archive.

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 includes 'Terminal — only `archive` follows', which indicates the lifecycle placement and implies when this tool is appropriate. However, it does not explicitly state when not to use it (e.g., if already completed) or compare to 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?

No annotations provided, so description carries full burden. It mentions the campaign starts as draft and defaults for success_metric window. But it omits side effects, idempotency, rate limits, and return behavior.

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?

Description is three sentences, front-loaded with purpose, and uses backticks for clarity. It's efficient but could be more organized.

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 14 parameters, nested objects, no output schema, and no annotations, the description is incomplete. Missing parameter details, return value, and error conditions limit its usefulness.

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

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

Schema coverage is 0%. Description explains three parameter groups (channels, audience, success_metric) out of 14. Many parameters like key, name, budget, creative are unmentioned, leaving gaps.

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

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

The description clearly states it creates a campaign in draft status, matching the title. It differentiates from launch tools by mentioning the draft-to-launch workflow, but doesn't explicitly distinguish from all sibling tools like campaign_update.

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 explains the workflow: create draft, then preview, then launch. This helps when to use. However, it doesn't specify when NOT to use (e.g., immediate launch) or prerequisites like environment existence.

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?

Discloses the scope of data returned (full audience, channels, creative, etc.) and, as a read-only fetch, no unexpected side effects. Lacks auth or error details but sufficient for a simple GET operation.

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

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

Single sentence, front-loaded with verb and resource, no redundant words. Efficient and to the point.

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

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

For a single-parameter tool with no output schema, the description fully covers what the tool returns, making it complete for agent 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?

Only one parameter 'id' with schema description 'Campaign UUID.' The description adds no extra semantics beyond the schema, which already has 100% coverage, so 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 specifies fetching a single campaign by id with a comprehensive list of fields (audience, channels, creative, etc.), clearly distinguishing from siblings like campaign_list (list) and campaign_preview.

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 implied (when full details of one campaign are needed) but no explicit guidance on when not to use or comparison with alternatives like campaign_preview or campaign_results.

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 provided, so description carries full burden. It discloses token single-use and snapshot-bound nature, and that changes require re-preview. This is sufficient behavioral context for a mutation tool.

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

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

Two focused sentences, no wasted words. Key information is front-loaded: the state transition and the prerequisite token.

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?

No output schema, but description explains the core behavior and prerequisites. Could mention return value or side effects, but not critical for a launch tool. Adequate for its 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 description coverage is 0%, so description must compensate. It adds meaning only for preview_token (its purpose and constraints), but does not explain launch_now or id parameters. The id is likely campaign ID, but launch_now's effect is unclear.

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 moves a campaign from draft/paused to scheduled/running, using a specific verb and resource. It distinguishes itself from siblings by requiring a preview_token from campaign_preview.

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 when to use (after preview) and what is required (fresh token). It also implies when not to use if changes have occurred since preview.

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 provided; description only mentions features. Does not state it is read-only, safe, or disclose rate limits, auth needs, or side effects. Minimal beyond basic purpose.

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?

Single sentence packed with essential info (pagination, filters). Front-loaded. Could be slightly expanded but no waste.

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 core functionality but lacks mention of include_archived and cursor format. No output schema, so return information is absent. Adequate for basic 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 coverage is 0%, but description adds meaning for status, search, limit, cursor. However, include_archived is not mentioned, and details like uuid format for cursor are omitted.

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?

Clearly states 'List campaigns in the current project' – specific verb and resource, with scope. Distinguishes from sibling mutation tools like campaign_create or campaign_get.

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?

Implied usage via listing features (pagination, filters), but no explicit when-to-use or alternatives. No exclusions or comparisons to 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?

No annotations are provided, so the description carries the full burden. It only states the action is reversible, but lacks details on side effects, state changes, or timing. For a mutation tool, more transparency about what happens when paused is needed.

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 very short with two sentences, front-loading the purpose. It is concise but could be slightly more structured. Every sentence adds value, though it may be too brief.

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 annotations, no output schema, and only two parameters, the description is minimal. It fails to specify what happens to campaign delivery, whether pause is immediate, or any prerequisites. It is incomplete for an agent to fully understand the tool's behavior.

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 two parameters (id required, reason optional) with 0% description coverage. The tool description does not explain any parameter meanings, defaults, or usage. It adds no value 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 pauses a scheduled or running campaign. It uses the verb 'Pause' with the resource 'campaign'. However, it does not explicitly distinguish from siblings like campaign_archive or campaign_complete, though it mentions reversibility via campaign_resume, which hints at 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 indicates use for scheduled or running campaigns and mentions reversibility via campaign_resume. It implies when to use but does not explicitly state when not to use or provide alternatives beyond the sibling. No exclusions are given.

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?

Discloses token is single-use, bound to current state, invalidated by edits, and requires all components valid. No annotations provided, but the description fully covers behavioral expectations.

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, front-loaded with purpose, no unnecessary words. Efficient and clear.

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 and no output schema, the description covers what the tool does, what it returns, constraints, and next steps. Complete 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 coverage is 100% and the description adds the requirement that all campaign components must be present and valid, but this is somewhat implied. 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?

Clearly states it is a dry-run that returns a launch plan and a preview token, distinguishing it from the actual launch tool and other 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?

Explicitly says to use before launching, gives a 5-minute token validity, warns that editing invalidates it, and implies campaign_launch as the next step.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns only the latest aggregate and not historical snapshots, which is key behavioral transparency. It does not mention side effects, permissions, or rate limits, but for a simple read tool this is acceptable.

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: first states the main action, second provides important context. No wasted words. Front-loaded with the 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?

For a simple tool with one parameter and no output schema, the description is complete: it explains what it fetches, the data limitation, and the alternative. It does not describe return format, but since no output schema exists, this is acceptable.

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

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

Only one parameter 'id' with schema description 'Campaign UUID.' The description adds no additional meaning beyond the schema. Since schema coverage is 100%, baseline is 3. No improvement 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?

Clearly states 'Fetch the latest results snapshot for a campaign.' The verb 'fetch' and resource 'latest results snapshot' are specific. It distinguishes from sibling tools like campaign_get by implying this returns performance data. However, it does not explicitly list the aggregate fields (impressions, clicks, conversions) in the description, relying on the title 'campaign_results' to imply that.

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 context: 'v1 only stores the latest aggregate... time-series snapshots land with the destinations framework.' This tells the agent when to use this tool (for latest aggregate) and when to use alternatives (destinations for time-series). No other sibling tools need this level of 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 provided, so description bears full burden. It discloses re-validation of launchability and conditions that cause rejection (empty audience, channels, creative, metric).

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 efficient sentences with no unnecessary words; front-loads core action and state transition.

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?

Coverage is adequate for a simple action with one parameter; behavioral detail is provided, though no return value description is given.

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?

Only one parameter 'id' which is self-explanatory (UUID). Schema coverage 0% but description adds no new meaning; baseline of 3 is appropriate given simplicity.

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?

Clearly states verb 'Resume' and resource 'campaign', specifies state transition 'paused → running', and distinguishes from siblings like campaign_pause.

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?

Implies usage when campaign is paused; context from sibling tools provides clarity, but no explicit when-not-to-use or alternatives are given.

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 trinary semantics for nullable fields (omit, null, set) and the side effect of invalidating preview tokens on certain edits. This goes beyond basic mutation behavior, though it does not cover error responses or idempotency.

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

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

Three sentences, each earning its place: first states purpose and constraint, second explains nullable field semantics, third details side effects. No fluff, highly 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 complex schema (13 params, nested objects) and lack of annotations or output schema, the description covers essential operational details (state constraints, trinary semantics, preview token invalidation). It could improve by briefly mentioning the response type, but the core completeness is solid.

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

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

Schema description coverage is 0%, so the description compensates with the trinary semantics rule, which is critical for correct use of nullable fields. It also explains the preview_token invalidation tied to specific parameter groups. However, it does not detail individual parameters beyond that, leaving some interpretation for nested objects.

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 patches a campaign with a specific verb ('Patch') and resource ('campaign'). It immediately adds crucial state constraints ('ALLOWED only in `draft` or `paused` state'), which distinguishes it from siblings like campaign_create, campaign_launch, and campaign_archive.

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 restricts when the tool can be used (only draft/paused states) and warns about preview_token invalidation when editing audience, channels, or creative. While it could mention alternatives like campaign_create for new campaigns or campaign_launch to change state, the context is clear given sibling names.

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?

Description mentions the return value (new id) and that the dashboard is initially empty, but does not disclose behavioral details such as whether layout parameter is supported (it exists in schema but is not mentioned), potential name conflicts, or permission requirements. No annotations are provided to compensate.

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, front-loaded with main action, and efficiently includes usage alternatives and next steps without extraneous text.

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 3 parameters (one nested), no output schema, and no annotations, the description covers the primary use case and return value but omits explanation of the layout parameter, which is a gap in completeness.

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 has 3 parameters with only 33% description coverage. The tool description adds meaning for 'name' and 'description' (optional), but fails to mention the 'layout' parameter, which is a nested object with no schema description. This omission leaves the agent uninformed about a significant 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?

Title and description clearly state the tool creates an empty dashboard with name and optional description, returning the new id. This distinguishes it from sibling tools like dashboard_template_get.

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?

Description explicitly explains when to use this tool (to create an empty dashboard) and provides alternatives: using dashboard_template_list and dashboard_template_get for pre-populated templates, and widget_create to add widgets afterward.

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 key behaviors: soft-delete, history retention, and template deletion restriction. With no annotations, the description carries the full burden, and it mostly succeeds but could mention reversibility or permissions.

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-loading the main action and adding important constraints. Every sentence adds value 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?

The description covers the tool's effect (soft-delete, history retention) and a constraint (templates). It lacks detail on return value or error behavior, but for a simple single-param tool it is mostly complete.

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

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

The single parameter 'id' is fully described in the schema as 'Dashboard UUID.' The description adds no additional meaning beyond what the schema provides, so 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?

Title and description clearly state the tool performs a soft-delete (archive) on a dashboard, specifying that history is retained and templates cannot be deleted. This distinguishes it from siblings like dashboard_update or dashboard_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?

The description implies when to use the tool (to remove from list but keep history) and includes a constraint (templates cannot be deleted). However, it lacks explicit guidance on when not to use it or comparisons to alternative archive/delete tools among 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?

Describes return format (full widget list with query, viz, position) which adds value beyond a simple fetch, but no annotations are provided and no mention of side effects or authentication.

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, front-loaded with action and key details, no redundant words.

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

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

For a simple get-by-id tool with one parameter and no output schema, the description covers the return value adequately, though it could mention error cases.

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 has 100% description coverage for the only parameter 'id', so the description adds no additional semantic meaning beyond confirming it's by id.

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?

Clear verb 'Fetch' and resource 'single dashboard by id, including the full widget list'. Distinguishes from siblings like dashboard_list which fetches multiple dashboards.

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 use case: 'to understand what's on a dashboard before editing it', implying context but not explicitly excluding alternatives like dashboard_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?

With no annotations, the description carries full burden. It accurately describes the read-only nature and scope, but could mention authentication or rate limits if applicable.

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: first states purpose and outputs, second gives sibling pointer. No wasted words, 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 adequately describes return values, scope, and exclusion. Complete for a simple list 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?

No parameters exist, so the baseline is 4. The description adds no parameter info, 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 clearly states it lists dashboards in the current project, excludes archived ones, and specifies the returned fields (id, name, description, created_at). It also distinguishes from dashboard_get for full widget details.

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 clear alternative (dashboard_get) for when more detail is needed. However, it does not explicitly state when not to use this tool or other exclusion criteria.

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 that the tool is read-only (returns a blueprint), provides the structure of the return value, and specifies the error condition (404 for unknown id). It could add a note on idempotency or permissions, but the current disclosure is solid.

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: first states the return value with details, second provides usage guidance and error behavior. It is front-loaded with the main purpose and contains no unnecessary 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?

Given no output schema, the description details the return structure (id, name, description, icon, widgets array with query+viz+position). It also covers error handling. The sibling tools context shows integration with dashboard_create and widget_create, and the description ties the workflow together. No missing critical information for a simple get-by-id 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% (template_id with description including an example). The description does not add further meaning beyond the schema, 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 specifies the verb 'Returns' and the resource 'full blueprint for a template', listing concrete fields (id, name, description, icon, widgets array). It distinguishes from siblings by noting to use this to fetch the recipe before calling dashboard_create and widget_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?

The description explicitly states when to use the tool ('Use this to fetch the recipe, then call dashboard_create + a widget_create per item to materialize it') and mentions the 404 error for unknown template ids. It does not explicitly state when not to use it, but the workflow context 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?

Declared as 'Read-only enumeration', making the non-destructive nature clear. Also lists returned fields (id, name, tagline, description, icon, widget_count) so the agent knows exactly what to expect.

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

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

Two concise sentences, front-loaded with the core purpose and no unnecessary words. Every sentence provides actionable 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?

Despite no output schema, the description sufficiently enumerates return fields. Contextual guidance on next steps (dashboard_template_get) completes the picture 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?

No parameters in the input schema (schema coverage 100%), so no parameter info to add. Baseline score of 3 is appropriate; description does not detract but also cannot add value for parameters.

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 the purpose: 'Read-only enumeration of every starter dashboard the platform ships with.' It clearly distinguishes this listing tool from sibling tools like dashboard_template_get and dashboard_create by mentioning usage flow.

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: 'Use dashboard_template_get(id) to retrieve the full widget specs, then materialize via dashboard_create + widget_create calls.' This tells the agent how to chain this tool with others for a complete 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, description takes full burden. Discloses trinary semantics for nullable fields and template restriction. Does not mention authentication, rate limits, or response/error behavior, but core mutation behavior is clear.

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, front-loaded with purpose, no unnecessary words. Every sentence adds essential information: what fields, how nullable fields work, and a usage restriction.

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 update fields, nullable handling, and template exclusion. Missing response description, but no output schema exists. Could benefit from mentioning that layout is a freeform object, but overall sufficient 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 coverage is 0%, but description adds meaning for three of four parameters: name, description, layout are explicitly listed as updatable. Explains trinary semantics for nullable description. Id is not elaborated but typically understood as identifier.

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 'Update' and the resource 'an existing dashboard', listing specific fields (name, description, layout) that can be modified. It distinguishes this tool from sibling tools like dashboard_create, dashboard_delete, and dashboard_get by focusing on modification.

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 condition for when NOT to use: templates (is_template = true) are read-only and cannot be edited via this tool. Also explains trinary semantics for nullable fields, guiding parameter usage (omit, null, value).

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 operation is read-only ('Read-only enumeration') and details the return fields (id, version, category, title, description). Since no annotations are provided, the description fully covers behavioral traits.

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: the first states the core function, the second adds usage guidance and return info. It is front-loaded, concise, and 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?

Given the tool has no parameters and no output schema, the description fully covers its purpose, usage context, and expected return values, making it complete for a simple enumeration 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 has zero parameters, and schema description coverage is 100%. The description does not need to add parameter semantics, and baseline for 0 parameters is 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 'Read-only enumeration of every destination adapter', specifying the verb (list) and resource (destination adapters). It distinguishes itself from related tools like destination_create by noting its use for discovering valid connector_id values.

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

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

The description explicitly recommends using this tool to discover valid connector_id values for destination_create, providing clear guidance on when to use it. However, it does not explicitly mention when not to use it or list 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 fully discloses behavioral traits: validation behavior (server validates config against its schema, returns 400 on shape errors), return value (destination id), and post-creation use (binding to Campaign). It stops short of mentioning error cases or idempotency.

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

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

The description is well-structured with a front-loaded purpose, followed by parameter constraints, validation behavior, examples, and return value usage. At about 5 sentences, it is concise but could be slightly tighter.

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 and 5 parameters with nested objects, the description covers the main creation behavior, config validation, and result usage. However, it omits details on environment_id and filters, and lacks error handling beyond config validation, leaving the tool partially underspecified.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for connector_id (must be from catalog) and config (per-adapter structures), but does not describe name, environment_id, or filters parameters, leaving gaps.

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

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

The description clearly states 'Install a destination adapter into the current project' with a specific verb and resource. It provides examples of connector_ids from the catalog, distinguishing the tool's purpose from sibling tools like destination_get or destination_delete, though not explicitly differentiating.

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 mentions that connector_id must come from destination_catalog and gives per-adapter config examples, providing context for use. However, it lacks explicit guidance on when not to use this tool or alternatives, leaving some 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?

With no annotations provided, the description carries the full burden. It correctly identifies the operation as a soft-delete and explains the retention of history. However, it does not disclose whether the operation is reversible or requires specific permissions, which are relevant for a deletion 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 a single, well-structured sentence that efficiently conveys the key information: soft-delete, effect on eligibility, and history retention. No unnecessary 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?

Given the simplicity of the tool (one parameter, no output schema), the description is largely complete. It explains the core behavior. However, it could be improved by mentioning the return value or any prerequisites, but this is not critical for a soft-delete operation.

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 single parameter 'id', so the description adds no additional value beyond what the schema already provides. 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 verb 'soft-delete' and the resource 'destination', and explains the effect (stops campaign dispatch, retains history). It distinguishes from a hard delete and from other destination tools like destination_update.

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 for when to use this tool: to stop a destination from being eligible for dispatch while preserving history. It does not explicitly mention when not to use it or alternatives, but the purpose is well-defined.

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 what is returned (config, filters, delivery state) but does not mention side effects, authorization requirements, or error behavior. The description is adequate for a read operation but lacks deeper 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?

The description is a single, front-loaded sentence that immediately conveys the action and result. Every word serves a purpose, with no redundancy or unnecessary detail.

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, no nested objects), the description is largely complete. It covers the action, required input, and return content. It could be enhanced by mentioning error handling or ID format, but overall it is sufficient for the agent to understand usage.

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 single 'id' parameter has a description: 'Destination UUID.'). The description adds 'by id' but does not provide additional meaning beyond the schema. Baseline score of 3 applies as the description does not enrich 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 clearly states the tool fetches a single destination config by ID, specifying the returned contents: full saved config, filters, and last delivery state. This distinguishes it from sibling tools like destination_list (for listing multiple) and destination_create (for creating).

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 implies usage when you have a specific destination ID and need its configuration, but it does not explicitly state when to use this tool over alternatives like destination_list or destination_test. No prerequisites or when-not-to-use guidance is provided.

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 must disclose behavior. It mentions listing and filtering but does not describe pagination (cursor, limit), archiving behavior (include_archived default), or whether the operation is read-only. This lack of detail reduces 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 two sentences long, front-loaded with the main purpose, and efficient. It wastes no words, though it could be slightly expanded to cover missing parameters without becoming verbose.

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 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain pagination, archiving, or response format, which are critical for an agent to use the tool correctly across all scenarios.

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 5 parameters with 0% description coverage, so the description must compensate. It only explains connector_id and status. Parameters include_archived, cursor, and limit are not mentioned, leaving their semantics unclear.

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 destination configs installed in the current project, specifies filtering by connector_id and status, and includes examples. This distinguishes it from sibling tools like destination_get, destination_create, etc., which have different actions.

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 explains when to use filtering by connector_id or status, providing clear context for usage. However, it does not explicitly state when not to use this tool or mention alternative tools for related tasks (e.g., destination_catalog for listing available connectors).

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 bears full burden. It discloses the tool's behavior for webhooks (GETs URL) and Resend (lists domains), and explicitly states it does not send a real payload. However, it does not mention whether the operation is read-only or has 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: first sentence states the main action, second and third provide specific details for different adapter types and an explicit exclusion. 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?

Given the tool's low complexity (one parameter, no output schema), the description is fairly complete. It explains the tool's purpose, behavior for specific cases, and what it does not do. It does not mention return values or error conditions, but these are not required when no output schema exists.

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 required parameter 'id' (uuid format) with 0% description coverage. The description does not explain what 'id' refers to (presumably destination ID), so it adds no semantic meaning beyond the schema. Baseline for low coverage is low.

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 it runs a connection check against the saved config, specifies behavior for different adapter types (webhooks, Resend), and explicitly distinguishes from other tools by stating it does not send a real campaign payload.

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 this tool (to test a destination's config) and what it does for specific adapters. It includes an explicit exclusion (not sending real payload), but does not mention alternatives or prerequisites.

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 effectively discloses key behaviors: status transitions are limited to active and paused (failed cannot be set manually), and nullable fields follow a trinary semantics (omit=preserve, send new value=overwrite). This clarifies the update's partial nature and constraints.

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—three sentences that front-load the purpose (first sentence) and then add critical behavioral details. Every sentence provides essential information, with no redundancy 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?

Despite no output schema or annotations, the description covers the main behavioral aspects (partial updates, status rules, nullable semantics) for a moderately complex tool with nested objects. It does not address prerequisites or error handling, but the core usage is well-specified.

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 description lists the updatable fields (name, config, filters, status) and adds contextual semantics for nullable fields and status transitions. However, it does not describe each parameter's purpose or data type beyond what the schema already provides; the schema itself covers most details. The trinary semantics add moderate value.

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

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

The description clearly states the tool updates an existing destination by specifying the fields that can be changed (name, config, filters, status). It is distinct from sibling tools like create, delete, get, and list, making the purpose unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives like destination_create or destination_test. However, it provides important usage details such as allowed status transitions (active↔paused) and trinary semantics for nullable fields, which guide correct invocation.

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 takes on full burden. It discloses that system events are auto-emitted (should not be tracked), and that customer events appear under customer_events. Does not mention any side effects or permissions, but for a read-only catalog tool this is sufficient.

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 moderately detailed but each sentence serves a purpose: defining the return, giving usage guidance, and explaining parameters. It could be slightly more concise, but it's 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 no output schema, the description adequately explains what the tool returns (canonical + custom events) and categorizes them. It does not specify the exact structure of the returned events, but for a catalog tool this is likely sufficient 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%, so the baseline is 3. The description adds meaning by explaining the category enum values (e.g., system events are auto-emitted) and clarifying the default for include_customer_events. This extra context helps the agent make informed choices.

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 merged canonical and custom events, with a specific verb 'Returns' and resource 'events'. It distinguishes from sibling tools by focusing on event discovery rather than campaign or destination management.

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 instructs to call this BEFORE writing any new track() callsites. Provides guidance on using canonical names instead of custom ones, and mentions filtering to avoid context bloat. This is a clear when-to-use directive.

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 weight. It discloses the return value (feedback id and createdAt) and explains that the MCP auto-stamps source/version metadata. It doesn't mention any side effects or permissions, but for a simple feedback tool, this is adequate.

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 of about 5 sentences. It is well-structured, front-loading purpose, then usage, then return details. While slightly verbose, every sentence adds value, and it 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?

Given no annotations and no output schema, the description covers all essential aspects: purpose, when (and how) to use, return value, and metadata handling. It fully equips 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?

Schema coverage is 100%, and the description adds meaning beyond the schema. For 'type', it provides explicit mappings for each enum value (e.g., 'bug = something is broken'). For 'message', it advises quoting user words, adding usage nuance.

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: 'File a bug report, feature request, or general note for the Sheepit team.' It specifies a clear action (submit) on a resource (feedback) and differentiates from sibling tools, none of which are feedback-related.

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 detailed guidance on when to invoke: proactively when user expresses frustration, after a confusing error, or when hitting a gap. It explicitly instructs to always confirm with the user and quote their words, establishing a clear usage protocol.

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 fully handles transparency. It discloses idempotency (409 on re-add), error on archived group (409), email resolution, and return value (membership row id). This goes beyond basic functionality.

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

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

The description is extremely concise, with four sentences covering action, parameter usage, return value, and idempotency. No excess verbiage; every sentence is informative.

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 3 parameters and no output schema, the description covers the return value, error cases, and parameter usage. It is nearly complete, though mentioning what happens with an invalid group UUID (e.g., 404) would be helpful.

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 only 33% (only id described). The description compensates by explaining the mutual exclusivity of user_id and email and that email is resolved to user_id. This adds significant 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 action ('Add a user to a user group') and specifies the two identification methods (UUID or email). It distinguishes from siblings like group_remove_member by the verb 'add'.

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 guidance: 'Provide exactly ONE of user_id/email'. It also notes idempotency and error cases, but does not compare with alternative tools or state when not to use.

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 explains that keys are snake_case and unique per project, and outlines the creation process. However, it does not disclose potential behavioral traits like mutation, idempotency, or failure scenarios.

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 with no wasted words. It front-loads the purpose and efficiently covers creation steps, key format, and example use cases.

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 (3 parameters, no output schema, no nested objects) and the context of sibling tools, the description provides adequate completeness by linking to follow-up actions and giving examples. It could add more detail on parameter behavior but 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 0%, so the description must compensate. It adds meaning for 'key' (snake_case, unique per project) but does not elaborate on 'name' or 'description' beyond the schema constraints, missing an opportunity to clarify their purpose.

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 'Create a new user group in the current project.' It specifies the action (create) and resource (user group). It also distinguishes from sibling tools like group_add_member by describing the creation step separately.

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 when to use the tool: to create a group, then add members with group_add_member, then reference in flag rules. It gives example use cases. However, it does not explicitly state when not to use it or 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?

Discloses cursor pagination and free-text search across key and name. With no annotations, this adequately describes the read-only nature, though it could add more about return structure.

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 front-loaded purpose and no fluff. Every sentence adds 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?

Covers pagination, search, and usage context. Lacks details on return object structure and the include_archived parameter, but sufficient for typical list operations.

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?

Explains the 'search' parameter as free-text across key and name and implies cursor/limit via pagination, but omits the 'include_archived' parameter. With 0% schema coverage, more explicit parameter descriptions would be beneficial.

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?

Clearly states 'List user groups in the current project' with a specific verb and resource. Distinguished from sibling tools like group_create and group_add_member.

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 advises using this tool before group_create to check for existing groups, providing clear guidance on when to use it relative to 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 discloses key behavioral traits: returns 404 if user wasn't a member and idempotency. This helps the agent handle outcomes correctly.

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 core action, and every sentence adds valuable information 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 simple removal tool with two parameters and no output schema, the description sufficiently covers the main behavior (return 404, idempotency). However, it omits potential prerequisites like permissions.

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 schema already documents both parameters. The description adds no new semantic details beyond what the schema 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 uses a specific verb ('Remove') and resource ('user from a group'), clearly distinguishing it from the sibling tool 'group_add_member'.

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 implies usage by stating the parameters and return behavior (404 for non-member), but does not explicitly state when to use versus alternatives or prerequisites.

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 behavioral disclosure. It explains the input envelope, permitted values, defaults (e.g., aggregation default 'count'), and return behavior (gap-filling with zeros). It does not mention permissions or error handling, but given the read-only nature, the transparency is high.

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

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

The description is well-structured, starting with purpose and usage, then detailing the input envelope. It is slightly long but every sentence adds value and there is no 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 absence of an output schema and annotations, the description is quite complete. It explains the input format thoroughly, return behavior, and even references sibling tool 'event_catalog_canonical' for event names. Minor gaps are the lack of explicit mention of read-only nature and permissions, but overall it 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 0%, but the description compensates by explaining each parameter field, allowed enum values, defaults, constraints (e.g., max 20 breakdown values), and the structure of 'range' (relative vs absolute). It adds significant 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 executes a one-shot InsightsQuery without saving it, with explicit example questions. It distinguishes from widget creation and provides a clear verb-resource pair.

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 concrete usage examples (e.g., 'how many signups yesterday?') and implies it's for one-off queries. However, it does not explicitly state when not to use it or list alternative tools for saved queries.

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 discloses that the health is pre-computed, returns deltas, and includes critical warnings about null handling and authoritative fields. This provides sufficient behavioral context beyond the schema.

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 sentence but packs all key information: what is returned, the authoritative fields, and null handling. It is front-loaded with the main purpose. Could be slightly improved with bullet points, but overall concise.

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

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

Given no output schema, the description covers the main return values (health verdict, four signals, code context, delta) and includes important caveats about conversion_rate. It is sufficiently complete for an agent to understand 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 already has 100% description coverage for all three parameters, including types, defaults, and ranges. The description adds no additional parameter semantics beyond what's in the schema, 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 states it returns the full pre-computed health verdict, all four signals, code context, and delta for ONE release. This clearly differentiates it from sibling tools like release_list or release_regressions, which have different purposes.

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 guidance on how to use the outputs: health_status and health_score are authoritative, and not to derive verdicts from individual rates. It also warns that conversion_rate may be null. However, it does not explicitly compare to alternatives like release_regressions for when 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?

With no annotations, the description carries full burden. It reveals that the verdict is server-side computed and advises not to recompute from rates. It also mentions pagination behavior. However, it does not disclose auth requirements, rate limits, or explicitly state read-only nature, but the context implies read-only.

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 (5 sentences) with a front-loaded core purpose. Every sentence adds value: purpose, behavioral note, filtering, pagination, alternatives. 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 6 params, no output schema, and no annotations, the description covers most aspects: purpose, when to use, params (most), pagination, and alternatives. It lacks explicit description of the output format (e.g., pagination object shape) but mentions pagination cursor, which implies structure. Minor gap.

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

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

Schema description coverage is 50% (3 of 6 params documented). The description adds some meaning: it lists filter options (platform, channel, status) and explains that status='active' means deployed to production, and mentions cursor usage. However, it does not explicitly address environment_id or provide format details for enum params beyond what schema offers. Partial compensation.

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

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

The description clearly states the tool lists releases with current health verdicts and rates, using specific verbs and resource. It distinguishes from sibling tools by naming release_health and release_regressions as alternatives for different needs.

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 guidance on when to use (e.g., to get current health verdicts) and when to use alternatives (release_health for breakdown, release_regressions for regressions). Also explains pagination and filter options.

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, description fully handles transparency: states regression detection is server-side, crash_free_delta is not recomputed, and how to interpret 0 values (non-computable). Provides guidance on confirming via pre/post rates. No contradictions.

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

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

Two well-structured paragraphs: first sentence gives purpose, second provides behavioral details. Every sentence adds value. Slightly verbose in second paragraph but overall effective.

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 3 parameters and no output schema, description covers key behavioral concepts (kinds, delta interpretation) adequately. Could mention output structure but not required. Complete for a list 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% with clear descriptions for each param (since, environment_id, limit). Description adds minimal extra context (e.g., 'optionally since a timestamp'). 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?

Clearly states 'List releases that REGRESSED' with specific filtering and ordering (newest-first). Distinguishes from siblings like release_list (general list) and release_health (in-depth investigation) by purpose and detail.

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?

Explains when to use (to list regressed releases, optionally with timestamp), describes meaning of kind='release' vs 'change', and recommends release_health for deeper investigation. Lacks explicit when-not-to-use but 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?

No annotations exist, so description carries full burden. It discloses that the tool returns a curated overview and respects language preferences. Could mention that it is a read-only help tool, but the tone implies no 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?

Two sentences efficiently cover purpose and usage guidelines. Some detail could be trimmed (e.g., repeating 'the user is writing in') but overall no waste.

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?

No output schema, but description hints at content ('curated overview', 'deep-dive'). It doesn't specify format (e.g., list of tools), which would help agents, but for a help tool it 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% with enum descriptions. The description adds value by explaining when to omit vs specify 'topic' and how to match 'language' to the user's conversation language, going beyond 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?

The description clearly states the tool returns a curated overview or deep-dive on a specific area, with explicit verb ('Returns') and resource ('overview of what this MCP server can do'). It distinguishes from siblings by focusing on generic 'what can I do?' queries.

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

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

The description explicitly says when to call without a topic (user asks about general capabilities) and with a topic (specific area). It also provides language matching instructions for Spanish, leaving no 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?

With no annotations provided, the description discloses that the tool returns a recipe but does not mention any behavioral traits such as idempotency, rate limits, or side effects. It implies a read-only operation but doesn't confirm 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?

Two sentences clearly stating the return value and usage context. Front-loaded with the core purpose, no fluff, 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?

Without an output schema, the description does not explain the format of the returned recipe (e.g., plain text, JSON, list of tool calls). Also, it omits 4 recipe options from the schema description, leaving gaps 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 claimed 100%, but the parameter description for 'recipe' only lists 5 out of 9 enum values, potentially misleading the agent about available options. The language parameter description adds value by noting Spanish use.

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 it returns a step-by-step recipe with exact tool calls for a specific goal. It distinguishes from sibling tools which are individual actions, making it clear that this is a meta-tool for orchestration.

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

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

Explicitly says 'Use when the user has a clear intent' and provides examples like 'send a marketing email' and language option. Does not specify when not to use, 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?

Despite no annotations, the description discloses key behavioral traits such as V1 limitations, query type, viz options, and position defaults. It lacks detail on authorization or side effects, but provides sufficient context for safe invocation.

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

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

The description is three sentences, front-loaded with the main action, and each sentence adds essential information 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?

Given the complexity (7 parameters, nested objects) and no output schema, the description covers primary constraints and defaults. It omits return value expectations but is adequate for agent 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?

With only 14% schema coverage, the description adds meaning for type, query (discriminated union), viz (chart options), and position (defaults). It does not elaborate on name, description, or dashboard_id, but the schema covers their 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 clearly states 'Create a new widget on the given dashboard' with a specific verb and resource. It distinguishes this tool from sibling tools like widget_delete and widget_update by focusing on 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 provides explicit guidance with 'Templates can't have widgets added via this tool,' indicating when not to use it. However, no alternative tools are mentioned for template widget addition.

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 that the operation is a 'hard-delete' (permanent) and confirms that the dashboard remains intact, but it does not mention any side effects (e.g., cascade deletions), authorization requirements, or rate limits. The disclosure is adequate for a simple delete but incomplete for a high-risk mutation.

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 sentence that immediately conveys the purpose and scope. It is front-loaded and contains no unnecessary words. Every part earns its place.

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

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

The tool is simple, but the description lacks details about the return value (e.g., success confirmation or empty response) and error conditions (e.g., if the widget doesn't exist). It does not state prerequisites (e.g., the widget must exist). Given no output schema, the description could be more complete, but it covers the essential behavior.

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?

Both parameters (dashboard_id, widget_id) are fully described in the input schema with UUID format. The description does not add any additional meaning beyond the schema, such as why both are required or any constraints. With 100% schema coverage, the baseline is 3 and the description adds no extra value.

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

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

The title and description clearly state that the tool removes a widget from a dashboard. The description specifies 'hard-delete' and clarifies that only the single widget is removed while the dashboard remains, distinguishing it from dashboard-level or bulk 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?

The description implies usage when a specific widget needs to be permanently removed from a dashboard, but it does not provide explicit guidance on when not to use it (e.g., for soft-delete or batch deletion) or mention alternative tools. While siblings include widget_create and widget_update, there is no other delete tool for widgets, so the context is clear but lacks explicit 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?

With no annotations, the description must disclose behavioral traits. It does not mention permissions, idempotency, side effects (e.g., partial update behavior), or what happens to omitted fields. 'Trinary semantics' hints at nullable handling but lacks detail. Significant gaps for a mutation tool.

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

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

Two sentences, 38 words, front-loaded with purpose. Every sentence adds value. No redundancy. Could be considered slightly under-specified but not verbose.

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 7 parameters (including nested objects) and no output schema, the description omits return values, error handling, prerequisites (e.g., dashboard_id must reference an existing dashboard), and permissions. Incomplete given 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 description coverage is 0%. The description lists parameter groups (name, description, position, query, viz) but adds no details or constraints beyond the schema. For complex nested parameters like query and viz, no contextual meaning is provided. Minimal added value.

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

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

The description clearly states 'Update name / description / position / query / viz of a single widget' with specific verb and resource. It distinguishes from bulk updates by referencing the dashboard layout endpoint, which also differentiates from a sibling 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?

Explicitly advises to use the dashboard layout endpoint for bulk position changes, indicating when not to use this tool. 'Trinary semantics for nullable fields' gives guidance on field handling but could be clearer. Overall, good context for usage.

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