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

Annotations already indicate destructive. Description adds critical context: files deleted from disk, irreversible, scope locked to mcp-dashboards temp folder, returns per-file success/failure including locked files. Exceeds annotation burden.

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

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

Four well-structured sentences with critical warning first. No wasted words; 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?

For a deletion tool with three parameters and no output schema, description fully covers usage, scope, parameter semantics, and return behavior. No gaps.

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

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

Schema covers 100% of parameters. Description adds meaning: explains that chartIds are specific IDs, olderThanDays is bulk by age, all is complete deletion; adds regex constraint for chartIds and requirement to provide at least one. Also describes return format.

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 the tool deletes chart preview HTML files from disk. Differentiates from siblings (all render/poll/save tools) by being the only deletion 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 requires user explicit instruction, warns that deletion is irreversible, and explains how to choose between parameters (chartIds, olderThanDays, all). Does not explicitly contrast with alternatives, but no sibling does deletion, so it's 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?

Adds context beyond annotations: files are auto-generated and auto-cleaned after 7 days, configurable via env var. Returns specific metadata fields. No contradiction with annotations.

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

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

Two focused sentences with no waste. First sentence defines tool, second provides usage and behavior context.

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

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

Tool is simple with no parameters. Description covers source, lifecycle, return data, and appropriate usage. No gaps.

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

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

No parameters exist; schema coverage is 100%. Description does not need to add parameter info. Baseline for 0 params 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?

Description clearly states it lists chart preview HTML files on disk, specifies resource and action. Distinguishes from sibling tools like delete_chart_files.

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 for auditing disk usage, then references delete_chart_files as follow-up action. Provides clear guidance on 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by explaining how presets work via environment variables and emphasizing security. It does not cover all behavioral traits like response format or rate limiting, but the safety profile is well-covered by annotations.

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

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

The description is concise with four sentences, front-loading the core purpose. Every sentence provides essential information: purpose, usage context, parameter distinction, and a critical security warning. 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 tool's complexity (5 optional parameters with security implications) and no output schema, the description covers the key points: when to use each parameter, authentication method, and a security warning. It omits details about response handling or error cases, but the openWorldHint annotation implies variability; overall sufficient for agent selection.

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

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

Schema coverage is 100%, so baseline is 3. The description adds semantic value by reinforcing the security distinction between 'preset' and 'url', and by stating that no presets are configured. This extra context helps the agent understand parameter usage beyond the schema's own descriptions.

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

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

The description clearly states the tool fetches JSON from an HTTP endpoint, specifies its usage by render_live_chart for polling, and distinguishes it from siblings which are all rendering or file-saving tools. The verb 'Fetch' and resource 'JSON from HTTP endpoint' are specific and unambiguous.

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

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

The description gives explicit guidance on when to use 'preset' (authenticated APIs) versus 'url' (public APIs), with a strong warning against passing API keys in headers. It also notes that no presets are configured, setting clear expectations. This directly helps the agent choose the correct parameter and avoid misuse.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that the chart is interactive and supports click-to-drill-down, but says nothing about the output artifact, where the rendered chart goes, or whether calling it persists anything. Some added context, but limited.

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 tight sentences, feature enumeration front-loaded after the core verb+resource phrase. No filler, no repetition of the title, every clause carries a capability.

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 an 8-parameter, deeply nested tool with no output schema and 88% schema coverage, the description covers the rendering capability set adequately. However, it omits what the call produces (inline content, file artifact, URL) and whether any output-identifying parameter exists, which an agent needs given siblings like save_file and list_chart_files. Adequate but with a real gap.

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

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

Schema description coverage is 88%, so the schema already documents theme, effects, palette, typography, options.colors, stacked, horizontal, drilldown and dataset fields in detail. The description confirms the existence of drilldown (options.drilldown) and the orientation/stacking options but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Render an interactive bar chart') and enumerates the variants it covers (vertical/horizontal, stacked, multi-series, drill-down, themes). This clearly separates it from pie/line/scatter siblings by chart type, though it never explicitly names an alternative. Clear but not sibling-routing.

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 feature list (stacked, multi-series, drill-down, themes) implicitly tells the agent which bar-chart scenarios this tool fits, but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling like render_line_chart or render_pie_chart. Usage must be inferred from the chart type.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that stats are computed automatically, which is helpful. No contradiction, but no further behavioral details (e.g., return format) are provided.

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

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

The description is three sentences, each adding value: purpose, input format, and an option example. No fluff, front-loaded, and 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?

The description covers core functionality and data input but omits output format (e.g., what is returned) and advanced options (theme, effects, etc.). Given moderate complexity and no output schema, more details would improve 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 coverage is 88% so the schema describes most parameters. The description adds meaning by explaining that data should be raw number arrays and that stats are computed automatically, which complements 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 'Render a boxplot or violin chart' with the specific purpose of showing distribution (median, quartiles, whiskers, outliers). It distinguishes from sibling chart tools by name and functionality.

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 tells when to use it ('What is the distribution?') and how to pass data (raw number arrays). However, it does not explicitly exclude alternatives or compare to other distribution-oriented charts, missing some guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the input shape and the absence of side effects implied by 'render', but says nothing about what is produced or returned (image, HTML, file path), which matters for a no-output-schema render 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?

Three short sentences, front-loaded with the core verb and encoding, then the data contract, then use cases. The middle sentence largely duplicates the schema's array item definition, so it is slightly redundant rather than wasteful.

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 10-parameter tool with no output schema, the description covers the essential required input but omits any mention of the many styling parameters (theme, palette, effects, projection, sizeRange) and what the caller receives back. The schema carries parameter detail, but return behavior is left to inference.

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 all ten parameters including defaults are already documented in the schema. The description restates the required point fields ({label, latitude, longitude, value}) but adds no syntax, units, or constraint detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Render a bubble/pin map - sized circles at geographic coordinates') and even defines the visual encoding, which is more than a tautology. It doesn't explicitly distinguish itself from siblings like render_geo_chart or render_scatter_chart, so an agent must infer the difference.

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 closing sentence gives positive use cases ('city-level data, office locations, event density'), which implies when this tool fits. It gives no exclusions or named alternatives (e.g., when to prefer render_geo_chart or a plain scatter), so routing is only partially guided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the chart's visual elements (zones, target marker) and constraints (2-8 zones). No contradiction with annotations.

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

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

Two efficient sentences covering purpose, features, and use cases. No filler, front-loaded with key information.

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

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

For a chart-rendering tool with no output schema and 8 parameters, the description covers core purpose and zone details. Could mention theme/palette support briefly, but schema handles specifics. Adequately complete.

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

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

Schema coverage is 100% with descriptions for all parameters. The description does not add new parameter-specific details beyond the schema, so baseline score applies.

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

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

Description clearly states the verb ('render'), resource ('bullet chart'), and its purpose ('Are we hitting target?'). It distinguishes from sibling charts like render_bar_chart by defining the specific chart type and use case (KPI vs target, maturity models).

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 examples of when to use (KPI vs target, seniority bands) but does not explicitly state when not to use or name alternatives. Still, the context helps the agent decide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the major behavioral traits (non-destructive, idempotent, safe). The description adds no further behavioral context (e.g., authentication, rate limits, output format), but also does not contradict the annotations. The baseline score is appropriate given the annotations carry the transparency burden.

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

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

The description is two sentences, front-loaded with the primary action and type, followed by supported data and themes. No unnecessary words; concise and efficient. 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?

Given the rich input schema (86% coverage) and clear annotations, the description adequately covers the tool's purpose and data requirements. However, it omits the return type (e.g., rendered chart as HTML/image), which could aid the agent in understanding the output. Still, the description is largely complete for a chart rendering 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?

With 86% schema description coverage, the input schema already provides detailed descriptions for most parameters, including the data array, theme presets, and options. The description only adds general context ('Provide date/OHLC data... Supports themes') without enriching specific parameter meanings. It meets the baseline for high-coverage schemas.

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 specifies the tool renders an interactive candlestick or OHLC financial chart, distinguishing it from other chart types. It explicitly mentions the data format (date/OHLC) and use cases (stock prices, crypto, forex), which is specific and differentiating from sibling tools like render_line_chart or render_bar_chart.

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 the tool is for financial time-series data (stock, crypto, forex) but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or comparisons are provided, leaving the agent to infer appropriate usage from the name and description alone.

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

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

Annotations declare readOnly, idempotent, non-destructive. Description adds context about previews and routing, which aligns with annotations. 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 concise sentences that front-load the purpose and describe the interaction without unnecessary detail. Every sentence contributes.

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 catalog tool with one optional parameter and no output schema, the description covers purpose, interaction, and routing behavior. No gaps.

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

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

Schema coverage is 100% with a comprehensive list of theme values. Description does not add additional meaning about how the theme parameter affects the catalog output, so it does not add 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?

Description clearly states it is the 'master entry point' to discover capabilities, with live visual previews and routing to sub-catalog tools. This distinguishes it from sibling render tools that focus on specific chart types.

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 implies usage by suggesting to click a tile and hit Ask, and mentions sub-catalog tools as alternatives. However, it does not explicitly state when not to use it or contrast with direct render tools.

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

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

Annotations already indicate safety (readOnlyHint, idempotentHint, destructiveHint false). The description adds that clicking cards leads to more info, but no additional behavioral traits beyond what annotations provide. It does not contradict annotations.

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

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

Two sentences with no wasted words. The first sentence states purpose, the second provides a useful alternative reference.

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

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

For a simple tool with one optional parameter, no output schema, and full annotation coverage, the description adequately covers purpose and provides a pointer to a related tool. No gaps for the use case.

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 one parameter 'theme' fully described in the schema. The description adds no additional meaning for this parameter, so baseline score of 3 applies.

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

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

The description clearly states the tool's action ('Show a visual catalog') and resource ('every available chart type as a dashboard of mini previews'). It also distinguishes itself from the sibling tool render_catalog by noting that this tool is for previews while render_catalog covers customization.

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 to use render_catalog for customization, implying this tool is for a visual overview. However, it does not give context on when to prefer this over other chart renderers like render_bar_chart.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds that output is a responsive grid and that palette/typography/effects can be mixed independently, but says nothing about the rendered output medium (HTML, image, file) or where the result goes.

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?

Front-loads the purpose in one sentence, then the theme catalog and the mix-and-match rule. The theme list is long but each entry carries a distinct use-case hint, so it earns its space; nothing is padded.

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 an 11-parameter tool with nested hero objects and no output schema, the description covers purpose and theming adequately but omits the required inputs (title, charts), the return value, and how it relates to the single-chart and save_file siblings. Usable, but an agent must open the schema to build a valid call.

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 3 baseline is met by the schema itself. The description then adds genuine value by mapping each theme name to a use case (investors, healthcare/WCAG AAA, crypto/gaming) and explaining the mix-and-match relationship between theme, palette, typography, and effects.

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

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

States a specific verb and resource: 'Render a full dashboard with KPI cards, charts, and optional hero metric in a responsive grid.' That composition distinguishes it from the single-chart siblings like render_bar_chart, though it never names an alternative explicitly.

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?

There is no statement of when to use this composite dashboard tool versus the many single-chart renderers, nor any prerequisites or exclusions. The theme use-case hints ('boardroom (investors, board decks)') guide parameter choice, not tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it supports scale labels and background zones, which is useful behavioral context. However, it doesn't detail rendering output (e.g., returns an image) or other behaviors.

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, then features. No extraneous 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?

Covers core chart type and two advanced features (scale labels, zones) but omits mention of cosmetic parameters (theme, effects) and does not describe output. For a tool with 13 parameters and no output schema, slightly more context would be beneficial.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds no parameter-specific information beyond the chart's purpose. Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states it renders a dumbbell chart and explains the visual metaphor ('Before/after dots connected by a bar'). It distinguishes from siblings by specifying this chart type, but does not explicitly differentiate from similar charts like render_slope_chart.

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

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

The description provides an implicit usage hint ('How big is the gap?') suggesting before/after comparisons, but lacks explicit guidance on when to use this tool versus alternatives, and does not mention when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by explaining that each card previews the effect and lists underlying treatments, which is beyond what annotations provide. No contradictions.

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

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

The description is three concise sentences with no redundancy. It front-loads the core purpose, lists the presets, explains card behavior, and points to an alternative. 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?

Given no parameters and no output schema, the description fully covers what the tool does: shows a visual catalog of 5 effect presets with previews and treatment lists. No gaps remain.

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

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

The tool has no parameters, and schema coverage is 100%. Per guidelines, baseline is 4 for zero parameters. The description doesn't need to add parameter info.

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 displays a visual catalog of exactly 5 effect presets, naming each one (none, subtle, shimmer, neon, energetic). It distinguishes itself from siblings by noting that 'render_catalog' is the master entry point for all customization dimensions.

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 when to use this tool (for effects presets) and when to use an alternative ('For a master entry point covering all customization dimensions, see render_catalog').

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details such as interactivity (draggable, zoomable, pannable), auto-layout via Dagre, status states with live polling or manual playback, and constraints on x/y usage. No contradiction with annotations.

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

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

The description is comprehensive but somewhat lengthy; however, every sentence serves a purpose, and key information is front-loaded. It strikes a good balance between completeness and clarity.

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 lacking an output schema, the description thoroughly covers the tool's functionality, including interactive features, status updates, polling, and layout constraints. It equips the agent with all necessary context to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so every parameter already has a description. The description adds value by explaining usage constraints (e.g., x/y only from previous renders, statusPath dot-path, pollTool usage) and providing context 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 renders interactive flowcharts/diagrams and lists specific use cases (workflow, data pipeline, system architecture, etc.). It distinguishes itself from sibling tools like render_dashboard by noting it's a full-canvas tool.

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

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

The description explicitly says 'USE THIS whenever the user wants to visualize a flow or structure' and provides numerous examples. It also warns when not to use it (for multi-chart layouts, use render_dashboard) and advises against hand-authoring coordinates unless round-tripped.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds the core auto-detection behavior, which is valuable beyond annotations. It does not contradict annotations.

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

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

Two sentences, front-loaded, every word earns its place. No unnecessary information.

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

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

For a low-complexity tool with strong annotations and moderate schema, the description provides enough context (auto-detection, input flexibility). The lack of output schema is partially mitigated by the description's mention of 'visualization'.

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

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

Schema coverage is 67% with descriptions for title and options.preferredType. The tool description adds context for the 'data' parameter ('arrays, objects, nested structures'), which is not fully detailed in the schema (type missing). This provides moderate 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 the tool's action: automatically detects the best chart type for arbitrary JSON data. It distinguishes itself from sibling tools that produce specific chart types (e.g., render_bar_chart) by emphasizing auto-detection.

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 arbitrary JSON and want automatic chart selection, but it does not explicitly declare when to use this tool versus the many specific chart renderers (e.g., render_bar_chart). No guidance on when not to use or prerequisites 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?

Annotations already indicate read-only and non-destructive behavior. The description adds that it fetches data from a URL, auto-detects chart type, and renders interactively, which goes beyond annotations. No mention of error handling or edge cases, but overall transparent.

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

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

Two sentences, front-loading the core purpose, with no unnecessary words. 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?

Given the tool's complexity (URL fetch, auto-detection, interactive rendering) and no output schema, the description covers key behaviors but lacks details on error handling, authentication, or return format. Still sufficient to differentiate from siblings.

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

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

Schema coverage is 67% with descriptions for title and url. The description does not add new parameter meanings beyond what the schema provides; the auto-detection mention relates to options.preferredType but adds no syntax. Baseline 3 is appropriate.

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

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

The description clearly states the tool fetches JSON from a URL, auto-detects the chart type, and renders it interactively. This distinguishes it from siblings like render_from_json (inline JSON) and chart-specific tools (which require explicit type selection).

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 use when you have a URL with JSON data and want automatic chart rendering. It does not provide explicit when-not or alternative tool references, but the context is clear given the sibling 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?

Annotations already declare readOnly and idempotent behavior. The description adds visual details (width-proportional bars, conversion percentages) that go beyond annotations without contradiction.

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

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

The description is a concise single sentence that provides core purpose and visual details. It is front-loaded and efficient, though could benefit from additional context 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 7 parameters, 100% schema coverage, and no output schema, the description covers the basic purpose and visual behavior. However, it lacks information on return value, ordering of stages, default options, or error handling, leaving some gaps for a complex chart tool.

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

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

Schema coverage is 100%, so parameter semantics are already well-defined. The description adds value by mentioning the showConversion parameter's effect but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool renders a funnel chart for conversion stages, with width-proportional bars and optional conversion percentages. It distinguishes from siblings like render_bar_chart or render_pie_chart by specifying the funnel chart purpose.

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

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

The description implies usage for conversion analysis ('Where do we lose people?') but does not explicitly state when to use this versus other chart tools, nor provide when-not or alternative guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint as true, and destructiveHint as false. The description adds the fact that it renders a map but does not elaborate on behavior like performance or edge cases. With annotations covering safety, the description adds minimal extra 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 two sentences, front-loading the purpose and data format. Every word earns its place, with no fluff or repetition.

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

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

With 10 parameters (2 required) and no output schema, the description captures the core functionality concisely. It could mention that the output is an image or chart, but the purpose is clear enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that country codes must be ISO 3166-1 alpha-2 and providing an example data format, which goes beyond the schema's property descriptions.

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

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

The description clearly states the tool renders a choropleth world map, using the verb 'Render' and specifying the resource as a geographic map color-coded by numeric values. It distinguishes from sibling tools like render_bar_chart by focusing on geographic concentration.

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 use for geographic data visualization with the question 'Where is the value concentrated?' and specifies the data format with ISO codes. However, it does not explicitly state when not to use or provide alternatives among the many sibling render tools.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, so the description need not repeat those. It adds that color scales are supported, but does not disclose other behavioral traits like input validation, performance, or error handling.

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, concise sentence with a question and key details. It is front-loaded and efficient, though it could benefit from slightly more structure to separate use case from features.

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 9 parameters (4 required) and no output schema, the description fails to explain how values map to colors, usage of theme and effects, or expected output format. It is minimal and leaves many behavioral aspects undocumented.

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

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

Schema coverage is 100%, so the schema already describes each parameter. The description mentions supported color scales, which overlaps with the schema's colorScale description. It adds marginal value 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 clearly states it renders a heatmap, a color-coded grid, and adds a use-case question 'When are patterns strongest?'. It distinguishes from sibling tools by specifying the heatmap type, but does not explicitly differentiate from other heatmap-like tools if any exist.

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 no guidance on when to use this tool versus alternatives. The question 'When are patterns strongest?' implies a use case but does not explicitly state scenarios or when not to use it. No alternatives mentioned.

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

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

The description adds context beyond annotations by stating 'working preview with sample data' and 'click any card to learn'. Annotations already indicate read-only and idempotent, and the description aligns without contradiction.

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

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

Two sentences, front-loaded with the main action, zero wasted words. Efficiently conveys purpose and interactive nature.

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 display tool with one optional parameter and no output schema, the description fully covers what the tool does, including the interactive preview behavior. Annotations support 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 coverage is 100% for the single parameter 'theme', and its description in the schema is already comprehensive. The tool description does not add further parameter semantics, so baseline score applies.

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

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

The description clearly states the verb 'Show', the resource 'hero metric variants', and the scope 'all 11 variants in a single dashboard'. It lists the variants explicitly, distinguishing from sibling tools like render_hero_metric.

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 display all hero metric variants). It does not explicitly exclude scenarios or mention 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial behavioral context: contextual appropriateness rules per variant, theme pairings (orb 'best with dark themes', gem 'best with golden-treasury, tokyo-midnight'), and a documented default (big_number). This is well beyond annotation coverage.

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?

Long, but every line is a variant-to-question-to-params lookup that earns its place, and it is front-loaded with the selection rule. Slightly dense with inline 'Params:' lists, though this structure is functional rather than wasteful.

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 an 11-variant, 37-parameter tool with no output schema, the description covers variant choice and per-variant parameters thoroughly. It leaves shared/global params (theme, palette, typography, size, effects) unexplained, but those are covered by the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond it: it groups which params belong to which variant and explains the abstract gemType enum meanings (crystal='Future', ruby='What's critical', diamond='Crown number'). It does not cover shared params like theme, palette, typography, size or effects, so it is additive rather than complete.

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

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

States a specific verb+resource ('Render a purpose-driven hero metric widget') and then enumerates all 11 variants with the question each answers. An agent can immediately tell this apart from sibling chart renderers like render_pie_chart or render_hero_catalog.

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 frames selection as 'Pick the variant that answers your question' and maps each variant to a decision question (How much? How close to goal? Good or bad?). Goes further with negative guidance: orb should avoid formal contexts, gem is 'for wealth, fintech, trading, crypto, luxury contexts ONLY' with an explicit fallback ('use big_number instead').

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds useful capability context (interactive output, smooth curves, gradient fill, multi-series, theming), but says nothing about output format, persistence, or interaction model.

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

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

Three short sentences, front-loaded with the core action, no filler. It is efficient, though the third sentence about themes partially duplicates the second's capability listing.

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 88% schema coverage and full annotation coverage, the description need not explain parameters or safety. For a nested, 8-parameter render tool with no output schema, the remaining needs – recognizing a chart render – are met; the noted gaps (return value, sibling routing) are minor given how much the schema already carries.

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 88%, so the schema already documents nearly all 8 parameters in detail. The description's mentions of smooth curves, gradient fill, multiple series, and themes loosely map to options.smooth, options.fill, datasets, and theme, but adds no syntax, defaults, or constraints beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Render an interactive line or area chart') and lists distinguishing capabilities. However it does not explicitly differentiate itself from siblings like render_bar_chart or render_scatter_chart, and the 'line or area' phrasing leaves the chart type slightly ambiguous.

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?

No guidance on when to choose this over ~25 sibling render_* tools, and no prerequisites or exclusions. The reader must infer usage from the tool name alone.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by explaining that the chart auto-refreshes and polls a tool at a regular interval, which is behavioral context beyond the annotations.

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

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

The description is three sentences long, front-loads the main action, and uses clear, direct language with no wasted words or redundancy.

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

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

Given the tool's high complexity (14 parameters, nested objects) and many sibling tools, the description adequately explains the core functionality and usage. It could elaborate slightly on why to choose this over static line charts, but it is sufficient for correct invocation.

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

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

Schema descriptions cover 100% of parameters, so baseline is 3. The description adds meaning by giving an example of using 'pollTool' with 'poll_http' and explaining how to poll external APIs, which provides context beyond the schema's generic descriptions.

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

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

The description clearly states it renders a real-time auto-updating line chart that polls a tool. It uses a specific verb ('Render') and resource ('live chart'), and distinguishes itself from sibling tools like 'render_line_chart' by emphasizing the real-time, auto-updating polling behavior.

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 'Use when the user wants to MONITOR a live data source' and provides guidance on setting up polling via 'pollTool' and 'pollArgs'. It does not explicitly mention when not to use it, but the context is clear and helpful.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that the tool renders a chart (non-destructive) and supports optional target markers, but goes beyond what annotations provide. It does not elaborate on other behavioral aspects like resource usage 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 highly efficient sentences: first defines purpose and visual, second adds features and usage context. No filler, each sentence earns its place.

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

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

Given 6 parameters, 100% schema coverage, and annotations, the description covers purpose, key features, and usage context. It lacks details on parameters like theme or effects, but those are self-explanatory from the schema. The description is sufficiently complete for a straightforward chart 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%, achieving baseline 3. The description adds value by explaining that the tool 'supports optional target markers for benchmarking,' which directly informs the target parameter. However, it does not elaborate on the other parameters (theme, effects, etc.), but they are adequately described in the schema.

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

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

Description clearly states the tool renders a lollipop chart for comparing segments, with horizontal lines and dots. Also mentions optional target markers and positions it as a cleaner alternative to bar charts, effectively distinguishing it from sibling chart tools like render_bar_chart.

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

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

The description specifies the tool is for 'How do segments compare?' and labels it a 'Clean alternative to bar charts for ranked data,' giving clear context for when to use it over bar charts. However, it doesn't explicitly state when not to use it or mention other alternatives like dumbbell charts.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, conveying safety. The description adds that it renders interactive charts and supports themes, but does not contradict annotations. However, it does not add deep behavioral context beyond what annotations imply.

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

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

Two sentences with no redundancy. First sentence states purpose and required input; second mentions themes. Front-loaded and 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?

The description covers essential aspects (data format, theme) but omits details on customization options (effects, donut mode, colors, legend, palette, typography). Given 7 parameters and no output schema, more context could help an agent select or configure 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 description coverage is 86%, so the schema already explains most parameters. The description mentions the core data format and theme support but does not delve into other parameters like effects, options, palette, etc. With high schema coverage, the description adds marginal 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 renders an interactive pie or donut chart from key-value data, specifying the input format as an array of {label, value} pairs. It distinguishes from siblings (many other render_* charts) by explicitly naming the chart type.

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 the tool is for pie/donut charts but provides no explicit guidance on when to use it vs alternatives like render_bar_chart or render_line_chart. No when-to-use, when-not-to-use, or alternative suggestions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral context beyond this, e.g., about rendering process, file output, or limitations.

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

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

The description is two sentences with no fluff, front-loading the core purpose and then adding clarifying context. Every sentence contributes 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?

The tool has 8 parameters, nested objects, and no output schema. The description covers purpose and use cases but lacks details on output format, side effects, or constraints beyond the annotations. Adequate but not comprehensive.

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 high (88%), and the description adds a summary phrase but does not explain parameters beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states it renders a radar (spider/web) chart, gives a question phrase to illustrate its use, and provides specific examples (skill profiles, product comparisons). This distinguishes it from many sibling chart-rendering tools.

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

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

The description implies usage through the question and examples, but does not explicitly state when not to use this tool or mention alternative chart types available in the sibling tools.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds no additional behavioral context (e.g., return format, side effects, or dependencies). With annotations covering safety, the description contributes little extra 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, highly concise and front-loaded with the tool's purpose. No redundant or irrelevant information.

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

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

The description is minimal but adequate for a simple rendering tool with fully documented parameters and annotations. It lacks output schema information, but that is accounted for. It does not cover limitations or prerequisites, which would be useful for a chart 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%, so the input schema already documents all parameters. The description mentions 'status colors', which relates to the metrics' status field, but does not add meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool renders a radial cluster chart for multi-metric health checks, with multiple ring gauges showing percentage metrics and status colors. It distinctively describes the chart type, differentiating it from sibling chart renderers.

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

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

The phrase 'Multi-metric health check?' implies usage for comparing multiple metrics, but no explicit guidance on when to use this tool versus alternatives like render_bar_chart or render_pie_chart. No exclusions or when-not-to guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds no behavioral details beyond the chart's visual mapping, which is consistent but not supplementary.

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, no redundancy. The first sentence clearly states the action and concept; the second lists use cases. Every word is purposeful and front-loaded.

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

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

For a rendering tool with 7 parameters (2 required) and no output schema, the description adequately explains the chart type and typical applications. It could mention that the output is a rendered image, but the purpose is clear enough.

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

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

Schema description coverage is 86%, meaning most parameters are well-documented in the schema. The description adds minimal parameter-level value (only implicitly explains 'flow' width). 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 explicitly states 'Render a sankey flow diagram' and explains the concept with 'Where does it go? Shows flows between nodes with width proportional to value.' It lists specific use cases (budget flows, user journeys, etc.), clearly differentiating from other chart siblings.

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

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

The description provides clear use case examples ('Great for budget flows, user journeys, energy transfers, conversion funnels'), giving the agent context on when to use this tool. However, it lacks explicit when-not-to-use guidance or direct comparisons to alternative chart types 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the output is an interactive scatter plot and supports multiple series, connecting lines, and themes, but does not disclose return format, file-saving behavior, or other operational details beyond what the schema and annotations provide.

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

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

The description is three sentences, front-loaded with the core purpose, and avoid unnecessary verbosity. The third sentence about themes is somewhat redundant with the schema but still concise overall.

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 7 parameters, nested objects, 40+ sibling render tools, and no output schema, the description covers the core purpose and capabilities but omits usage differentiation and return behavior. The rich schema and safety annotations carry much of the burden, leaving this as minimum viable.

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 high at 86%, so the schema already documents parameters thoroughly. The description mentions x/y data, multiple series, optional connecting lines, and themes, but these map directly to schema fields (datasets, showLine, theme) without adding syntax, format, or default information 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 states a specific verb and resource ('Render an interactive scatter plot') with x/y coordinate data, multiple series, and optional connecting lines. It is clearly distinct from most siblings by naming scatter plot, but it does not explicitly differentiate from adjacent chart types like render_line_chart or render_bubble_map.

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?

There is no guidance on when to choose this tool over alternatives such as render_line_chart or render_bubble_map, nor any exclusions or prerequisites. The description only restates capability without context for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, non-destructive operation. The description adds that it produces SVG lines, confirming the output format and visual nature, which is useful but not extensive.

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 efficiently conveys the tool's purpose and output. The clarifying question adds value without unnecessary verbosity.

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 8 parameters (4 required) and no output schema, the description sufficiently conveys the tool's conceptual purpose and output format (SVG lines). It does not detail optional parameters like theme or effects, but the schema covers those. The description is adequate for this complexity level.

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%, meaning every parameter already has a description in the schema. The tool description does not provide additional details about parameter usage, so it meets but does not exceed the baseline for parameter documentation.

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

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

The description clearly states the tool renders a slope chart, specifically for showing 'How did rankings change?' using SVG lines between two time periods. This specific verb-resource combination and the clarifying question distinguish it from siblings like render_bar_chart or render_line_chart.

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 implicitly guides usage for comparing relative position changes across two time periods. While it does not explicitly state when not to use this tool or provide alternatives, the context is clear enough for an AI agent to select it for ranking-change scenarios.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context such as what the render returns, whether it is persisted, or how it behaves with large data arrays, so it only meets the reduced bar.

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, zero filler, and the scoping/steering message is front-loaded right after the one-line purpose. Nothing could be removed without losing information.

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

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

For a 6-parameter render tool with fully documented schema and no output schema, the description gives enough to make the routing decision correctly. It is slightly thin on what a standalone card grid render actually returns, but that gap is minor given the consistent render_* family pattern.

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 title, data, theme, palette, effects and typography in detail. The description contributes no additional meaning about any parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names a specific resource ('sparkline card grid') and marks its scope as 'standalone', which is what separates it from the broader dashboard renderers. It stops short of an explicit verb, but an agent can tell exactly what artifact this produces versus siblings like render_line_chart or render_dashboard.

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

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

It explicitly routes the agent away from this tool: prefer KPI cards with sparkline[] inside render_dashboard for an integrated look. That names both the alternative tool and the condition under which it wins, which is exactly the when/when-not guidance an agent needs.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds that the output is interactive and themeable, but says nothing about what is produced or returned (an image, HTML, a saved file) or how it interacts with siblings like save_file.

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

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

Three short, front-loaded sentences with no filler. The middle sentence ('Click column headers to sort') describes end-user UI interaction and is of limited value to an invoking agent, but it is 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?

With 8 parameters including nested objects, no output schema, and many sibling tools, the description should clarify what the tool produces and how it relates to file-saving or catalog tools. It leaves the return value and the reason to pick a table over a chart or dashboard unexplained.

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 high (88%), so the schema documents title, columns, rows, theme, effects, options, palette and typography on its own. The description only adds that themes are supported for 'styled visuals', which is a minor gloss over what the schema already states.

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

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

The description states a specific verb and resource ('Render a sortable, interactive data table'), which cleanly separates it from the chart-rendering siblings (pie, bar, line, etc.). It does not explicitly name an alternative, but the table-vs-chart distinction is self-evident.

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?

There is no guidance on when to choose this tool over the many sibling renderers (render_from_json, render_dashboard, or any chart tool), nor on prerequisites. The only clue is the resource type itself.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it shows 21 theme cards with previews of colors, typography, and effects, and allows clicking to use a theme. This is sufficient beyond the annotations.

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

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

Three sentences with no wasted words. The first sentence states the purpose, the second adds detail about content, and the third provides a useful alternative reference. Front-loaded and 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 0 parameters, no output schema, and annotations that cover safety, the description is complete. It describes the visual output, user interaction, and points to a broader tool. Minor omission: how the theme is applied after clicking is implied but not 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?

There are 0 parameters and schema coverage is 100%. The description does not need to explain parameters. Baseline for 0-parameter tools 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 the verb 'show' and the resource 'visual catalog of all 21 available themes'. It distinguishes from sibling tools by mentioning an alternative master entry point (render_catalog), avoiding confusion with other catalog tools.

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

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

Provides explicit guidance to use render_catalog for a master entry, implying this tool is for theme-specific selection. However, it does not explicitly state when not to use it or provide 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?

Annotations already declare readOnly, idempotent, non-destructive. Description adds visual behavior (progress dots, status colors) and orientation advice, complementing annotations without contradiction.

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

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

Three sentences covering purpose, usage, and orientation advice. No wasted words, front-loaded with key 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?

Adequate for a render tool with good annotations and high schema coverage. Covers purpose, usage context, and orientation guidance. Could mention output format but not needed given typical render 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?

Schema coverage is 100%, so baseline is 3. Description adds value with orientation recommendation and explanation of status colors, 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?

Clearly states it renders a timeline chart with progress dots and status colors. Distinguishes from sibling chart renderers by naming the specific chart type and its use case.

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 guidance on when to use (project milestones) and orientation recommendation based on number of items (horizontal ≤8, vertical longer). Lacks explicit when-not-to-use or alternatives, but 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description does not contradict this and adds context about the chart type but no additional behavioral traits beyond what annotations provide.

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

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

The description is very concise, using two short sentences that front-load the core purpose and immediately convey value. Every phrase is purposeful and avoids redundancy.

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

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

Given the tool's complexity and absence of output schema, the description covers key aspects: chart type, hierarchical grouping, and example use cases. It could mention parameter requirements briefly, but high schema coverage mitigates the 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 high (86%), so the schema handles most parameter meaning. The description reinforces the data parameter's role with 'value' and 'group' but adds minimal new semantic detail 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 renders a treemap, defines its purpose as visualizing 'what takes up the most space' with nested rectangles sized by value, and distinguishes it from sibling chart tools by mentioning optional hierarchical grouping.

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 use cases like budget breakdowns, disk usage, and portfolio allocation, offering context for when to use this tool. It does not explicitly exclude other chart types or mention alternatives, but the examples help guide selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it renders a chart with color-coded indicators, but does not disclose side effects (e.g., does it save to disk?). With annotations covering safety, a score of 3 is appropriate.

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 with 21 words, front-loading the purpose. Every word earns its place with no wasted content.

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

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

Given no output schema, the description explains the chart's visual output. However, it does not specify where the chart is rendered (e.g., displayed, saved as a file), which could be important for an agent. Still, it is mostly complete for a simple chart 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%, so the schema already documents all parameters. The description provides context about the chart's purpose (variance) but does not add meaningful semantics beyond what is in the schema.

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

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

The description clearly states the tool renders a variance chart comparing actual vs budget with color-coding. However, it does not explicitly differentiate from sibling chart tools like render_bar_chart.

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?

No guidance on when to use this tool versus alternatives. The description implies it's for variance/over-under budget scenarios but does not state when not to use it or provide comparisons.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, ensuring the agent knows it's a safe read operation. The description adds the key behavioral constraint that values should sum to 100, which is not in annotations. 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 sentences, each earning its place: the first defines the tool and its visual form, the second adds the key constraint. No unnecessary words, well front-loaded.

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

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

Given the complexity (6 params, no output schema) and the presence of annotations, the description covers the essential aspects: what the chart is, the data format, and a key constraint. It does not explain the return value, but for a render tool this is often implied.

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 all parameters. The description repeats the sum-to-100 constraint and adds the 10x10 grid context, but this does not significantly augment the parameter semantics beyond the schema.

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

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

The description clearly states the verb 'Render' and the resource 'waffle chart', specifies the 10x10 grid and proportional composition, and distinguishes from sibling chart tools like pie or bar charts by focusing on composition with a grid layout.

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

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

The phrase 'What is the composition?' implies it's used for showing parts of a whole, but there is no explicit guidance on when to use it versus alternatives like render_pie_chart or render_bar_chart, nor any when-not conditions.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds value by explaining the auto-inference logic for bar types, which is beyond what annotations provide. No contradiction.

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

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

Two concise sentences that front-load the purpose. No unnecessary words; 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?

Given the tool's complexity (7 parameters, no output schema), the description adequately covers the core behavior and auto-inference. It could mention what the output looks like, but the schema handles most parameter details.

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

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

Schema description coverage is 100%, and the description does not add new information beyond the schema. The auto-inference rule is already present in the schema. Baseline 3 is appropriate.

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

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

The description clearly states it renders a waterfall chart, explains the concept ('What drove the change?'), and mentions auto-inference of bar types. The name and title are specific and distinct from sibling chart tools.

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

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

The description mentions auto-inference of bar types but does not provide explicit guidance on when to use this tool vs. other chart renderers or when not to use it. Usage is implied but not compared 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's additional context about word sizing adds some value but does not contradict annotations. Behavioral traits beyond safety are not detailed.

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 and fairly concise, but the first sentence is a quoted phrase that adds little structure. It could be more efficiently worded without losing information.

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

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

Given high schema coverage and no output schema, the description covers the core functionality and use cases. However, it does not mention output format or behavior for edge cases, leaving some gaps for a rendering 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 86%, so baseline is 3. The description references the 'value' parameter (frequency/importance) but does not explain other parameters like theme, effects, or palette. It adds marginal 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 it renders a word cloud and explains the purpose: identifying dominant themes with words sized by frequency or importance. It distinguishes itself from 36 sibling render_* tools by specifying the chart type and use cases.

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

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

It provides explicit use case examples (survey responses, keyword analysis, topic frequency) but does not mention when not to use it or alternatives among sibling tools. Some guidance is given, but exclusions are absent.

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

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

Annotations indicate idempotent and non-destructive. Description adds that it writes to the Downloads folder and accepts only .png or .csv filenames, and that it's app-only. This provides good behavioral context beyond annotations, though it doesn't explicitly mention overwrite 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?

Two concise sentences with no filler. All information is necessary 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?

Tool has three required parameters, no output schema. Description covers purpose, target location, file type restrictions, and who invokes it. This is fully sufficient for correct 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 description coverage is 100%, so the schema already documents each parameter. The description adds context about file extension restrictions and app-only invocation but does not significantly enhance parameter understanding beyond schema.

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

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

Clearly states it saves a chart export (PNG or CSV) to user's Downloads folder. Distinguishes itself from sibling render tools by specifying it is a file-saving operation, not a rendering operation.

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 'App-only - invoked by the chart View's Download buttons, not by the AI.' This tells the AI not to call this tool directly and that it is triggered by user interaction in the app, providing clear when-to-use guidance.

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