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

No annotations are provided, so the description carries the full behavioral burden. It discloses the mutation ('add ... to the datasource') and references a formula skill, but says nothing about validation behavior (validate_formula param), idempotency, required permissions, or duplicate handling. Significant gaps for a mutation tool with 9 parameters.

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 core action and followed by a reference pointer. No waste, though the pointer is arguably the only additional value and the description is quite thin 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?

An output schema exists, so return values needn't be explained. But for a 9-parameter mutation with zero schema coverage and no annotations, the description is far too thin — most parameter semantics and behavioral traits remain undisclosed.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. Its only parameter-adjacent content is the formula resource pointer, leaving role, datatype, field_type, table_calc, default_format, internal_name, and validate_formula entirely undocumented. It does not add meaning beyond the bare 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?

States a specific verb+resource: 'Add a calculated field to the datasource.' An agent can distinguish it from sibling mutators like remove_calculated_field and validate_formula. However, it does not explicitly differentiate from repair_calculated_field_issues or audit_calculated_fields, so it stops short of a 5.

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?

Points the agent to a skill resource for formula syntax, which is a useful usage cue, but gives no when-to-use/when-not guidance relative to siblings such as validate_formula or remove_calculated_field. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it is nearly silent. 'Union' and 'existing native sets' weakly imply that the input sets must already exist and that a new set is produced, but there is no mention of permissions, whether inputs are mutated, or error behavior when dimensions differ.

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

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

A single front-loaded sentence with no filler, and the verb and constraint lead. It is efficient, though the brevity borders on under-specification for a two-parameter mutation tool.

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

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

An output schema exists so return values need not be explained, but with no annotations, 0% parameter coverage, and a non-trivial set-combination operation, the description leaves too much unspecified for an agent to invoke it confidently.

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

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

Schema description coverage is 0% and neither of the two parameters is documented in the schema. The description only faintly implies that 'set_names' refers to existing sets being unioned and that a resulting set is named, but it never clarifies the relationship between set_name and set_names, so it does not compensate for the coverage gap.

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 gives a specific verb ('Union') and resource ('existing native sets') and adds a scoping constraint ('at the same dimension grain') that separates it from a plain single-set creation. However, it never references the nearby sibling 'add_set' by name, so the agent must infer the distinction between adding one set versus combining several.

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 explicit when-to-use statement and no named alternative. The only implicit guidance is the 'same dimension grain' constraint, which tells the agent a precondition exists but not how to satisfy it or when to prefer 'add_set' or 'add_group' 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?

With no annotations, the description carries the full burden, and it does disclose real behavior: the default layout value, what each layout mode produces, the fallback semantics of 'auto', and the exact inline schema for a native set control. It stops short of stating permissions, error handling, or effects on any pre-existing dashboard, which leaves a residual gap for a mutation tool.

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

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

Front-loads the one-line purpose, then organizes workflow and layout options under clear headers with no filler sentences. It is longer than most definitions but each block (workflow steps, layout modes, skill pointer) 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?

An output schema exists, so return values need not be explained, and the description covers creation flow, layout representation, and prerequisites. The only meaningful omission is guidance on width/height and how worksheet_names interacts with the layout, but for the core call the agent has everything it needs.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly documents the layout parameter (file path, dict tree, preset strings, set_control format) and implies worksheet_names and dashboard_name through the workflow, but width and height are never mentioned anywhere, leaving two of five parameters undocumented.

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: 'Create a dashboard combining multiple worksheets.' It is unambiguously distinguished from siblings like generate_layout_json (which produces the layout artifact) and add_dashboard_action/add_dashboard_extension (which augment an existing 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?

Provides an explicit numbered workflow naming the prerequisite tools (list_worksheets, generate_layout_json) and when to hand off a layout file vs pass an inline dict. It also gives a clear when-to-use rule per layout value ('auto' only for simple vertical fallbacks; use dict/file for mixed layouts).

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It adds no information about permissions, persistence, side effects, or how the added action affects the dashboard. The only extra detail is a serialization format for clear_value, which is parameter semantics rather than behavioral disclosure.

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 short paragraphs with no wasted words, and the first sentence front-loads the action types the tool supports. It is appropriately concise for a structured schema, though the second paragraph’s serialization note is tightly scoped to one case.

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 a 17-parameter mutation tool with no annotations and 0% schema description coverage, the description is severely incomplete. It lists action types and one parameter format, but leaves most parameter semantics, usage context, and behavioral expectations unaddressed. The existence of an output schema excuses return-value explanation, but not the missing input and behavioral context.

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

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

Schema description coverage is 0% across 17 parameters, and the description only explains three parameters (source_field, target_parameter, clear_value) and only for the action_type='parameter' case. The remaining 14 parameters, including required dashboard_name and action_type, receive no additional semantic guidance beyond their titles.

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 ('Add') and resource ('dashboard action'), and enumerates the action types it supports (filter, highlight, URL, navigation, parameter). It is clear what the tool does, but it does not distinguish itself from siblings like initialize_dashboard_filter_action or add_dashboard_set_action, leaving an agent to infer when this broad action tool is preferred.

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 a conditional parameter requirement for action_type='parameter' but provides no overall guidance on when to use this tool versus alternatives such as the filter- or set-specific action tools. There is no context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It implies a mutation but says nothing about side effects, permissions, whether it requires an existing dashboard, or how the extension is positioned/rendered. Only the existence of 'manifest and settings' is disclosed.

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

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

A single efficient sentence with no waste and a front-loaded verb. It is concise but under-specified rather than densely informative, so it sits at minimum-viable.

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 output schema covers return values, but for a mutation tool with nested objects, no annotations, and 0% parameter coverage, the description is far too thin. It omits prerequisites, the manifest schema expectations, and positioning semantics.

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

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

Schema coverage is 0% with 7 parameters, so the description must compensate. It loosely names 'manifest' and 'settings' but says nothing about dashboard_name, x, y, width, height, or the expected shape/structure of the manifest object, leaving most parameters undocumented.

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 ('Add') and resource ('native dashboard extension'), so the core action is clear. However, it does not distinguish itself from the many dashboard siblings like add_dashboard, add_dashboard_action, or add_dashboard_toggle_button, leaving the agent to infer when 'extension' is the right choice.

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, no prerequisites (e.g., must the dashboard already exist?), and no mention of alternatives among the crowded dashboard siblings. The agent must infer everything from the name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully describes the runtime effect (the set fills with marks under the pointer and clears on leave), which is genuine behavioral context beyond a restatement. But it omits whether this mutates the workbook, required permissions, whether the target_set must already exist, and side effects on existing actions.

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

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

Two short sentences, front-loaded with the action being added and followed by the effect. No filler, though the parenthetical and second sentence could be tightened slightly.

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?

This is a mutation tool with 8 parameters, zero schema coverage, and no annotations, so the description is the only guidance. An output schema exists so return values need not be explained, but the description never states prerequisites, permission requirements, or mutation side effects, leaving significant gaps for an agent to call it correctly.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and only partially does: 'clears when it leaves' loosely maps to clear_option, 'hover' maps to event_type, and 'set' hints at target_set. The remaining parameters (caption, source_sheet, single_select, selection_mode) receive no semantic help whatsoever.

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 ('Add a Set Action') and clarifies the underlying object with the parenthetical '(edit-group-action)', which is helpful for matching Tableau's UI concept. It is distinguishable from sibling actions like add_dashboard_toggle_button or initialize_dashboard_filter_action by naming the specific action type, though it never explicitly contrasts them.

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 second sentence implies the use case ('enabling hover-driven labels and calculations') and the default event_type of on-hover, so an agent can infer when this action is appropriate. However, it gives no explicit when-to-use versus add_dashboard_action or other action siblings, and no prerequisites.

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

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

With no annotations, the description carries the full behavioral burden and delivers almost nothing: it does not say what gets created, where the button lands, what happens to existing dashboard content, or whether target_parameters/target_worksheets scope the toggle. Only 'native button' hints at the artifact.

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

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

A single short sentence with no waste, but its brevity comes from under-specification rather than efficient editing; it is front-loaded only in the trivial sense of being one clause long.

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?

An output schema exists so return values need not be explained, but a 7-parameter creation tool with zero annotation coverage and no parameter documentation is far too thin. The agent cannot determine placement, captioning, or scoping behavior from this definition.

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?

Seven parameters with 0% schema description coverage and the description mentions none of them; position, caption_shown, caption_hidden, initially_hidden, target_parameters and target_worksheets are entirely undocumented in both schema and prose. No compensation for the coverage gap.

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 conveys the effect ('Show/hide a dedicated dashboard sheet container with a native button') but never states the actual action verb, which is 'add' a toggle button to a dashboard like the name implies. It is distinguishable from generic siblings like add_dashboard_action, but the resource and operation are only implied rather than stated.

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 when-to-use guidance, no prerequisites, no mention of alternatives such as add_dashboard_action or add_dashboard_extension despite several closely related siblings. The agent gets no routing information at all.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only states the create action. It does not disclose whether the change is persisted to the workbook or requires a save, what happens to source members not covered by the groups mapping, permission requirements, or reversibility.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though arguably terse for a 5-parameter mutation tool.

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

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

With no annotations, 5 parameters at 0% schema coverage, and a nested 'groups' object, the description is far too thin. An output schema exists so return values are covered, but callers still lack the semantics needed to build a correct groups mapping.

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

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

Schema description coverage is 0%, so the description must compensate. 'Source-field members' loosely maps to source_field and grouping maps to groups, but field_name, default_value, and internal_name — including the default 'Other' fallback behavior — are entirely undocumented.

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 verb+resource ('create a categorical dimension') and the mechanism ('by grouping source-field members'), which is clearer than a restatement of the name. However, it does not differentiate from closely related siblings such as add_set, add_combined_set, or add_hierarchy, which all create derived objects from fields.

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 use this tool versus add_set/add_combined_set, no prerequisites, and no exclusions. An agent must infer the selection context entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It discloses one useful constraint ('bare dimension fields'), but says nothing about whether the hierarchy persists immediately, what happens to existing hierarchies, required permissions, or error behavior for non-dimension fields. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

A single front-loaded sentence with no filler; the verb, resource, and key constraint are all delivered immediately.

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?

An output schema exists so return values need not be described, but for a two-parameter mutation tool with no annotations and no schema descriptions, the definition omits prerequisites, failure modes, and where the hierarchy is created (worksheet vs. datasource). Not sufficient to call correctly with confidence.

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

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

Schema coverage is 0% and both parameters are undocumented in the schema, so the description must compensate. It adds real meaning for 'fields' (they must be bare dimensions, and their order defines the drill order), but contributes nothing about the required 'name' parameter or its constraints.

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 ('Create') and resource ('Tableau drill hierarchy') with meaningful qualifiers ('ordered', 'from bare dimension fields') that separate it from neighboring tools like add_group and add_set. It does not explicitly name a sibling to disambiguate against, but the resource is distinct enough to identify without opening the schema.

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 indication of when to use this over add_group, add_set, or add_combined_set, and no prerequisites such as needing the dimensions to already exist or a workbook to be loaded. Usage must be inferred entirely from the verb.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing. "Activate" implies a state change, but there is no statement about permissions, whether an existing datasource is replaced, what happens on failure, or whether the file must already exist.

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

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

A single short sentence with no filler, front-loaded with the action. Its brevity is appropriate in form; the shortfall is substance, not structure, so it is not penalized here.

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 output schema covers return values, so those need not be described. But for a 3-parameter mutation tool with 0% schema coverage and no annotations, the description leaves the agent unable to call it correctly or confidently.

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

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

Schema description coverage is 0%, so the description must compensate and does not: neither name, filepath, nor the table_name default of "Extract" is explained. The meaning of "name" (datasource name vs. connection name) is genuinely ambiguous given the sibling set.

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 verb+resource pair ("add ... data source") is identifiable, but "another independent extracted data source" is jargon-heavy and doesn't clarify what an 'extracted' source is. It never distinguishes itself from siblings like set_hyper_connection or select_datasource, which an agent must choose between.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as set_hyper_connection or set_csv_connection, which occupy adjacent territory. The agent is left to infer context entirely from the tool name.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a persistent mutation of the workbook, but says nothing about permissions, failure modes (e.g., duplicate parameter name), what happens to defaults, or whether the change is saved or only staged in memory.

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 single sentence is front-loaded and free of filler, but for a 12-parameter mutation tool this is under-specification rather than conciseness. There is no structure an agent can act on.

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

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

Although an output schema exists and return values need not be described, the definition omits everything else needed for a complex 12-parameter tool with no annotations: parameter meanings, write semantics, and usage context. It is far too thin for the tool's complexity.

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

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

The schema has 12 parameters with 0% description coverage, and the description mentions none of them. Non-obvious fields like domain_type ('range'), granularity, allowed_values, allowed_aliases, and internal_name are left entirely unexplained, so an agent cannot populate them meaningfully.

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 verb and resource ('Add a parameter to the workbook'), so an agent knows exactly what operation it performs. However, it offers no differentiation from structurally similar siblings such as add_calculated_field, add_group, or add_set, which all add objects to a workbook.

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 use this tool versus the many other 'add_*' siblings, no prerequisites (e.g., must a workbook be open or uploaded first?), and no caveats. Usage must be entirely inferred from the name.

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

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

With no annotations provided, the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether the band is persisted to the workbook, whether it requires an existing axis to be present (only implied), what happens on re-invocation, or what the operation returns. The single word 'native' hints at a rendering distinction but is unexplained.

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 one sentence is front-loaded and free of padding, so it is structurally fine. However, brevity here reads as under-specification rather than efficiency given the tool's 11 parameters and mutation semantics.

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?

An output schema exists so return values need not be explained, but the description is otherwise inadequate: 11 undocumented parameters, no annotations, no usage guidance, and no behavioral disclosure for a tool that mutates a worksheet's axis rendering.

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

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

Schema description coverage is 0% across 11 parameters, so the description must compensate and it does not mention a single parameter. Fields like scope, formula, probability, symmetric, and reverse_palette are completely opaque to the agent.

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 ('Add') and resource ('percentage distribution band') plus a scoping constraint ('on an existing axis'). It is clear what the tool does, but it does not differentiate itself from the closely related sibling add_reference_band, leaving the agent to guess which band type to choose.

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 use this versus add_reference_band, add_reference_line, or configure_chart, nor any prerequisite beyond the implicit 'existing axis'. The agent must infer the selection criteria entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It signals a mutating 'Add' and a 'native' band, but says nothing about prerequisites (an existing axis), reversibility, permissions, or how the lower/upper values interact — a substantial gap for a mutation tool.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though for a 13-parameter tool that efficiency shades into under-specification rather than true conciseness.

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

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

With no annotations, 13 undocumented parameters, and only a one-line description, the definition is not complete enough for reliable invocation. The output schema relieves it of explaining return values, but the input side remains severely under-described.

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

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

Schema description coverage is 0% across 13 parameters. The phrase 'constant or field-backed' loosely maps to the value/field pairs and lower/upper defaults, but the description never explains lower_value vs lower_field, formulas (min/max), labels, scope, or pane_index — leaving most parameters undocumented.

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 gives a specific verb (Add), resource (native filled band), and scope constraint (on an existing axis), plus a constant-vs-field-backed distinction. This lets an agent distinguish it from add_reference_line and add_percentage_band by implication, though neither sibling is named.

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 when-to-use or when-not-to-use guidance and no named alternative. The only constraint, 'on an existing axis', is scope rather than a selection rule, so the agent gets no help choosing between this and add_reference_line / add_percentage_band.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers little: no note on permissions, whether the line can be modified/removed, what happens to existing lines, or the side effects of a write ('add') operation. The phrase 'configured worksheet pane' faintly implies a prerequisite but is never made explicit.

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

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

A single, front-loaded sentence with no wasted words. It is efficient, though the brevity contributes to the under-specification rather than reflecting disciplined conciseness.

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 mutation tool with no annotations and no parameter documentation, one sentence is far too thin; only the existence of an output schema relieves the description of explaining return values. An agent lacks enough information to call this correctly against its 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?

With 10 parameters and 0% schema description coverage, the schema documents nothing. The description only hints at field dimensions via 'field-backed', giving no meaning for label, scope, formula, tooltip, label_type, pane_index, or probability — a substantial gap the description fails to close.

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

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

Clear verb+resource: it adds a 'field-backed reference line' to a 'configured worksheet pane'. That is more specific than a bare restatement, but it never distinguishes this from the near-identical siblings add_reference_band and add_percentage_band, which an agent must choose between.

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 versus alternatives, no prerequisites beyond the implicit 'configured pane', and no conditions for choosing a reference line over a band or percentage band despite their obvious overlap.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what gets created and why, but says nothing about permissions required, whether an existing set is overwritten, failure modes, or whether the change is saved immediately. For a mutation tool with nine parameters and no annotations, this is a significant gap.

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

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

The description is front-loaded with the core action and then immediately gives the two key usage modes. It is compact and avoids filler, though the parenthetical example and second paragraph could be slightly tighter. Every sentence earns its place, but it is not maximally crisp.

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?

An output schema exists, so return values need not be explained. However, with nine input parameters at 0% schema coverage and no annotations, the description only covers two high-level usage patterns and leaves most parameter behavior and mutation side effects undocumented. It is not complete enough for an agent to invoke the tool correctly across its full parameter space.

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

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

Schema description coverage is 0%, so the description must compensate for all nine parameters. It only explains the combined use of basis_field and top_n and mentions omitting them, while leaving set_name, dimension_field, members, direction, aggregation, use_all, and internal_name entirely unexplained. The added meaning is helpful but covers only a small fraction of 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: 'Create a Tableau set (datasource filter-group) for membership logic.' It adds clarifying scope ('datasource filter-group') that helps distinguish it from generic grouping tools. However, it does not explicitly compare itself to close siblings like add_group or add_combined_set, so an agent must infer the distinction.

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

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

It gives clear conditional usage: 'Use basis_field + top_n to build a top-N set' and 'omit both to create an empty set used as a Set Action target.' This tells the agent how to configure the tool for two concrete scenarios. It does not mention when to prefer this tool over siblings such as add_group or add_combined_set, which prevents a top score.

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

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

No annotations are provided, so the description must fully disclose behavior. It states that a blank worksheet is added, but does not mention side effects (e.g., whether the worksheet becomes active, how it interacts with existing worksheets, or if it requires save). No annotation 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 single, clear sentence with no wasted words. It is appropriately concise for a simple tool.

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

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

Given the tool has one parameter and an output schema (likely returns the worksheet ID or success), the description is minimal. It does not describe the return value or any constraints. For a simple add operation, this is adequate but not complete; the agent may need more context to use it correctly.

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

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

The input schema has one required parameter ('worksheet_name') with 0% description coverage. The description does not explain what 'worksheet_name' means or any constraints (e.g., uniqueness, length). Since there is only one parameter, the baseline is 4, but the description adds no value beyond the schema, so a 3 is appropriate.

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

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

The description clearly states the action ('Add') and the resource ('a new blank worksheet to the workbook'). It distinguishes from sibling tools like 'clone_worksheet' or 'configure_chart', though it could be more specific about the context (e.g., that it adds to an existing workbook).

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 like 'clone_worksheet' or 'add_dashboard'. It does not specify prerequisites (e.g., workbook must be open) or exclusions. The context signals show no annotations, so the description carries the full burden.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose non-obvious traits: it operates only on on-disk files, will not touch the in-memory workbook, does not persist the current workbook, and requires a prior save for fresh workbooks. It does not state whether the file is modified or what kind of report is produced, but the operational constraints are well surfaced.

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?

Purpose sentence is front-loaded, followed by the constraint block; every sentence carries information and there is no filler. Slightly verbose phrasing around the save_workbook instruction, but acceptable.

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?

An output schema exists, so return values need not be described. The key gap is sibling routing versus validate_workbook/profile_twb_for_migration; otherwise the prerequisites and constraints an agent needs to invoke this correctly are present.

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

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

One parameter with 0% schema description coverage, so the description must compensate. It adds real meaning ('must already exist on disk', TWB/TWBX file scope) but omits format details such as absolute vs relative paths, accepted extensions, or path syntax.

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 (analyze) and resource (TWB/TWBX file) plus the scope of analysis (against cwtwb's declared capabilities). It is clearer than most siblings, though it does not explicitly distinguish itself from near-neighbors like validate_workbook, profile_twb_for_migration, or inspect_target_schema.

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?

Gives a concrete precondition (file_path must already exist on disk), an explicit exclusion (cannot analyze the in-memory workbook, does not save it), and a routing instruction (call save_workbook first for a newly generated workbook). It stops short of naming alternative analysis/validation siblings and when to prefer them.

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

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

With no annotations, the description carries the full burden. It indicates the tool is likely destructive (applying migrations, writing files) and does not mention idempotency or side effects. The description adds some behavioral context ('write a migrated TWB plus reports') but lacks details on error handling or state changes.

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 that states the core action. It is front-loaded and contains no filler, but could benefit from slightly more structure (e.g., listing key parameters).

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 5 parameters (3 required) and no annotation support, the description is incomplete. It does not explain return values despite having an output schema, nor does it cover migration scope or overrides. Sibling tools with similar purposes demand clearer differentiation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'file_path', 'target_source', 'output_path', and 'scope' implicitly via 'workbook migration', but provides no details on 'mapping_overrides'. The description does not explain parameter meaning or expected formats beyond what the schema minimally indicates.

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 'Apply a workbook migration and write a migrated TWB plus reports', which is a clear verb+resource combination. However, it does not differentiate from the sibling 'migrate_twb_guided' or 'preview_twb_migration', leaving ambiguity about when to use this tool versus those.

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 like 'migrate_twb_guided' or 'preview_twb_migration'. No context about prerequisites, typical workflow, or exclusions is 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?

No annotations provided, so description must disclose behavior. It states 'rewrite ... using replacement fields' but doesn't mention mutability, whether operation is reversible, or if it requires prior preview. For a mutation tool with no annotations, more detail is needed.

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

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

Single sentence, no fluff. It front-loads the action and scope. Could add a second sentence for when to use or behavior, but current is acceptable.

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 (refactoring a worksheet), and no annotations or output schema description, the description is incomplete. It omits what 'replacements' are, whether it validates, and how errors are handled. Output schema exists but description doesn't leverage it.

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

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

Schema coverage is 0% (no descriptions), but description mentions 'replacement fields', hinting at the 'replacements' parameter. However, it doesn't clarify the format or meaning of the replacement fields, leaving ambiguity. With 0 parameters described in schema, baseline is 3 but could be higher.

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

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

Description clearly states action ('rewrite one worksheet'), resource ('worksheet'), and scope ('without touching others'). It distinguishes from siblings like 'preview_worksheet_refactor' or 'configure_worksheet_style', though not 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?

Implies use when needing to refactor a single worksheet without affecting others, but lacks explicit when-to-use vs alternatives, such as when to use 'apply_twb_migration' or 'preview_worksheet_refactor' first.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the most important trait: it will not mutate anything. It adds nothing further (scope of the audit, how findings are surfaced, or limits).

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

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

A single front-loaded sentence with the verb and resource first and the read-only qualifier at the end. No filler.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. The description is nearly sufficient for a zero-arg read tool, though it never states the auditing scope (whole workbook vs. a datasource).

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond what the empty schema already conveys.

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 ('Report') and precise resource ('calculated-field datatype/role contradictions'), which is more specific than a generic 'audit'. The 'without mutation' qualifier helps distinguish it from repair_calculated_field_issues, but no sibling is named 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?

Usage is only implied: an agent can infer this is the read-only check to run before or instead of repair_calculated_field_issues. There is no explicit when-to-use, no prerequisite, and no named alternative.

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

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

No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as side effects (e.g., whether cloning copies dependencies like calculated fields), authorization requirements, or impact on source worksheet. The description only states what the tool does, not how it behaves.

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

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

The description is very short (one sentence) and directly states the purpose. It could be considered under-specified, but it is concise and front-loaded with the key action. However, it sacrifices necessary detail for brevity.

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 (cloning involves copying multiple elements), the description is incomplete. It does not mention what exactly is cloned (e.g., fields, formatting, filters). Although an output schema exists, the description lacks behavioral context needed for correct invocation.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions. The tool description does not add any meaning to the parameters 'source_worksheet' and 'target_worksheet'. It is unclear what format or identifiers are expected (e.g., worksheet names or IDs).

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 'Clone an existing worksheet and its worksheet window', which clearly indicates the action (clone) and the resource (worksheet and its window). It distinguishes from siblings like 'add_worksheet' and 'configure_worksheet_style', though it doesn't explicitly differentiate from them.

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 is provided on when to use this tool versus alternatives. For example, it doesn't mention when to use 'clone_worksheet' instead of 'add_worksheet' or 'configure_worksheet_style'. There is no context on prerequisites or limitations.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether this mutates/overwrites existing chart configuration, creates a chart if none exists, requires permissions, or is reversible. For a write-oriented tool with zero annotation coverage, this is a substantial gap.

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, front-loaded sentences with no filler and the resource pointer clearly set off. It is structurally efficient, though the extreme brevity masks real under-specification rather than achieving it.

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 27-parameter configuration tool with no annotations and 0% schema coverage, the description is far too thin to guide correct invocation. An output schema exists so return values need not be covered, but the missing parameter and behavioral detail leaves the agent poorly equipped.

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 27 parameters at 0% schema description coverage, and the description supplies essentially no parameter meaning. 'Chart type and field mappings' loosely gestures at mark_type and the encoding fields (rows, columns, color, label), but the vast majority of parameters remain undocumented in both schema and description.

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

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

States a specific verb and resource with scope ('Configure chart type and field mappings for a worksheet'), which is clearer than a tautology. However, it does not distinguish itself from closely related siblings like configure_chart_recipe, configure_layered_chart, and configure_dual_axis, so an agent cannot tell from the description alone which chart-configuration entry point fits.

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 points to a skill resource (read_resource('cwtwb://skills/chart_builder')) for chart type selection, which is useful supporting guidance. But it never states when to use this tool versus the several sibling chart/config tools, so usage is only implied rather than routed.

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

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

With no annotations, the description carries the full behavioral burden and delivers little: it does not state that this mutates the workbook, what permissions are required, what happens on failure, or what auto-prerequisite behavior entails (that lives only in the schema default). Mentioning the registry is minor context against a mutation tool that discloses almost nothing.

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 with the purpose front-loaded and no filler. The resource pointer is useful, though the quoted function-call syntax is awkward and would read better as plain prose.

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?

An output schema exists, so return values need not be described. But with no annotations, 0% parameter coverage, and undefined recipe/registry concepts, the definition leaves an agent without enough to invoke this mutation tool correctly; the resource pointer is suggestive but insufficient to close 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 0% and the description names none of the four parameters, so worksheet_name, recipe_name, recipe_args, and auto_ensure_prerequisites carry no meaning beyond their bare titles. Referencing a resource that might document patterns is a partial gesture at compensation but adds no concrete parameter semantics.

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

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

States a specific verb ('Configure') and resource ('showcase recipe chart') and locates it in the 'shared recipe registry', which is distinct from the sibling configure_chart. However it never explains how a 'recipe' chart differs from the plain configure_chart, so an agent cannot confidently choose between them from the description alone.

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 only guidance is a pointer to read the chart_builder resource for 'recipe chart patterns', which is about how to build rather than when to use this tool versus configure_chart or configure_layered_chart. No prerequisites, no exclusions, no conditions that select this tool over siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Set' implies mutation, and 'preserving pane calculation context' is a useful side-effect hint, but the description omits permissions, overwrite behavior, reversibility, and what the runs actually do.

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 definition is a single front-loaded sentence with no filler. It is appropriately concise structurally, though it is so terse that it withholds detail which would be useful.

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?

An output schema exists, so return values need not be explained. However, with no annotations and 0% input schema coverage, the description is too thin for an agent to call this tool correctly; it never explains the runs structure or when to use this tool versus its many 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 description coverage is 0%, so the description must compensate. 'literal/field' vaguely hints at label types, but it does not explain the required worksheet_name, the required runs array of objects, or the pane_index default, leaving all three parameters semantically undocumented.

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 ('Set') and resource ('mark labels'), so the general purpose is inferable. However, 'rich literal/field' is jargon that obscures exactly what is being configured, and there is no differentiation from siblings like configure_custom_tooltip or set_worksheet_caption.

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 when-to-use guidance, prerequisites, or alternatives are provided. The phrase 'while preserving pane calculation context' hints at a constraint but does not tell the agent when this tool should be selected over other label or worksheet configuration 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing: not whether the tooltip replaces or appends existing content, what a 'run' entails, permission needs, or reversibility. It only vaguely names the payload types.

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?

It is a single short, front-loaded sentence with no padding, which is structurally fine. However, the brevity comes at the cost of comprehensibility, so it is terse rather than efficiently informative.

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

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

For a no-annotation mutation tool with three parameters at 0% schema coverage, the description leaves almost everything an agent needs unstated: parameter meanings, side effects, and prerequisites. An output schema exists so return values are excused, but the input/behavioral gaps are severe.

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

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

Schema description coverage is 0%, so the description must compensate, but it only loosely gestures at 'runs' and mentions a non-existent 'filter_fields'. Required parameters 'worksheet_name' and optional 'pane_index' are never explained, leaving their meaning to guesswork.

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 verb 'Set' and the implied resource (a custom tooltip's runs/sheets) are present, so it is not pure tautology, but the description never says it configures a tooltip and instead leans on jargon like 'field runs' and 'embedded sheets'. It references 'filter_fields', which is not even a parameter, creating confusion rather than clarity.

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 tool, when not to, or how it differs from the closely named sibling configure_custom_label. The agent is given no routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, but it only says what linking means conceptually. It does not disclose whether the operation mutates existing worksheet state, what happens to an existing blend, what permissions or preconditions are required, or any side effects.

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

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

The description is a single front-loaded sentence with no filler or repetition. It is concise, though for a four-parameter configuration tool the brevity borders on under-specification rather than optimal sizing.

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

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

For a tool with four required parameters, a nested object, and no annotations, the one-sentence description is substantially incomplete. The output schema relieves it of explaining return values, but it still omits parameter meaning, preconditions, and behavioral effects that an agent needs before invoking it.

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

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

Schema description coverage is 0% across four required parameters, including a nested object (link_fields), so the description needed to compensate heavily. Instead it provides no parameter-level meaning: worksheet_name, secondary_datasource, link_fields, and secondary_fields are all left entirely undocumented in both the schema and the description.

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

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

The description clearly states a specific action ('Link ... sources') and resource ('independently aggregated sources in a worksheet'), and it distinguishes the operation from a join. However, it does not differentiate this tool from nearby siblings such as import_blended_field or link_worksheet_filters, so it falls short of a 5.

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 'without a join' hints at when blending is appropriate rather than joining, but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. An agent receiving this tool among many worksheet/datasource configuration tools gets no routing information.

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

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

No annotations are provided, so the description carries the full disclosure burden for a 31-parameter mutation-style tool. It omits whether the worksheet must already exist, whether existing chart settings are overwritten, what permissions are needed, and whether the change is reversible. It adds almost nothing beyond 'this configures a dual-axis chart.'

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

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

Two short sentences, front-loaded with the action, with no filler or redundancy. The second sentence is a routing hint rather than bloat, though it does substitute a pointer for information the description could have supplied.

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 31-parameter tool with zero schema descriptions, no annotations, and only one required field documented by name, the description is far too thin. The presence of an output schema excuses it from explaining return values, but not from explaining how to drive the input parameters.

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

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

Schema description coverage is 0% across 31 parameters, and the description explains none of them. Pairs like size_1/size_2, color_1/color_2, mark_type_1/mark_type_2, dual_axis_shelf, synchronized, and table_calc_overrides are left entirely opaque, so an agent must guess at the axis-1/axis-2 semantics and accepted formats.

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 verb and resource ('Configure a dual-axis chart composition'), which is enough to tell it is a chart-configuration tool. However, it does not differentiate itself from siblings like configure_chart, configure_layered_chart, or configure_chart_recipe, nor does it say what a 'composition' modifies.

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 only guidance is a pointer to a skill resource for 'dual-axis chart patterns and best practices,' which is about how to do it well, not when to choose this tool over configure_chart or configure_layered_chart. No prerequisites, exclusions, or alternative-selection conditions are stated.

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

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

No annotations are provided, so the description carries the full burden. It states no mutation semantics, side effects, permission/auth needs, reversibility, or whether it requires a pre-existing layered chart, despite 'configure'/'Build' implying a write to an existing worksheet. Only niche sort/table-calc semantics are disclosed.

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

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

The text is short but misallocated: it front-loads a vague purpose sentence and then spends most of its length on sort_mode and table_calc_context, two of the least central parameters, while ignoring the core panes/rows/columns inputs. Structure does not prioritize what an agent needs first.

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 14-parameter mutation tool with zero annotation coverage and zero schema descriptions, the description should define the encodings/panes model and most parameters. It covers roughly two parameters and leaves the rest to guesswork, so an agent cannot reliably construct a correct 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 coverage is 0% across 14 parameters, so the description must compensate, and it does not. It clarifies only sort_mode values and table_calc_context, leaving rows, columns, panes, filters, axis_shelf, sort_field, synchronized, table_calc_overrides and others entirely undocumented.

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 opening line gives a verb and a loose resource ('Build layered panes with encodings, ordered values and native styles'), but 'layered panes' is jargon that doesn't map to an obvious user concept, and nothing distinguishes this tool from siblings like configure_chart, configure_dual_axis, or configure_chart_recipe. An agent can infer it configures a multi-pane chart, but only vaguely.

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

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

The description explains what two sort_mode values mean, but never says when to reach for this tool versus configure_chart/configure_dual_axis/configure_chart_recipe, nor any prerequisite (e.g., an existing worksheet/layered view). No when-to-use or when-not-to-use guidance is present.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Configure' implies mutation, but nothing says whether existing subtotals are replaced or merged, whether the label/aggregation defaults are applied on every call, or what permissions are needed.

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

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

A single well-formed sentence with the core purpose front-loaded and no filler. It is terse to the point of being under-specified, but not padded or repetitive.

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?

An output schema exists so return values need not be described, but for a five-parameter mutation tool with zero annotation coverage and zero schema descriptions, the definition is far too thin. It leaves the agent guessing about field selection, aggregation behavior, and side effects.

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

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

Schema description coverage is 0% across five parameters, and the description only obliquely gestures at labels and per-dimension subtotals. It gives no meaning for worksheet_name, measure_fields, subtotal_fields, aggregation, or the default 'Avg.' label, so it does not compensate for the schema gap.

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 (configure) and resource (subtotals), plus the sub-resource of per-dimension subtotal labels. An agent can tell this is the worksheet subtotals tool; it just doesn't need to name a sibling because no other tool covers subtotals.

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 indication of when to use this versus alternatives, no prerequisites (e.g., worksheet must exist or be opened first), and no mention of what state the worksheet must be in. The agent is left to infer everything from the name.

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

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

With no annotations, the description must carry the full behavioral burden, but it only hints that passing an empty list disables completion. It omits permission requirements, whether changes are reversible, side effects, and any other behavioral traits expected from a mutation-like configuration tool.

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

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

The single-sentence description is compact and front-loads the main action, but it omits key identifying context for the tool, so its brevity comes at the cost of clarity rather than being fully earned.

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 configuration tool with two required, undocumented parameters and no annotations, the description is too thin. Even though an output schema exists, essential input semantics and usage context are missing, leaving an agent with insufficient information to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate; instead it only explains one behavior of the 'fields' parameter ([] disables completion) and says nothing about 'worksheet_name' or the expected format of field names. The schema provides only types/titles, leaving both parameters largely undocumented.

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 verb-like behavior ('Complete missing dates') and a scope ('discrete exact-date fields'), which hints at the resource (date range configuration for a worksheet). However, it never names the tool's actual resource (worksheet domain range) or clearly distinguishes it from the many sibling configure_* tools, making the purpose only moderately inferable.

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 use this tool versus alternatives like set_date_options or enable_domain_completion, both of which appear related. The only conditional fragment ('[] disables completion') is a parameter behavior, not a usage rule.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one behavioral quirk (pane_mark_style resolving native qualified references), but says nothing about whether styling overwrites existing settings, permissions required, reversibility, or scope of effect for a 29-parameter mutation tool.

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

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

The purpose is front-loaded and the three blocks are short, but the middle sentence about pane_mark_style is an oddly narrow detail given the much larger undocumented surface, making the structure feel unbalanced rather than optimally prioritized.

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 29 parameters, 0% schema coverage, no annotations, and only a required worksheet_name plus an output schema, the description is far too thin to guide correct invocation. It covers a handful of style categories and one parameter quirk, leaving the agent to guess at the rest.

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

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

Schema description coverage is 0% across 29 parameters, so the description must compensate but barely does. It mentions only background color, the axis/grid/border visibility flags collectively, and one specific parameter (pane_mark_style), leaving the vast majority of parameters (map_style, legend_style, cell_formats, etc.) undocumented anywhere.

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 ('Apply worksheet-level styling') and enumerates the style categories (background color, axis/grid/border visibility). This is distinguishable from siblings like set_field_format or set_worksheet_title. It stops short of explicitly naming an alternative tool, so it doesn't reach 5.

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 explicit when-to-use or when-not guidance and no routing to alternatives among the many style-related siblings (set_field_format, set_shape_palette, add_reference_band). The only pointer is a formatting best-practices resource, which is not usage selection guidance.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not disclose that this mutates the workbook, what happens to the existing domain, whether the field must already be continuous, permissions required, or reversibility. It implies a write operation ('extend', 'allow calculations') without characterizing it.

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

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

A single front-loaded sentence with no filler, which is structurally fine, but it is under-specified rather than genuinely concise given the tool's complexity. Nothing is wasted, but little is said.

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?

An output schema exists so return values needn't be explained, but for a 5-parameter mutation tool with zero annotation coverage and zero schema descriptions, the definition leaves critical calling information missing. It is not complete enough for reliable 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?

All 5 parameters have 0% schema description coverage, and the description mentions none of them (field, periods, period_type, calculations_on_densified_marks, worksheet_name). Meaning such as what 'periods' counts or what period_type accepts is completely absent.

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 recognizable action (extend a continuous date domain) tied to a resource, but it is vague about scope and offers no differentiation from close siblings like configure_worksheet_domain_range or enable_domain_completion. An agent cannot reliably tell which of these overlapping tools to call.

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 when-to-use guidance, no prerequisites, and no named alternative. The clause 'allow calculations on added periods' hints at a scenario but never states the condition under which this tool should be chosen over configure_worksheet_domain_range.

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

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

No annotations are provided, so the description carries the full burden. It discloses that YAML/JSON contain an editable native XML tree, assets are copied alongside definitions, unknown XML is retained, only XML syntax is checked, the current editor session is not modified, and existing output requires force. It omits permission requirements and error behavior, but covers important behavioral traits.

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

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

Front-loads the core purpose, then adds necessary behavioral caveats in compact sentences. No redundant or filler content; every sentence adds value for a tool with no annotations.

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

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

Given no annotations and no output schema, the description is fairly complete on behavior and caveats. It does not describe return values or error handling, which would be useful in the absence of an output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that output format is determined by output suffix (output_path) and that force is needed to overwrite existing output, but leaves input_path and exact path/format semantics undocumented.

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 (convert), resources (TWB, TWBX, YAML, JSON), and key constraints (by output suffix, without an editor session). This distinguishes it from siblings like open_workbook or save_workbook that operate within an editor session.

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

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

Provides clear context: use when converting between formats without an editor session, and notes that existing output requires force. It does not name alternatives or explicitly exclude other tools, but the condition for use 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether an existing custom layout is overwritten, what 'shared IDs' means operationally, whether dashboard_name must already exist, or how conflicts are resolved — only the vague verb 'preserve'.

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

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

A single short sentence with no filler, so it is concise. However, the brevity comes at the cost of clarity, and the one sentence is not front-loaded with a recognizable action verb.

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?

An output schema exists, so return values are covered elsewhere. But with zero annotation coverage, zero parameter documentation, and no usage context, the description leaves an agent without enough to call this 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 0% for two parameters. The description hints at device values by mentioning 'Phone/Tablet', which loosely maps to device_name, but dashboard_name — the required parameter — is never explained or constrained in either the schema or the description.

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

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

The name promises a copy operation, but the description says only 'Preserve default geometry', never stating that it copies a default device layout onto a custom one. 'Shared IDs' and 'geometry' are unexplained jargon, so the agent cannot confidently say what the tool produces.

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 when-to-use statement, no condition for choosing this over siblings like enable_automatic_phone_layout or generate_layout_json, and no prerequisite noted. The agent is left to infer everything from the name.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool modifies existing files, requires specific permissions, or if the creation is reversible. The word 'create' implies a write operation, but no further details are given.

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, short sentence that directly states the tool's purpose. It is concise and front-loaded, though it could benefit from additional 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?

Given the presence of an output schema and the relatively simple operation (creation from template), the description provides the core purpose. However, it lacks details on parameter behavior, error conditions, or what happens to existing workbooks. It is 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?

The input schema has 2 parameters with 0% description coverage, meaning the description adds no detail beyond the schema. However, the parameter names ('template_path', 'workbook_name') are fairly self-explanatory. The description clarifies that the template is from a TWB/TWBX file, which adds context.

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

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

The description specifies the action ('create a new workbook') and the source material ('from a TWB or TWBX template file'). However, it does not differentiate from siblings like 'generate_workbook_from_run' or 'save_workbook', which could create ambiguity.

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

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

The description lacks any guidance on when to use this tool versus alternatives (e.g., 'generate_workbook_from_run' or 'open_workbook'). It does not mention prerequisites, such as whether the template file must exist or be provided via a path.

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

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

No annotations are provided, so the description must carry the full burden. It accurately states the tool's behavior (describing one capability) but does not disclose side effects, permissions, or error conditions. The description is honest but minimal.

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, efficient sentence with no wasted words. It is front-loaded with the key action and resource.

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 is low (simple retrieval with 2 parameters and an output schema), the description is mostly adequate. However, the lack of parameter semantics and usage guidance reduces completeness for an agent without external knowledge.

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

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

Schema description coverage is 0%, and the description does not explain what 'kind' and 'name' refer to or how to obtain valid values. The description adds no meaning beyond the schema field titles, leaving the agent to guess.

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 retrieves a capability and its support tier, using a specific verb ('describe') and resource ('capability'). It distinguishes from sibling tools like 'list_capabilities' by focusing on a single capability, though it does not explicitly contrast them.

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 is provided on when to use this tool versus alternatives (e.g., 'list_capabilities'). The description lacks context on prerequisites or appropriate usage scenarios, leaving the agent to infer from the name.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention if the tool is read-only, has side effects, requires authentication, or any constraints. The description only states the purpose but not the 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?

The description is a single sentence, front-loaded with the action, and contains no unnecessary words. It is appropriately concise for a simple tool.

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

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

Given the tool's complexity (one parameter, no annotations, but an output schema exists), the description is too sparse. It does not explain the tool's purpose relative to siblings, the format of the summary, or prerequisites. The output schema may provide return structure, but the description should still set expectations.

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

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

Schema coverage is 0%, meaning the input schema provides no description for the 'file_path' parameter. The description does not explain what 'file_path' should point to (e.g., a TWB file, a specific format). With only one parameter, the description should add 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 states 'Summarize the non-core capability gap of a TWB template', which is a specific verb ('Summarize') and resource ('non-core capability gap of a TWB template'). It is clear and distinct from sibling tools like 'profile_twb_for_migration' or 'analyze_twb'.

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 is provided on when to use this tool versus alternatives like 'profile_twb_for_migration' or 'analyze_twb'. The description does not explain what constitutes a 'non-core capability gap' or in what context this is relevant.

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

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

With no annotations, the description carries the full behavioral burden. It does not disclose whether the operation mutates the workbook, whether it is reversible, whether it overwrites an existing phone layout, or any permission requirement – all important for a layout-generation action.

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

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

A single, front-loaded sentence with no filler. It is appropriately sized for the operation, though its brevity comes partly at the cost of the missing detail noted elsewhere.

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?

An output schema exists, so return values need not be explained, but the 0% schema coverage means the description should cover the parameters and basic behavior. It omits both, leaving the agent under-informed for a two-parameter layout action.

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

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

Schema coverage is 0% and the description explains neither parameter. 'Default dashboard objects' loosely hints at dashboard_name, but worksheet_height – a non-obvious tuning parameter with a default – is never mentioned, so the description fails to compensate for the empty 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 gives a specific verb ('Derive') and resource ('a scrolling Phone layout from the default dashboard objects'), making the operation's intent clear. It does not, however, differentiate itself from related siblings such as copy_default_device_layout, so an agent must infer which layout tool applies.

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 when-to-use guidance, no prerequisites (e.g. a dashboard must already exist), and no reference to the sibling copy_default_device_layout that a reader would naturally confuse this with. The agent gets no routing help.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the underlying mechanism (an INDEX() detail table calculation) but says nothing about which worksheet artifacts are mutated, whether existing calculations are affected, reversibility, required permissions, 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?

A single, front-loaded sentence with no wasted words. It is appropriately terse for a narrowly scoped operation, though the terseness contributes to the missing usage and parameter 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?

An output schema exists so return values needn't be explained, but for a mutation tool with zero annotation coverage and 0% parameter documentation, the description is far too thin. It omits when to use it, what the parameters mean, and any behavioral side effects an agent needs.

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

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

Schema description coverage is 0% and none of the three parameters are described. The description never mentions worksheet_name, field_name, or ordering_type, nor their defaults ('Domain Completion Index', 'Rows'), so it adds zero meaning to 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 gives a specific verb and mechanism: it adds an INDEX() detail table calculation to trigger Tableau densification. This is more concrete than a generic 'enable' verb. However, it does not distinguish itself from closely related siblings such as configure_worksheet_domain_range or add_calculated_field, so an agent cannot route between them from the text alone.

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 explicit guidance on when to use this tool versus alternatives like configure_worksheet_domain_range (domain range) or add_calculated_field. The phrase 'trigger Tableau densification' implies a context but never states conditions, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that validation occurs, but does not say what happens on validation failure, whether output_path causes a file to be written, or what the DSL is validated against. For a generation tool with zero annotation coverage this is a significant gap.

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

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

A single tight sentence that front-loads the binding action. It is efficient, though cramming two operations ('bind' and 'validate') into one clause slightly muddies the primary action.

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?

An output schema exists so return values need not be described, but with no annotations, 0% parameter coverage, and a nested object parameter, the description is too thin for an agent to invoke this correctly. It leaves the DSL format, slot semantics, and failure behavior unspecified.

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

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

Schema description coverage is 0% and there are three parameters including a nested worksheet_slots object. The description vaguely maps 'worksheet names' to worksheet_slots and 'Gallery template' to template_name, but explains nothing about the slot structure (string or array), the required keys, or output_path's role.

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 verb and resource: binding worksheet names to a Gallery template and validating the layout DSL. It is clear what the tool does, but it does not differentiate itself from close siblings like generate_layout_json, generate_layout_yaml, or diff_template_gap.

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 use this tool versus the sibling layout generators or template tools. No prerequisites, no exclusions, no mention of what a 'Gallery template' must be in order for this to apply.

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

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

No annotations are provided, so the description carries the burden. It discloses that the file is written to disk and later consumed by add_dashboard, but does not state whether an existing file at output_path is overwritten, whether the write requires specific permissions, or what the save returns. Useful context, but incomplete for a write tool with zero 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?

Front-loaded purpose followed by a tight numbered workflow and a compact DSL reference. Every section earns its place; the only mild bloat is restating ' or YAML file' after the header.

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 takes a complex nested object and an output schema exists, so return values needn't be explained. The workflow and DSL spec cover the hard part, though the absence of any guidance on output_path/ascii_preview semantics leaves a small completeness 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 0%, so the description must compensate. It does well for layout_tree, documenting the declarative container DSL (container/worksheet types, direction, children, fixed_size, weight) — the most complex nested parameter. However, output_path and ascii_preview are only vaguely implied (preview via step 2) and never defined, leaving two of three parameters undocumented.

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 ('Generate and save a dashboard layout file') and the output format ('JSON or YAML file'). The sibling generate_layout_yaml exists, and while the name implies the JSON/YAML split, the description never explicitly routes the agent between the two, so sibling differentiation is left to inference.

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 an explicit numbered workflow: call list_worksheets first, design with the user via ASCII preview, then this tool, then add_dashboard with the resulting path. It names the preceding and following sibling tools and the sequencing condition, so the agent knows exactly when this tool fits.

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

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

With no annotations, the description carries the full burden. It discloses the file-write side effect and the ordering dependency on add_dashboard, plus that ascii_preview is required for user confirmation, but omits overwrite behavior, path/permission requirements, and what happens if the file already exists.

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, then presents a compact numbered workflow where every step earns its place. The closing note on the shared DSL is useful rather than padding.

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?

An output schema exists so return values needn't be explained, and the workflow dependencies are covered. But for a 3-required-param tool with a nested, undocumented layout_tree object, the description gives only a pointer ('same DSL as generate_layout_json') rather than enough to construct the tree.

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

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

Schema coverage is 0%, so the description must compensate. It gives partial meaning for all three: layout_tree references the generate_layout_json DSL, ascii_preview is tied to confirmation, and output_path is the <this_file_path> consumed by add_dashboard. However, no format or structure details are provided for the nested layout_tree or the path.

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 ('Generate and save a dashboard layout YAML file') and explicitly contrasts with the sibling generate_layout_json by noting they share the same container DSL. It's clear what the tool produces, though it stops short of stating when YAML should be preferred over the JSON variant.

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 an explicit numbered workflow placing this tool between list_worksheets and add_dashboard, which is strong when-to-use guidance and names the downstream consumer (add_dashboard with layout=<this_file_path>). It lacks an explicit exclusion or rule for choosing YAML vs the JSON sibling.

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