Server Quality Checklist

Tool Scores

• add_seriesB
  3/5.0
  Behavior2/5

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

  With no annotations beyond the title, the description carries full burden for behavioral disclosure. It says it adds a series but does not state effects on existing series, whether it modifies the chart in place, error behavior when the chart is missing, or whether changes are reversible. It also lacks any mention of side effects or return details beyond 'JSON confirmation'.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the purpose. The Args list is compact and adds necessary detail without redundancy, though it duplicates schema field names. No wasted sentences.

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

  Completeness2/5

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

  For a mutation with five parameters and no output schema, the description is incomplete. It lacks prerequisites (existing chart), error conditions, how the series is merged with existing series, and the precise return format. Agents may call it incorrectly without this context.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must explain parameters. It does: explicitly notes which are required (chart_name, series_range) and which default to None, and gives an example format for series_range. This adds meaningful semantics beyond the schema's bare defaults.

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

  Purpose4/5

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

  Description clearly states the action ('Add a data series to a chart') with a specific verb and resource. It is distinct from sibling tools like create_chart or set_chart_type, though it does not explicitly contrast with them, leaving some inference needed.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, nor prerequisites like an existing chart. It does not mention that the chart must already exist or that this is for modifying, not creating, charts. The user must infer context.

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

• delete_named_rangeB
  3.3/5.0
  Behavior3/5

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

  The destructiveness is already declared by destructiveHint=true, so the description need not repeat that. It does add the return type ('JSON confirmation') and marks the 'name' parameter as required, which is useful. However, it omits any mention of side effects, failure behavior if the range doesn't exist, or whether the deletion is irreversible beyond what the annotation implies.

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

  Conciseness5/5

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

  The description is extremely concise: a single action statement followed by a compact argument list and a return line. It is fully front-loaded and contains no filler, making it easy for an agent to parse quickly.

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

  Completeness3/5

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

  For a simple delete operation, the description covers the core action and parameter semantics, and the destructiveHint annotation covers safety. However, it does not describe error cases, permissions, or the effect on dependent formulas/cells, which could leave an agent uncertain about edge scenarios. It is minimally viable but not rich.

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

  Parameters3/5

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

  With 0% schema description coverage, the description must explain both parameters. It provides meaning for 'workbook' (name or path, None = active workbook) and states 'name' is required (though the schema marks it optional with a default). This adds value but remains terse and does not elaborate on formats or constraints beyond that.

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

  Purpose4/5

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

  The description states 'Delete a named range' with a clear verb and resource. It is unambiguous and distinct from sibling operations like create, update, or read by the verb itself, but it does not explicitly name alternatives or contrast with them, so it stops short of full differentiation.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus alternatives such as update_named_range or list_named_ranges. It simply declares the action without context or exclusions, leaving the agent to infer usage.

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

• merge_cellsA
  3.6/5.0
  Behavior2/5

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

  Annotations provide no safety hints (no readOnlyHint or destructiveHint), so the description carries the full burden of behavioral disclosure. It states the core action but omits critical side effects: merging typically keeps only the upper-left cell value, discarding other values, and may fail on overlapping merges. This is a notable gap for a mutating operation.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-sentence purpose followed by a clear Args/Returns block. Every line adds value with no redundancy.

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

  Completeness3/5

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

  The description covers the core operation and parameters, but lacks important context for safe invocation: no mention of data loss on merge, restrictions on valid ranges, or error conditions. The return value is only described as 'JSON confirmation', which is vague. Given the absence of an output schema, more behavioral detail would be needed for full completeness.

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

  Parameters5/5

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

  Schema property descriptions are absent (0% schema coverage), but the description fully documents all three parameters with meaning: workbook name/path, sheet name, and A1-style range address, including defaults. This compensates completely for the schema gap.

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

  Purpose5/5

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

  The description states a specific verb ('Merge'), a resource ('a range'), and the outcome ('into a single cell'). This clearly differentiates it from siblings like unmerge_cells and get_merge_info.

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

  Usage Guidelines2/5

  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. It does not mention unmerge_cells for undo, get_merge_info for inspecting merges, or any exclusions. The usage context is only implied by the tool name.

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

• add_dropdown_validationA
  3.7/5.0
  Behavior2/5

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

  Annotations provide no readOnly or destructive hints, so the description carries the full burden of behavioral disclosure. It states that the tool will restrict a range and return a JSON confirmation, but it does not disclose whether this replaces existing validation, mutates existing cell contents, or what error conditions may arise. That is minimal beyond the basic purpose.

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

  Conciseness5/5

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

  The description is front-loaded with a one-sentence purpose and then follows a tight Args/Returns structure. Every line adds a specification or an example, with no redundancy or filler.

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

  Completeness4/5

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

  For a mutation tool with no annotations and no output schema, the description covers purpose, all parameters, and the return shape, which is enough for an agent to make the call correctly. It does not explain side effects like overwriting existing validation, but that is an edge concern rather than a blocking gap.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates by documenting all four parameters with defaults, examples, and meaning. It clarifies workbook/sheet None meaning active objects, gives an A1-style range example, and explicitly marks values as required with an example, which is valuable because the schema shows ambiguous null defaults.

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

  Purpose5/5

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

  The first sentence, 'Restrict a range to a dropdown list of allowed values,' is a specific verb+object statement that names the exact operation and result. It also inherently distinguishes this from the sibling add_number_validation by specifying a dropdown list, so an agent selecting a validation tool can tell them apart.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus add_number_validation, get_validation, remove_validation, or other range-modification tools. The intended use case is implied by the purpose statement, but there is no explicit when-to-use, when-not-to-use, or alternative-routing guidance.

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

• unmerge_cellsA
  3.7/5.0
  Behavior2/5

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

  Annotations carry only the title, so the description must disclose behavior. It does not mention that unmerging is a mutating operation with potential data consequences, what happens if the address is not currently merged, or any required permissions. The only behavioral extra is the note that it returns JSON confirmation.

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

  Conciseness5/5

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

  The description is short and front-loaded, with a one-sentence purpose followed by compact Args and Returns sections. Every line adds semantics and no filler is present.

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

  Completeness2/5

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

  With no output schema and no behavioral annotations, the description should cover return details and side effects. It only says 'JSON confirmation,' which is vague, and omits edge cases like non-merged ranges and the effect on cell contents after unmerging. Safe invocation for a mutating spreadsheet operation is not fully supported.

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

  Parameters5/5

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

  Schema description coverage is 0% and the schema contains only types/defaults, so the description fully compensates. It explains each parameter: workbook name/path with active default, sheet with active default, and range_address as an A1-style merged-area address with an example.

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

  Purpose5/5

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

  The description states 'Undo a cell merge' with a specific verb and resource, and names the scope via workbook, sheet, and range_address. This clearly sets it apart from the inverse sibling merge_cells and the read-only get_merge_info.

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

  Usage Guidelines3/5

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

  Usage is implied by 'Undo a cell merge' but the description gives no explicit when-to-use guidance, exclusions, or alternatives such as get_merge_info to inspect merges first. There is no misleading guidance, but it relies on inference.

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

• add_worksheetA
  3.8/5.0
  Behavior3/5

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

  Annotations provide no safety hints, so the description carries the burden. It usefully discloses insertion behavior ('1-based tab position to insert before'), target scope ('open workbook'), and return shape, but it does not cover error behavior, duplicate-name handling, or whether changes persist.

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

  Conciseness4/5

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

  The key action is front-loaded, and the Args/Returns sections are tight and scannable. The only minor inefficiency is repeating parameter names that also appear in the schema, but since the schema lacks descriptions this repetition is justified.

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

  Completeness4/5

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

  For a simple three-optional-parameter mutation with no output schema or annotations, the description covers how to call it and what it returns. It is slightly short on side-effect/error context, but nothing essential for a basic call is missing.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must document the parameters, and it does: workbook name/path defaulting to active, name defaulting to Excel's generated name, and index as a 1-based before-position. Each parameter's meaning is fully explained beyond the bare schema.

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

  Purpose5/5

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

  Opening sentence 'Add a new worksheet to an open workbook' uses a specific action and resource, and the sibling list contains no other add-worksheet tool, so there is no ambiguity with activate/rename/delete worksheet operations.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to choose this tool over alternatives or any prerequisites beyond 'open workbook'. It does not mention exclusions or conditions; the practical usage rules are left to inference from sibling names.

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

• delete_chartA
  3.8/5.0
  Behavior3/5

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

  The destructiveHint annotation already signals that this operation is destructive, and the description adds some useful context by explaining that workbook and sheet default to the active ones and that the tool returns JSON confirmation. However, it does not go further to describe irreversibility, error behavior, or effects on related objects.

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

  Conciseness5/5

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

  The description is compact and well-structured with a clear one-line purpose followed by Args and Returns sections. Every sentence adds necessary information without padding or redundancy.

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

  Completeness4/5

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

  For a simple three-parameter destructive tool, the description covers the essential invocation details, parameter semantics, and return format. The lack of an output schema is partially mitigated by the 'JSON confirmation' statement, but the required-parameter inconsistency and absence of error/precondition information leave small gaps.

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

  Parameters4/5

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

  With 0% schema description coverage, the description carries the full parameter documentation burden and does explain workbook, sheet, and chart_name, including default behavior for workbook and sheet. The main weakness is that the description marks chart_name as required while the schema has no required fields and a default of null, which could confuse an agent about whether it must be supplied.

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

  Purpose5/5

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

  The description states 'Delete a chart,' a specific verb plus resource, and the sibling list includes create_chart, list_charts, set_chart_type, and set_chart_title, making the intended operation unambiguous. The Args and Returns sections further clarify target scope without confusing it with other chart-related tools.

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

  Usage Guidelines2/5

  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 delete_worksheet or delete_table, nor any stated prerequisites such as the chart needing to exist. The description only states what the tool does, leaving usage decisions to inference.

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

• list_tablesA
  3.8/5.0
  Behavior3/5

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

  The description aligns with the readOnlyHint annotation, confirming a read-only operation. It adds the return format (JSON with name and range) and explains default behavior for parameters, which provides some context beyond the schema and annotations.

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

  Conciseness5/5

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

  The description is two sentences plus a structured Args/Returns section, front-loading the purpose. It is efficient with no wasted words or redundant details.

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

  Completeness4/5

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

  For a simple read-only listing tool, the description covers purpose, parameters, and return type adequately. It lacks examples or edge-case notes, but given the tool's simplicity and the presence of readOnlyHint, it is reasonably complete.

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

  Parameters4/5

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

  The description explains each parameter's meaning and default behavior ('None = active workbook' and 'None = active sheet'), compensating for the 0% schema description coverage. This is clear and sufficient for correct parameter usage.

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

  Purpose5/5

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

  The description clearly states the resource (Excel tables) and the action (listing) on a worksheet, which is distinct from sibling list tools like list_worksheets or list_charts. It leaves no ambiguity about what the tool does.

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

  Usage Guidelines2/5

  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 such as get_table_info or create_table, nor any mention of prerequisites or exclusions. An agent gets no help in deciding the right context for this tool.

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

• add_color_scaleA
  3.9/5.0
  Behavior3/5

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

  Annotations provide only a title, so the description carries the behavioral disclosure burden. It does disclose the operation type, default color behavior, the mid_color toggle between 2-color and 3-color scale, and a JSON confirmation return value. However, it does not mention side effects like whether existing formatting or conditional formatting rules are overwritten, or any permission requirements.

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

  Conciseness5/5

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

  The description is compact and well-structured with a one-line summary followed by Args and Returns sections. Every line provides useful information, and the most important behavior is front-loaded.

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

  Completeness4/5

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

  For a six-parameter tool with no output schema, the description covers all parameter semantics, defaults, and the return type. It is missing only minor contextual details such as whether the color scale replaces existing conditional formatting rules and more specific result formatting, but the core information needed to call the tool is present.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates by explaining every parameter: workbook/sheet defaults, A1-style range_address, hex RGB color meaning, defaults for min/max, and the conditional behavior of mid_color. This is essential and well done.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Add a 2-color or 3-color scale to a range.' It clearly conveys what the tool does and distinguishes it from generic formatting tools like format_range and from the broader add_conditional_format_rule sibling.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives such as add_conditional_format_rule or format_range. The intended use is only implied by the tool's name and summary, with no exclusions, prerequisites, or selection criteria.

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

• append_table_rowsA
  3.9/5.0
  Behavior3/5

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

  The description discloses that rows must match the table's column count, which is an important constraint, and states that it returns the resulting row count. However, with no annotations for readOnly or destructive hints, the mutating nature is only implied, and potential error handling, side effects, or permission requirements are not addressed.

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

  Conciseness5/5

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

  The description is compact and well-organized, leading with the core action, then detailing each parameter, and ending with the return value. Every sentence is informative, with no redundancy or fluff. The example is concise but illustrative.

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

  Completeness4/5

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

  For a mutating table operation with no output schema, the description covers purpose, parameter semantics, a validation constraint, and the return value. It falls short only in not addressing error behavior or the discrepancy that rows is declared nullable in the schema despite being 'required' in the description. Overall, it gives an agent enough to call the tool correctly in most cases.

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

  Parameters5/5

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

  The description includes a full 'Args' section that maps to all four parameters, explaining that workbook and sheet default to active, table_name is required, and rows must be a list of lists matching column count. It even provides an example. Since schema description coverage is 0%, this fully compensates for the lack of schema-level explanations.

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

  Purpose5/5

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

  The description opens with 'Append one or more rows to the end of a table,' which is a specific verb (append) and resource (table rows) with a clear scope ('to the end'). This distinguishes it from sibling tools like insert_rows or set_range_values, and the title alone would have been ambiguous without it.

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

  Usage Guidelines2/5

  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 such as insert_rows or set_range_values. The description provides parameter details but no selection criteria, exclusions, or situational advice. An agent must infer that append is appropriate for adding rows at the end of a table.

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

• apply_table_styleA
  3.9/5.0
  Behavior3/5

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

  Annotations provide no readOnly or destructive hints, so the description carries the burden. 'Apply' makes the mutating nature clear, and 'Returns: JSON confirmation' gives a basic output expectation. However, it does not disclose whether an existing style is overwritten or whether the table 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.

  Conciseness5/5

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

  The description is compact and well-organized with Args and Returns sections. Every line adds useful information, and there is no filler or redundant restatement of the tool name.

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

  Completeness3/5

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

  The description covers all parameters and the return type, but it omits usage context such as prerequisites, behavior when style_name is invalid, and how this relates to sibling styling tools. For a simple mutation tool it is adequate, but not fully complete.

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

  Parameters4/5

  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 it does: every parameter is explained, including the active-workbook/active-sheet fallbacks and concrete style name examples. It also marks table_name as required, which is important context not visible in the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Apply a built-in table style.' It uses a specific verb and resource, and the parameter list makes it evident this targets an existing table, distinguishing it from table creation, table listing, and other siblings.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when a table already exists and needs a built-in style, but it never explicitly says when to choose this tool over alternatives like format_range or create_table. There is no exclusion guidance or sibling differentiation.

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

• set_chart_typeA
  3.9/5.0
  Behavior3/5

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

  With no safety annotations beyond a title, the description carries the behavioral burden. It does say the tool changes a chart's type and returns JSON confirmation, which is useful. However, it does not disclose that the existing type is overwritten, whether the chart must already exist, or potential side effects on chart series.

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

  Conciseness5/5

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

  The description is compact, well-organized, and front-loaded with the core purpose. The Args section is minimal and each line adds necessary information. There is no filler or redundant text.

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

  Completeness4/5

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

  The description covers parameter semantics, valid chart type values, active defaults, and the return format. It lacks guidance on how to find chart_name or what happens when a chart is not found, but for a straightforward chart modifier this is reasonably complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully documents all four parameters: workbook and sheet with active defaults, chart_name as required, and chart_type with all accepted values. This provides essential meaning that the input schema itself lacks.

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

  Purpose5/5

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

  The description states a specific action and resource: 'Change a chart's type.' This clearly distinguishes it from the sibling tool set_chart_title, which changes a different property. The verb 'change' and noun 'chart type' make the tool's purpose immediately identifiable.

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

  Usage Guidelines2/5

  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 such as set_chart_title, create_chart, or list_charts. It explains defaults for workbook and sheet, but does not state when this tool is appropriate or what prerequisites exist.

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

• activate_worksheetA
  4/5.0
  Behavior3/5

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

  Annotations provide no read-only or destructive hints, so the description carries the behavioral burden. It discloses the state-changing effect ('make active'), the workbook default behavior, and the JSON confirmation return value. It does not mention what happens if the named worksheet does not exist or whether any data is affected.

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

  Conciseness5/5

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

  The description is concise and well-structured, with a clear one-line purpose followed by compact parameter documentation and a return note. No unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple activation tool, the description covers the key facts: what it does, both parameters, the default for workbook, and the return value. The main missing context is error behavior when the worksheet name is invalid, but the low complexity of the operation makes this a minor gap.

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

  Parameters4/5

  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 does: it explains that workbook is a name or path with None meaning active workbook, and that name is the sheet to activate and is required. This is valuable because the schema lists no required parameters and provides no descriptions.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Make a worksheet the active tab in an open workbook.' This clearly distinguishes it from sibling worksheet tools like add_worksheet, delete_worksheet, rename_worksheet, and list_worksheets.

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

  Usage Guidelines3/5

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

  The description implies usage: it is used to select a worksheet as the active tab, likely before other operations such as reading or writing cell values. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

• clear_conditional_format_rulesA
  4/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, and the description's 'Remove all' reinforces that destructive nature. It adds that the operation returns a JSON confirmation and that workbook/sheet can default to active. However, it does not disclose nuances such as whether intersecting ranges or overlapping rules are affected, or irreversibility beyond the annotation. This is adequate but not rich.

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

  Conciseness5/5

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

  The description is a compact docstring with the main purpose front-loaded, followed by a structured Args section and a brief Returns note. Every line carries information and there is no redundant or filler text.

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

  Completeness4/5

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

  For a simple tool with three optional parameters, no output schema, and a destructive annotation, the description covers the essential operational details: what it does, parameter roles, and return type. The only notable omission is clarification of what happens when range_address is omitted (defaults to 'A1'), but this is minor given the low complexity.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description carries the burden of explaining parameters. It documents each one: workbook (None = active workbook), sheet (None = active sheet), and range_address (A1-style with example). It adds meaningful context beyond the bare schema, though it omits the schema's default of 'A1' for range_address, which is a minor gap.

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

  Purpose5/5

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

  The description uses a specific verb ('Remove') and a clear resource ('all conditional formatting rules from a range'), making the tool's intent unambiguous. The wording also distinguishes it from siblings like add_conditional_format_rule and list_conditional_format_rules, which clearly perform different operations.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool—whenever the user wants to delete conditional formatting rules from a range—but it provides no explicit guidance on alternatives or exclusions. There is no mention of preferring this over clear_range or checking existing rules with list_conditional_format_rules first.

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

• get_table_infoA
  4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals safety, and the description adds concrete behavioral context: active workbook/sheet defaults are explained, and the return JSON is specified as column names, range, row count, and style. This goes beyond the annotation without contradicting it.

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

  Conciseness5/5

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

  The description is compact and well organized with a one-line summary, explicit Args, and Returns sections. Every sentence earns its place and key information is front-loaded.

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

  Completeness4/5

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

  For a read-only metadata tool with no output schema and no parameter descriptions in the schema, the description is largely complete: it defines all parameters, states return fields, and clarifies active-context defaults. The only meaningful gap is the required/schema mismatch and the absence of error behavior if the table does not exist.

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

  Parameters3/5

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

  The Args section gives useful meaning to all three parameters, including 'None = active workbook' and 'None = active sheet', which the schema does not explain. However, it states table_name is 'required' while the schema defaults it to null and context signals count 0 required parameters, creating a conflicting signal.

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

  Purpose5/5

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

  The summary line 'Get a table's structure: columns, range, and style' clearly names the verb, resource, and scope. It differentiates from siblings like get_table_data by emphasizing structural metadata rather than cell values, even though 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.

  Usage Guidelines3/5

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

  The description does not explicitly state when to prefer this over related tools such as list_tables or get_table_data, nor does it give exclusions. The intended use is implied by the one-liner, but there is no routing guidance or alternative recommendation.

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

• autofit_columnsA
  4.1/5.0
  Behavior3/5

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

  With no read-only or destructive annotations, the description carries the behavioral burden. It does disclose the core behavior: column widths are changed based on the provided range or used range, and a JSON confirmation is returned. It does not mention side effects, reversibility, or permission needs, but the mutation is clearly inferred from 'Autofit column widths'.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the primary purpose before the argument details. Each line in the Args and Returns sections earns its place, and there is no redundant or filler text. It is appropriately sized for a simple three-parameter tool.

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

  Completeness4/5

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

  The description adequately covers the tool's operation, all optional parameters, the default behaviors for each, and the return type. It does not specify the exact structure of the JSON confirmation or address error cases, but for a simple formatting action this is a minor gap. Overall, an agent has enough context to call the tool correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must fully document the parameters. It does this well by explaining that workbook accepts a name or path, sheet is a worksheet name, and range_address is A1-style, with None defaults for each. This adds real meaning beyond the raw parameter names and defaults in the schema.

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

  Purpose5/5

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

  The description uses a specific verb-resource pair, 'Autofit column widths', and clearly defines the scope: a given range or the sheet's used range. This distinguishes the tool from formatting and range-editing siblings. The meaning is unambiguous and actionable.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when column widths need to be autofitted, and clarifies range behavior with defaults. However, it does not explicitly state when to choose this over alternatives like format_range, nor does it mention exclusions or prerequisites. Usage context 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.

• delete_commentA
  4.1/5.0
  Behavior4/5

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

  The description adds behavior beyond the destructiveHint annotation by noting the operation is conditional ('if any') and that it returns a JSON confirmation. This helps an agent understand the tool's effect even when no comment exists, though it does not specify the exact confirmation structure or error handling.

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

  Conciseness5/5

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

  The description is concise and well-structured, with labeled Args and Returns sections. Every sentence carries information without unnecessary fluff.

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

  Completeness4/5

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

  For a simple three-parameter tool, the description covers the necessary inputs and return type. The only gap is the lack of detail about the JSON confirmation structure and potential edge cases (e.g., error when no comment exists), but this is minor for such a straightforward operation.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by explaining each parameter (workbook, sheet, cell) including defaults, types, and an example for cell. This is essential and well done.

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

  Purpose5/5

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

  The description clearly states the action (delete), the resource (a comment on a specific cell), and the conditional nature ('if any'). This distinguishes it from siblings like add_comment and get_comments without ambiguity.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives, such as checking for an existing comment with get_comments first. There is no explicit when-to-use or when-not-to-use, and no mention of related tools or prerequisites.

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

• delete_rowsA
  4.1/5.0
  Behavior4/5

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

  The description adds value beyond the destructiveHint annotation by specifying that rows below are shifted up, effectively explaining the data manipulation effect. It also discloses the return type (JSON confirmation). While it doesn't mention irreversibility or performance implications, the core behavioral detail of shifting rows is genuinely useful and goes beyond the annotation's simple destructive flag.

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

  Conciseness5/5

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

  The description is a compact docstring that opens with a one-line summary, then lists parameters and return value in a clear, scannable format. Every sentence serves a purpose—no fluff or redundancy. The structure front-loads the core action and then provides necessary details, making it efficient for an agent to parse.

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

  Completeness4/5

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

  Given the simplicity of the operation and the presence of the destructiveHint annotation, the description covers all essential aspects: what it deletes, how it affects rows, parameter semantics, and return type. It lacks explicit notes on irreversible changes or edge cases (e.g., deleting all rows), but these are arguably covered by the annotation and the straightforward nature of the tool. Overall, it is sufficient for an agent to call the tool correctly.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates for each parameter: workbook, sheet, row_index (clearly marked as required and 1-based), and count (with its purpose). It also provides default behavior for workbook/sheet (None = active). This is a thorough explanation that the schema alone does not supply, making it highly informative for correct invocation.

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

  Purpose5/5

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

  The description clearly states the action (delete) on resource (rows) and the effect (shifting rows below up). It distinguishes from sibling tools like delete_columns and delete_worksheet by specifying rows, and mentions the ability to delete multiple rows via count. The verb and resource are specific, leaving no ambiguity about what the tool does.

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

  Usage Guidelines2/5

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

  The description does not provide any guidance on when to use this tool versus alternatives, such as clear_range or delete_worksheet. It lacks context about prerequisites (e.g., workbook must be open) or conditions that would make this tool the right choice. The absence of any usage or exclusive guidance means the agent receives no direction on selecting this over siblings.

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

• get_workbook_infoA
  4.1/5.0
  Behavior4/5

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

  With readOnlyHint=true, the safety profile is already known, and the description adds behavioral nuance: the default resolution to the active workbook of the first Excel instance and the inclusion of visibility in the returned data. It does not contradict the annotation.

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

  Conciseness4/5

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

  The description is short and organized with Args and Returns sections. The return list partially repeats the opening sentence, but the added visibility detail and default behavior make the structure worthwhile.

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

  Completeness5/5

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

  For a one-parameter read-only tool with no output schema, the description covers what the tool returns, how to specify the workbook, and what happens when workbook is omitted. Nothing else is required to call it correctly.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description fully compensates for the single workbook parameter by stating it is a name or path and explaining the None default. This is precisely the information an agent needs beyond the bare schema.

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

  Purpose5/5

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

  The description opens with a specific verb-resource pair and enumerates the exact payload: worksheet names, active sheet, and each sheet's used range. This makes its scope concrete and separates it from sibling tools like list_worksheets, which would only cover the first item.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to prefer this tool over list_worksheets, get_table_info, or get_range_values. It explains the workbook argument but not the selection context or exclusions.

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

• read_named_rangeA
  4.1/5.0
  Behavior4/5

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

  The description adds valuable behavior beyond annotations: it states the return format ('JSON with the value(s) as a 2D array') and clarifies the default for workbook (None = active workbook). Since readOnlyHint is already provided, the safety profile is covered, and these extra details are useful. It does not mention error conditions (e.g., missing name) but is otherwise solid.

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

  Conciseness5/5

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

  The description is two sentences followed by a compact Args/Returns listing. The core purpose is front-loaded, and every line either explains a parameter or the output. No waste or redundancy.

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

  Completeness4/5

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

  For a simple read tool, the description covers essentials: purpose, parameters, default behavior, and return format. It does not explicitly address error handling or alternatives, but these are not critical for a read-only operation. Slightly more context about when to use this vs get_range_values would have made it a 5, but it is largely complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries the full burden. It explicitly documents both parameters: workbook (name or path, None = active) and name (required). This adds meaning beyond the schema's raw types and defaults, and even clarifies that 'name' is logically required despite the schema not enforcing it.

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

  Purpose5/5

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

  The description states a clear action ('Read') and an unambiguous resource ('named range'), which distinguishes it from siblings like get_range_values (reads by cell address) and list_named_ranges (lists all names). The purpose is immediately obvious to an agent.

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

  Usage Guidelines2/5

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

  The description explains how to call the tool but not when to prefer it over alternatives. It does not mention that get_range_values is for cell addresses or that list_named_ranges is for enumeration. No explicit guidance on selection criteria or exclusion cases exists.

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

• remove_hyperlinkA
  4.1/5.0
  Behavior3/5

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

  With destructiveHint=true already declared, the description is not required to restate destructiveness. It adds the useful 'if any' qualifier suggesting a no-op when no hyperlink exists. However, it does not disclose whether only the hyperlink is removed (vs other formatting) or if the action is reversible.

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

  Conciseness5/5

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

  The description is efficient: a one-sentence purpose followed by a structured Args list and a Returns note. No fluff or repetition; the main action is front-loaded.

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

  Completeness4/5

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

  For a simple single-cell operation, the description adequately covers parameter semantics and return type. It lacks explicit error-handling or edge-case details, but given the tool's low complexity and the 'if any' qualifier, these are minor omissions.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates by explaining each parameter: workbook (None = active workbook), sheet (None = active sheet), and cell (A1-style single-cell reference with example). This adds meaningful semantics beyond the schema's type and default values.

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

  Purpose5/5

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

  The description states a specific verb ('Remove') and resource ('hyperlink from a cell'), clearly distinguishing it from siblings such as add_hyperlink and list_hyperlinks. The phrase 'if any' adds precision about scope, making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage when a hyperlink needs to be removed from a cell, and the 'if any' qualifier hints it is safe to call even without a hyperlink. However, it does not explicitly mention when to use this tool versus alternatives like list_hyperlinks or add_hyperlink, nor provide exclusions.

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

• remove_validationA
  4.1/5.0
  Behavior3/5

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

  The annotations declare destructiveHint: true, which the description does not contradict. The description adds minimal behavioral detail beyond that, such as the return of JSON confirmation, but does not describe side effects or irreversibility. It does clarify default behaviors for workbook and sheet, which is useful but not behavioral transparency per se.

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

  Conciseness5/5

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

  The description is concise and well-structured, with the action stated upfront followed by a clear args/returns format. Every sentence adds value without redundancy.

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

  Completeness4/5

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

  For a simple removal tool, the description covers the core essentials: what it does, parameters, and return type. However, it omits details like whether it only affects existing validation or what happens if no validation exists. Given the tool's simplicity and the presence of annotations, this is a minor gap.

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

  Parameters5/5

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

  The description provides meaningful explanations for all three parameters, including defaults and an example for range_address. Since the schema provides no descriptions (0% coverage), the description fully compensates, making parameter semantics clear.

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

  Purpose5/5

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

  The description clearly states the action (remove) and the target (data validation from a range). It is distinct from sibling tools like add_dropdown_validation and get_validation. The purpose is unambiguous.

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

  Usage Guidelines3/5

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

  The description does not explicitly mention when to use this tool versus alternatives like add_validation or clear_range. The usage is implied by the name and action, but there is no explicit guidance on selection criteria.

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

• rename_worksheetA
  4.1/5.0
  Behavior3/5

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

  Annotations are minimal (only title), so the description carries full burden. It discloses that renaming is a mutation and describes the return format, but it does not mention potential errors (e.g., duplicate names, missing sheets) or side effects. This is adequate but not rich.

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

  Conciseness5/5

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

  The description is structured with a clear main sentence, an Args section, and a Returns section. Every word earns its place, and the information is front-loaded with the core action.

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

  Completeness4/5

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

  For a simple rename tool without an output schema, the description covers the essentials: action, parameters, defaults, and return format. It does not describe failure cases, but that is a minor gap given the simplicity and the explicit open-workbook context.

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

  Parameters5/5

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

  The schema has 0% description coverage, so the description is essential. It clearly explains each parameter (workbook, name, new_name), including defaults (None = active) and marks new_name as required, fully compensating for the schema's lack of detail.

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

  Purpose5/5

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

  The description opens with 'Rename a worksheet in an open workbook,' a specific verb+resource that clearly distinguishes this tool from siblings like add_worksheet, delete_worksheet, and activate_worksheet. It leaves no ambiguity about what the tool does.

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

  Usage Guidelines3/5

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

  The description gives the prerequisite that the workbook must be open and provides default behavior for active elements, but it does not mention when to use this tool over alternatives or any exclusions. The use case is implied by the purpose, but explicit guidance is absent.

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

• add_number_validationA
  4.2/5.0
  Behavior3/5

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

  The description explains the core behavior and lists all condition types, which is helpful, but annotations are sparse (only a title). It does not disclose side effects such as whether existing validation on the range is overwritten, whether this is a write operation requiring save, or what happens to values already in the range.

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

  Conciseness5/5

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

  The description is structured efficiently: a one-sentence purpose followed by a compact Args list. Each parameter line adds practical meaning without redundancy, and the Returns line is minimal but useful since there is no output schema.

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

  Completeness5/5

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

  For a tool with 7 parameters, no output schema, and minimal annotations, the description covers all necessary invocation details. It defines parameter semantics, required values, condition options, and the return type, leaving no critical gaps for calling the tool correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates. It explains every parameter beyond the schema: workbook/sheet defaults, A1-style range_address, all allowed condition strings, value1 being required, value2 only for between/not_between, and decimal meaning 'whole numbers only'.

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

  Purpose5/5

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

  The description opens with a specific verb-resource statement: "Restrict a range to numbers matching a comparison." This clearly distinguishes it from sibling validation tools like add_dropdown_validation and from general range operations.

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

  Usage Guidelines3/5

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

  The description implies the tool's use case through its purpose: restricting cells to numeric input that satisfies a comparison. However, it never explicitly says when to use this tool over alternatives such as add_dropdown_validation, get_validation, or remove_validation.

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

• delete_columnsA
  4.2/5.0
  Behavior3/5

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

  The annotations already flag this as destructive (destructiveHint=true). The description adds useful context by stating that columns to the right shift left and that a JSON confirmation is returned, but it does not go further into irreversibility, formula/reference impact, or how deleted cell contents are handled.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core behavior before the Args section. Every sentence contributes meaning, and the parameter list is cleanly structured without unnecessary filler.

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

  Completeness4/5

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

  The tool is straightforward and the description covers behavior, parameters, and return value. It would be slightly more complete if it resolved the mismatch between the claimed required column parameter and the schema's optional flags, and if it warned about permanent data loss, though destructiveHint partially covers that.

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

  Parameters4/5

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

  With 0% schema description coverage, the description takes on the burden of explaining all parameters and does so well: workbook/sheet active defaults, column letters, and count. The only caveat is that 'column (required)' conflicts with the schema's lack of a required field, which could cause slight ambiguity.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Delete one or more columns, shifting columns to their right left.' This clearly distinguishes the tool from siblings like delete_rows, delete_worksheet, and delete_table by naming columns as the exact target.

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

  Usage Guidelines4/5

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

  The description clearly establishes when to use this tool: when deleting columns from a worksheet. It does not explicitly name alternatives or exclusions, but the column-specific language and count parameter make the intended use obvious among the many sibling tools.

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

• delete_tableA
  4.2/5.0
  Behavior4/5

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

  The annotation already marks the operation destructive, and the description adds valuable nuance: only the table definition is removed while the underlying cell data is preserved. It also mentions a JSON confirmation return. This goes beyond the annotation without contradicting it.

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

  Conciseness5/5

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

  The core behavior is front-loaded in a single sentence, followed by a compact Args section and a short Returns note. Every line earns its place; there is no filler or redundancy.

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

  Completeness4/5

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

  For a three-parameter destructive tool, the description covers the operation, parameter meanings, defaults, and return type. It does not specify the exact confirmation payload or error behavior, but those gaps are minor given the simple scope and the destructiveHint annotation.

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

  Parameters4/5

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

  With 0% schema coverage, the description fully compensates by explaining all three parameters, including the active-workbook and active-sheet defaults and which table is removed. One minor flaw: it says table_name is required while the schema has no required parameters, giving an agent conflicting signals if it checks both.

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

  Purpose5/5

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

  The description uses a specific verb ('Remove') and resource ('a table's definition') and adds the key nuance 'keeping the underlying cell data'. This clearly distinguishes it from sibling tools like delete_worksheet or clear_range, and it is not a tautology of the tool name.

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

  Usage Guidelines3/5

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

  The first sentence gives clear operational context: use this when you want to remove a table definition but keep its cell data. However, it does not explicitly state when not to use it or name alternatives such as delete_worksheet, so the agent must infer routing from the operation semantics.

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

• get_commentsA
  4.2/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals this is a safe, non-mutating operation, so the description does not need to over-explain. It adds context by stating it 'lists all comments' and returns cell addresses and text, which helps understand the output. No contradictions with annotations exist.

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

  Conciseness5/5

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

  The description is extremely concise and front-loaded, with the core action stated in the first sentence. The Args and Returns sections are minimal and efficient, containing no filler. Every sentence earns its place, making it easy to parse quickly.

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

  Completeness4/5

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

  Given the simplicity of the tool and the readOnlyHint annotation, the description covers the essentials: what it does, how to specify scope, and what it returns. It does not mention pagination or edge cases, but for a list operation with JSON output, this is sufficient. The absence of an output schema is mitigated by the description's mention of the return structure.

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

  Parameters4/5

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

  Schema description coverage is 0%, leaving parameters undocumented in the schema. The description compensates by explaining each parameter: 'workbook: Workbook name or path (None = active workbook)' and 'sheet: Worksheet name (None = active sheet)'. This adds actionable meaning, clarifying defaults and usage, which is essential for correct invocation.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'List all comments on a worksheet.' This clearly distinguishes it from sibling tools like add_comment and delete_comment by focusing on the read-only listing operation. It also specifies the return format (JSON with cell address and text), making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  While the description does not explicitly state 'use this when you need to see comments', the clear phrasing and the presence of sibling add/delete comment tools implicitly provide that context. It also explains that workbook and sheet are optional with active defaults (None = active), which guides usage. No exclusions are needed given the simple read operation.

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

• list_worksheetsA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context: names are returned 'in tab order' and the active worksheet is identified. It does not contradict the annotations.

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

  Conciseness5/5

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

  The description is compact and well-organized with Args and Returns sections. Every sentence provides necessary information, and the core purpose is stated first.

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

  Completeness4/5

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

  For a simple read-only tool with one optional parameter and no output schema, the description covers purpose, parameter semantics, and return value shape. It could be slightly more precise about the exact JSON keys, but it is sufficient for correct invocation.

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

  Parameters4/5

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

  Schema description coverage is 0%, but the description compensates by explaining the workbook parameter as 'Workbook name or path (None = active workbook).' This adds meaning beyond the raw schema, clarifying optionality and default behavior.

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

  Purpose5/5

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

  The description clearly states the action: 'List worksheet names, in tab order, for an open workbook.' It names the specific resource (worksheets) and the output (sheet names and active sheet), which distinguishes it from siblings like list_open_workbooks or add_worksheet.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool: when you need worksheet names for an open workbook. However, it does not explicitly contrast it with alternatives such as get_workbook_info or list_open_workbooks, or state when not to use it.

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

• update_named_rangeA
  4.2/5.0
  Behavior3/5

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

  Annotations are minimal (only a title), so the description carries full behavioral disclosure. It indicates mutation via 'Change' and states the return type, but it does not disclose error behavior (e.g., what happens if the named range does not exist), prerequisites, or side effects. It implies the range must already exist, but that is not explicit.

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

  Conciseness5/5

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

  The description is well-structured: a single-line action, a list of arguments with brief explanations, and a returns line. It is concise with no fluff and front-loads the core purpose. The parameter list is clear and the return type is stated.

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

  Completeness4/5

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

  For a straightforward modification tool, the description covers the essential aspects: purpose, parameters, and return type. It lacks details on error conditions (e.g., missing named range, invalid address) and prerequisites, but the simplicity of the operation mitigates the need. The ambiguity around required parameters is a notable gap.

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

  Parameters4/5

  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 explains each parameter with definitions, defaults (workbook/sheet None), and an example for range_address. However, there is an inconsistency: the description marks 'name' as required while the schema marks it optional with a default of null. Also, range_address has a default 'A1' in the schema but the description does not mention that default. This reduces clarity.

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

  Purpose5/5

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

  The description clearly states the verb 'Change' and the resource 'an existing named range' and what changes (its reference). It distinguishes itself from siblings like create_named_range, delete_named_range, and read_named_range by focusing on updating the definition rather than creating, deleting, or reading values.

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

  Usage Guidelines4/5

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

  The description does not explicitly say when to use this tool versus alternatives, but it implies usage by saying 'existing named range to update', which suggests it is for modifying existing ranges rather than creating new ones. The distinction from write_named_range (which writes values to the referenced range) is implied but not spelled out, so there is some room for interpretation.

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

• add_hyperlinkA
  4.3/5.0
  Behavior3/5

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

  The description provides some behavioral detail: text_to_display defaults to the address itself, internal references use a '#' prefix, and a JSON confirmation is returned. However, with no annotations, the description carries the full burden and fails to disclose important side effects such as whether an existing cell value or hyperlink is overwritten, or error behavior when the address is invalid. Partial transparency with gaps around mutation consequences.

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

  Conciseness5/5

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

  The description leads with a one-sentence purpose and then uses a clean Args list followed by a Returns line. Every line communicates a parameter or return behavior; there is no filler or redundancy. The structure is highly scannable and efficient.

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

  Completeness4/5

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

  For a tool with six parameters and no output schema, the description is largely complete: all parameters have defaults and examples, and the return value is described as JSON confirmation. Gaps remain around side-effect behavior and alternative tool usage, but those are relatively minor for invoking the tool successfully.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: workbook and sheet default to active objects, cell is A1-style single-cell, address includes URL and internal '#' examples, text_to_display defaults to the address, and screen_tip is defined. This fully compensates for the missing schema-level descriptions.

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

  Purpose5/5

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

  The description clearly states the action ('Add a hyperlink') and target resource ('to a cell'). The verb 'Add' uniquely distinguishes it from the sibling tools remove_hyperlink and list_hyperlinks, making the operation unambiguous even without explicit differentiation.

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

  Usage Guidelines4/5

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

  The description makes the usage context obvious: use this when a hyperlink should be added to a cell. It includes helpful default context ('None = active workbook/sheet') but does not mention alternatives like list_hyperlinks or remove_hyperlink, nor any conditions for avoiding this tool. Clear context, but no explicit exclusions or alternatives.

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

• create_named_rangeA
  4.3/5.0
  Behavior4/5

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

  Annotations only provide a title, so the description carries the behavioral burden. It discloses name syntax constraints, None-defaults for workbook and sheet, A1-style addressing, and the JSON confirmation return value. It does not mention duplicate-name behavior or permissions, but the core behavioral contract is clear.

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

  Conciseness5/5

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

  The description is compact and well-structured with Args and Returns sections. The first sentence states the purpose, and every subsequent line adds meaningful parameter or return-value detail without redundancy.

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

  Completeness4/5

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

  For a four-parameter tool with no output schema and no annotation safety hints, it covers inputs, defaults, constraints, and return value adequately. It lacks edge-case behavior such as what happens when the named range already exists, but an agent has enough detail to call it correctly in typical cases.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates by explaining all four parameters, including defaults, constraints, and an example for range_address. It also clarifies that name is required despite the schema lacking a required list.

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

  Purpose5/5

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

  States 'Create a new named range' with a specific verb and resource, and 'new' distinguishes it from sibling update/delete/read/write named range operations. The scope is immediately clear.

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

  Usage Guidelines3/5

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

  The description implies this tool is for creating named ranges, but it does not explicitly state when to use it over siblings like update_named_range or delete_named_range. No alternative conditions or exclusions are given, leaving usage largely to inference from the word 'Create'.

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

• create_tableA
  4.3/5.0
  Behavior3/5

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

  Annotations carry no read-only/destructive hints, so the description must carry more weight. It discloses useful defaults (active workbook/sheet, Excel default table name) and the JSON return shape, but it does not address what happens on table-name conflicts, whether existing range data is altered, or other side effects. This is an adequate but not fully transparent disclosure for a mutation.

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

  Conciseness5/5

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

  The description is compact and front-loaded with a one-sentence summary, followed by a clear Args list and a Returns line. There is no filler or repetition of schema types.

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

  Completeness4/5

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

  For a five-parameter tool with no output schema and minimal annotations, the description covers inputs and return value adequately. It lacks edge-behavior context such as name-conflict errors, but an agent has enough information to invoke the tool successfully in the normal case.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description documents all five parameters with meaningful semantics: workbook/sheet fallback behavior, A1-style range addressing, table naming defaults, and the header-row flag. It fully compensates for the schema's lack of parameter descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Create an Excel Table from a range.' This states exactly what the tool does and its scope, and the phrase 'from a range' distinguishes it from sibling table operations like list_tables or delete_table.

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

  Usage Guidelines4/5

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

  The description gives clear context: call this tool when an Excel Table needs to be created over an A1 range, with workbook/sheet defaults if not provided. It does not explicitly name alternatives or exclusion cases, but the operation is specific enough that an agent can identify when it applies.

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

• delete_worksheetA
  4.3/5.0
  Behavior4/5

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

  The destructiveHint annotation already signals mutation, and the description adds meaningful behavioral detail: Excel will refuse to delete a workbook's only remaining visible sheet, and the tool returns a JSON confirmation. This goes beyond annotation coverage, though it does not discuss reversibility or error cases.

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

  Conciseness5/5

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

  The description is compact and well organized with Args and Returns sections. It front-loads the purpose and includes only essential behavioral caveats, with no redundant fluff.

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

  Completeness4/5

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

  For a simple destructive two-parameter tool with no output schema, the description covers parameter semantics, the active-workbook default, the required sheet, and the important last-visible-sheet refusal. The return value is only described as 'JSON confirmation' without a shape, and error behavior is not detailed, but these are minor gaps for this tool.

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

  Parameters5/5

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

  The input schema provides only parameter names and defaults, but the description fully explains both parameters: workbook is a name or path with None meaning the active workbook, and name is the required sheet to delete. This compensates strongly for the 0% schema description coverage.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Delete a worksheet from an open workbook.' This clearly distinguishes it from sibling deletion tools like delete_table, delete_chart, delete_columns, and delete_named_range, which target different object types.

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

  Usage Guidelines3/5

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

  The description gives context (operates on an open workbook, targets a specified sheet) and implicitly indicates when to use this tool. However, it does not explicitly contrast it with alternatives or state when not to use it, such as preferring delete_table for table structures or clear_range for cell contents.

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

• get_table_dataA
  4.3/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description adds meaningful behavioral details: it excludes the header, returns a 2D array, and specifies a JSON response with column names and rows. It does not contradict the read-only nature.

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

  Conciseness5/5

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

  The description is concise and well-structured: a clear purpose statement followed by structured Args and Returns sections. It is front-loaded and contains no unnecessary prose.

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

  Completeness4/5

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

  The description covers the function, parameters, and return format well. However, there is a minor discrepancy: it labels table_name as required while the schema gives it a default of null, which could confuse an agent. Otherwise it is complete for a read operation.

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

  Parameters5/5

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

  The schema provides no descriptions for parameters (0% coverage), so the description fully compensates by explaining each parameter (workbook, sheet, table_name) including defaults and the required nature of table_name. This is essential guidance.

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

  Purpose5/5

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

  The description states a clear action (read data rows from a table), identifies the resource (table), and specifies the output format (2D array excluding header). It clearly distinguishes from sibling tools like get_range_values by targeting table-specific data.

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

  Usage Guidelines3/5

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

  The description implies usage for reading table rows but does not explicitly mention when to use this tool versus alternatives such as get_range_values or get_table_info. There is no guidance on exclusions or alternative selection.

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

• get_validationA
  4.3/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses the return format (JSON with validation type/operator/formulas, or has_validation: false if none exists) and parameter defaults (active workbook/sheet). This provides useful behavioral context without contradicting annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-line purpose, then Args and Returns sections. It wastes no words and front-loads the core action before diving into parameter details.

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

  Completeness4/5

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

  Given the lack of an output schema, the description adequately covers return values and defaults. It does not mention edge cases like invalid cell references or workbook errors, but for a simple read operation, the provided information is sufficient 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.

  Parameters5/5

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

  The schema has 0% description coverage, so the description fully compensates by explaining each parameter: workbook/path, sheet name, and A1-style cell reference, including default behavior for workbook and sheet. This is essential for correct invocation.

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

  Purpose5/5

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

  The description clearly states the verb 'read' and the resource 'data validation rule applied to a cell', distinguishing it from sibling add/remove validation tools. It also clarifies the 'if any' condition, making the intent unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for reading validation rules but does not explicitly state when to use this tool versus alternatives like add_dropdown_validation or remove_validation. It lacks explicit when-not conditions or references to alternative tools, so the guidance is only implicit.

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

• insert_columnsA
  4.3/5.0
  Behavior3/5

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

  The description discloses the core mutation behavior (inserting blank columns and shifting existing columns right) and states the return type as JSON confirmation. However, annotations provide no read-only or destructive hints, and the description does not mention potential side effects like formula adjustments, formatting shifts, or permission requirements. It carries the behavioral burden adequately but not completely.

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

  Conciseness5/5

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

  The description is front-loaded with a one-sentence purpose, followed by a compact Args list and a Returns line. Every element earns its place, and there is no redundant or filler text.

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

  Completeness4/5

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

  For a simple mutation tool with no output schema and sparse annotations, the description covers all parameters, the optional workbook/sheet behavior, required column semantics, and the return type. It could be more complete by noting the count default or describing the exact JSON confirmation shape, but it is sufficient for correct invocation in most cases.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates fully by explaining every parameter: workbook, sheet, column, and count. It also clarifies that column is required and gives a concrete example ('B'), adding meaning far beyond the bare schema.

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

  Purpose5/5

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

  The description states a specific action ('insert one or more blank columns') and the direct effect ('shifting existing columns right'). It clearly distinguishes this from sibling tools like insert_rows and delete_columns by naming the column operation and its directional impact.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: inserting blank columns before a specified column letter, with optional workbook/sheet scope. It does not explicitly name alternatives or exclusions, so it misses the top score, but the usage context is unambiguous.

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

• insert_rowsA
  4.3/5.0
  Behavior3/5

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

  The description discloses the key side effect (shifting rows down) and the requirement of row_index, but with no safety annotations, it omits other behavioral aspects such as potential impact on formulas, formatting, or undoability. It provides minimal but useful transparency.

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

  Conciseness5/5

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

  The description is well-structured with a front-loaded summary, a clean Args list, and a Returns line. Every sentence is purposeful, and the format makes it easy to parse.

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

  Completeness4/5

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

  The description covers the action, all parameters, and the expected return value, making it sufficient for a simple insertion tool. Minor gaps like error handling or behavior when workbook/sheet is missing are acceptable, but a note on preservation of formatting or formulas would have made it more complete.

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

  Parameters5/5

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

  The schema has no parameter descriptions (0% coverage), but the description fully compensates by explaining each parameter: workbook and sheet defaults, row_index as 1-based and required, and count as how many rows. This adds substantial meaning beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the specific action: 'Insert one or more blank rows, shifting existing rows down.' This distinguishes it from sibling tools like delete_rows and insert_columns, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description clearly indicates when to use the tool (to insert rows), but it does not explicitly mention alternatives or when not to use it. The context is sufficient for an agent to infer its use case, but lacks explicit exclusion guidance.

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

• save_workbookA
  4.3/5.0
  Behavior3/5

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

  Annotations contain only a title, so the description carries the burden. It discloses that the operation overwrites in place ('equivalent to pressing Ctrl+S') and returns a 'JSON confirmation'. However, it does not explicitly state that this is a write operation or mention failure modes, permissions, or consequences of overwriting.

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

  Conciseness5/5

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

  The description is compact with an opening sentence that immediately states the core action, followed by a clearly formatted Args section and Returns section. Every sentence adds value, with no repetition or unnecessary detail.

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

  Completeness4/5

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

  For a low-complexity tool with one optional parameter and no output schema, the description covers the action, parameter semantics, and return value. The main missing piece is explicit error-handling details (e.g., what happens if the workbook is not found), but this is not essential for correct invocation.

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

  Parameters5/5

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

  The schema provides no description for the 'workbook' parameter, but the description fully explains its meaning ('Workbook name or path') and the default behavior ('None = the active workbook of the first Excel instance found'). This completely compensates for the 0% schema coverage.

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

  Purpose5/5

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

  The description states a clear action ('Save') and resource ('an open workbook') with explicit scope ('in place') and a relatable analogy ('equivalent to pressing Ctrl+S'). This uniquely distinguishes it from all sibling tools, none of which perform a save operation.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: saving an open workbook, with a default behavior for the active workbook of the first Excel instance. It doesn't mention alternatives since no sibling performs saving, so exclusions are unnecessary. The note about the active workbook gives practical usage guidance.

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

• set_cell_formulaA
  4.3/5.0
  Behavior3/5

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

  No behavioral annotations exist, so the description carries the burden. It does disclose that the tool sets a formula/literal and returns the resulting calculated value, but it does not mention overwriting existing cell contents, recalculation side effects, or any destructive implications of setting a cell.

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

  Conciseness5/5

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

  The description is compact, front-loaded with a clear one-sentence summary, followed by a structured Args block and Returns line. Every sentence or bullet earns its place with no fluff.

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

  Completeness4/5

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

  For a 4-parameter tool with no output schema, the description covers all parameters and the return value, including default active workbook/sheet behavior. It lacks edge-case detail like invalid formulas or error handling, but is otherwise complete for a simple setter.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates by explaining every parameter: workbook/sheet defaults, the A1-style cell format, and the '=' prefix requirement for formulas with a literal alternative. It adds all missing semantic value.

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

  Purpose5/5

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

  The description states 'Set a formula (or literal value) on a single cell,' which uses a specific verb, resource, and scope. It clearly distinguishes itself from siblings like set_range_values (which targets ranges) and get_range_formulas (which reads formulas).

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

  Usage Guidelines4/5

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

  The description gives clear usage context by explaining optional workbook/sheet defaults, A1-style cell references, and formula formatting. It does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of a 5.

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

• set_range_valuesA
  4.3/5.0
  Behavior3/5

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

  Annotations only include a title, so the description carries the full behavioral burden. It discloses the mutation ('write') and how values are anchored (flat list as one row, list of lists as a block) plus the return value. However, it does not mention overwrite behavior, whether existing data outside the written block is preserved, or error behavior for invalid workbook/sheet names. These are meaningful gaps.

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

  Conciseness5/5

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

  The description is a single purpose sentence followed by a compact Args list and a Returns line. Every sentence contributes necessary information, with no filler. The structure is front-loaded and easy to scan.

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

  Completeness4/5

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

  For a tool with no output schema and no annotations, the description covers the core invocation concerns: optional workbook/sheet, values shape, anchoring, and return. It is missing edge-case details such as error handling, full-range addresses, and whether existing cells are overwritten. Given the minimal structured metadata, these additions would push it to a 5.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates. It explains each parameter individually: workbook/sheet with None defaults, range_address as a top-left cell with examples, and values with three acceptable formats and their layout semantics. This is rich and precise, leaving no ambiguity about the inputs.

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

  Purpose5/5

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

  The description opens with 'Write values into a cell or range in an open workbook,' which is a specific verb plus a clear resource. This distinguishes it from siblings like get_range_values (reads) and set_cell_formula (formulas). The scope is immediately clear and non-tautological.

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

  Usage Guidelines4/5

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

  The context is explicit: this tool is for writing values, not reading or formatting. An agent can infer when to use it from the verb and resource. However, it does not name alternatives or give when-not-to-use conditions, so it stops short of a 5.

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

• sort_rangeA
  4.3/5.0
  Behavior4/5

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

  The destructiveHint annotation already signals that sorting mutates state, and the description adds useful behavioral context: header rows are excluded from sorting and kept in place, key_column uses a 1-based offset, and workbook/sheet default to active objects. It does not explicitly state that the range is reordered in place, but the annotation covers the core safety signal.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-sentence purpose, a scannable argument list, and a return line. Every sentence adds necessary information with no filler.

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

  Completeness4/5

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

  Given the absence of an output schema, the description appropriately states that the return is a JSON confirmation, and it documents all parameters. It could be slightly more explicit about in-place mutation and that only one key column is supported, but the annotation and the word 'sort' make these largely inferable.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries the full burden of documenting parameters. It explains all six parameters clearly, including defaults, an example range address, the 1-based key column offset, and header behavior. This fully compensates for the empty schema descriptions.

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

  Purpose5/5

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

  The description opens with 'Sort a range by one column' — a specific verb, resource, and scope. It is easily distinguishable from sibling range tools like get_range_values, set_range_values, and format_range.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool through its purpose and parameter documentation, but it never explicitly states when to prefer sort_range over alternatives or mentions limitations such as supporting only a single sort key. No exclusion or alternative guidance is provided.

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

• add_commentA
  4.4/5.0
  Behavior4/5

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

  Annotations provide only a title, so the description carries the behavioral disclosure burden. It explicitly warns that existing comments are replaced and defines the author default (env var or 'Author'). It also states the return type. This is strong transparency for a simple mutation tool, though it omits potential error cases or permission requirements.

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

  Conciseness5/5

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

  The description is well-structured with a brief purpose line, a behavioral note, and a clean Args list. Every sentence adds value, and the formatting is scannable. No fluff or repetition.

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

  Completeness5/5

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

  Given five parameters, no output schema, and minimal annotations, the description covers all necessary information: parameter meanings, defaults, replacement behavior, and return type. Nothing essential is missing for a correct invocation.

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

  Parameters5/5

  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 fully. It explains all five parameters with meanings, defaults, and examples (e.g., 'A1-style single-cell reference'). It also clarifies that text is effectively required, overriding the schema's default of empty string. This is exactly the level of detail an agent needs.

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

  Purpose5/5

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

  The description clearly states the action: 'Add a comment (note) to a cell in an open workbook.' It also notes that it replaces any existing comment, distinguishing it from get_comments and delete_comment. The verb and resource are specific, and the replacement behavior adds a differentiating detail.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (when you need to attach a comment to a cell) but does not explicitly compare with alternatives like get_comments or delete_comment. There is no 'use X instead' guidance, so the agent must infer the exact selection criteria from the tool name and purpose.

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

• create_chartA
  4.4/5.0
  Behavior3/5

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

  Annotations provide no readOnly or destructive hints, so the description carries the burden. It does disclose the output format (JSON with chart name) and parameter defaults (e.g., 'None = active workbook/sheet'), which is helpful. However, it does not discuss side effects such as whether an existing chart with the same name is overwritten, whether the sheet is made active, or any prerequisites like the range needing to be valid. This is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is well-structured with a one-line summary, a clear Args section listing each parameter, and a Returns section. There is no redundancy or fluff—each line provides essential information. It is front-loaded with the core purpose.

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

  Completeness5/5

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

  For a 10-parameter tool with no output schema, the description covers everything needed for correct invocation: all parameters are defined, defaults are stated, chart types are enumerated, and the return value is described. It is sufficiently complete for an agent to call the tool correctly.

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

  Parameters5/5

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

  The schema has 0% description coverage, so the description fully compensates by documenting all 10 parameters. It explains each parameter with defaults, examples (e.g., range_address 'A1:C10', chart_type enum list), and positional arguments. This adds significant meaning beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the action ('Create a chart from a range') with a specific resource (chart) and the source (range). It distinguishes itself from sibling chart tools like set_chart_type or list_charts by focusing on creation. The return value is also specified, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description gives clear context that this tool is for creating new charts from a data range, and the parameters (workbook, sheet, range_address, chart_type) make it obvious when it applies. It does not explicitly name alternatives, but the purpose is distinct enough that an agent would naturally use this for chart creation and other tools for modification or listing. This is 'clear context, no exclusions'.

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

• format_rangeA
  4.4/5.0
  Behavior4/5

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

  The description adds meaningful behavioral details beyond the sparse annotations: only explicitly set arguments are changed, everything else is preserved, and a JSON confirmation is returned. It also documents how 'None' resolves to the active workbook/sheet and gives formatting syntax examples. It falls short of covering error behavior or side effects, but it carries the transparency burden well.

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

  Conciseness5/5

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

  The description is front-loaded with the core behavior, then terse Args entries, each contributing concrete value. The return line is minimal and useful. Despite covering 13 parameters, it remains readable and free of filler.

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

  Completeness5/5

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

  For a 13-parameter tool with no output schema and no meaningful annotations, the description covers all inputs, the selective-application behavior, the address format, and the return type. This is enough for an agent to invoke the tool correctly without further inference.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must carry the full parameter documentation burden. It does so comprehensively: every parameter is listed with its meaning, expected value type, and relevant examples such as 'FF0000', '$#,##0.00', and horizontal alignment options. This exceeds what the raw schema provides.

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

  Purpose5/5

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

  The description opens with a precise verb-resource pair: 'Apply font, fill, number-format, and alignment to a cell or range.' This clearly distinguishes it from siblings like set_range_values, clear_range, and sort_range, which serve different purposes.

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

  Usage Guidelines3/5

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

  The description clearly conveys that this tool is for formatting a range, but it does not explicitly state when to prefer it over alternatives or when not to use it. The usage context is implied by the formatting-specific language, but no exclusions or alternative routing are provided.

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

• get_range_formulasA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description adds value by explaining A1-style formula formatting, fallback to literal values for non-formula cells, and the JSON 2D array return shape. These details go beyond the read-only annotation without contradicting it.

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

  Conciseness5/5

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

  Front-loaded with the core purpose, then concise, well-structured Args and Returns sections. No redundant sentences; every line adds necessary context.

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

  Completeness5/5

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

  For a read-only tool with three optional parameters and no output schema, the description fully covers param meanings, default behaviors, and return format. Nothing essential for calling it correctly is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates fully with an Args section explaining each parameter, including defaults (None = active workbook/sheet) and format examples (range_address 'A1' or 'A1:C10'). This is exactly the meaning an agent needs beyond bare parameter names.

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

  Purpose5/5

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

  The description begins with 'Read formulas from a cell or range', which states a specific verb and resource. The additional note that non-formula cells return literal values further clarifies its scope, distinguishing it from value-reading siblings like get_range_values.

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

  Usage Guidelines3/5

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

  Usage is implied rather than explicit: reading formulas vs. values. No direct mention of when to use this tool over alternatives like get_range_values, nor any exclusions or prerequisites. The intent is clear but the guidance relies on inference.

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

• list_hyperlinksA
  4.4/5.0
  Behavior4/5

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

  The annotations include readOnlyHint=true, but the description adds valuable context beyond that: it specifies the return format (JSON with cell, address, display text) and explains default behavior for workbook and sheet. This helps the agent understand what to expect without contradicting the annotations.

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

  Conciseness5/5

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

  The description is concise, front-loads the purpose in the first sentence, and then provides essential parameter and return information without any fluff. Every sentence adds value.

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

  Completeness5/5

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

  The description is complete for a simple read-only list tool. It explains what is returned, the parameter defaults, and the scope. Given the annotations already indicate read-only, there are no missing pieces an agent would need to call this tool correctly.

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

  Parameters5/5

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

  The input schema has zero description coverage, so the description fully compensates by explaining each parameter: workbook is a name or path, with None meaning active workbook, and sheet similarly defaults to active sheet. This adds essential semantics that the schema alone lacks.

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

  Purpose5/5

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

  The description clearly states the action: 'List all hyperlinks on a worksheet.' This is specific about the verb (list) and resource (hyperlinks on a worksheet), and naturally distinguishes from sibling tools like add_hyperlink and remove_hyperlink. The scope is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage (when you need to see hyperlinks), but it does not explicitly mention alternatives or when not to use it. There is no guidance on choosing this over related tools, but the defaults for workbook and sheet are clarified. The usage context 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.

• write_named_rangeA
  4.4/5.0
  Behavior3/5

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

  Annotations only contain a title, so the description must carry the full behavioral burden. It does disclose key traits: only the top-left cell is set, and returns a JSON confirmation. However, it omits other important behavioral details such as whether the named range must already exist, whether it overwrites existing values, and how errors are surfaced. Given no readOnlyHint or destructiveHint annotations, this is a moderate gap.

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

  Conciseness5/5

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

  The description is tightly structured: a clear opening statement, one critical caveat with routing to a sibling, a compact Args list, and a Returns line. No filler or repetition; every sentence adds distinct information.

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

  Completeness4/5

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

  For a relatively simple write tool with no output schema, the description covers the core behavior, parameter semantics, and return type. It also differentiates from the closest sibling. It is slightly incomplete because it doesn't state whether the range must pre-exist or what happens on failure, but for a straightforward mutation this is a minor omission.

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

  Parameters4/5

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

  The schema provides zero descriptions for its three parameters, yet the description's Args section explains each: workbook (with None meaning active workbook), name (required), and value (required). It also clarifies that name and value are required despite the schema suggesting defaults. This meaningfully compensates for 0% schema coverage, though the explanations remain brief and lack type details or constraints.

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

  Purpose5/5

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

  The first sentence, 'Write a single value into a named range's top-left cell,' clearly identifies the action (write), the resource (named range), and the specific location (top-left cell). This precisely differentiates it from siblings like set_range_values (block writes) and read_named_range (read-only).

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

  Usage Guidelines5/5

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

  The description explicitly states when to use an alternative: 'For multi-cell named ranges, only the top-left cell is set — use set_range_values with the range's address for block writes.' It also marks name and value as required in the Args section, giving clear usage prerequisites. No ambiguity remains about when to choose this tool over set_range_values.

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

• list_open_workbooksA
  4.5/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already signals a read-only operation, and the description adds useful behavioral context by specifying the return payload: a JSON list including workbook name, full path, save state, and owning Hwnd. This goes beyond the annotation to describe what the agent will receive, without contradicting the read-only hint.

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

  Conciseness5/5

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

  The description is two short sentences: the first states the action and scope, the second outlines the return fields. It is front-loaded with the core purpose and contains zero filler. Every sentence earns its place.

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

  Completeness5/5

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

  For a tool with no parameters and a readOnlyHint, the description is complete: it tells what it does, what it returns, and the scope. No output schema is provided, but the description lists the return fields explicitly. Nothing an agent needs to invoke it correctly is missing.

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

  Parameters4/5

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

  With zero parameters, the input schema carries no semantic burden. The description implicitly defines the operation as parameterless 'list all open workbooks,' which is sufficient. The baseline for 0-parameter tools is 4, and the description meets that by making the tool's behavior self-evident.

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

  Purpose5/5

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

  The description states a specific verb ('List') and a specific resource ('all workbooks currently open') with a clear scope ('across every running Excel instance'). It distinguishes itself from siblings like get_workbook_info, which likely targets a single workbook, by explicitly covering all workbooks and all instances.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use it: when you want to enumerate all open workbooks across all Excel instances. It does not explicitly mention alternatives or exclusions, but the scope statement makes it clear this is the go-to for a global listing. A 4 is appropriate given the simplicity and the absence of parameter choices that might create ambiguity.

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

• add_conditional_format_ruleA
  4.6/5.0
  Behavior4/5

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

  Annotations provide no safety hints, so the description carries the behavioral burden. It clearly indicates a mutating 'add' operation, describes the return payload (new rule's index), and reveals the ordering behavior ('rules apply in index order'). It could state explicitly that existing rules are preserved, but the add semantics effectively imply non-destructive appending.

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

  Conciseness5/5

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

  The description is a well-structured docstring with a clear purpose sentence, an Args block, and a Returns section. It is somewhat long, but every parameter earns its place given the absence of schema descriptions, and the structure makes information easy to scan.

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

  Completeness5/5

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

  For a complex 9-parameter tool with no output schema and no annotations, the description is remarkably complete. It explains each parameter, the condition enum, parameter dependencies, and the return value, including the important index-order behavior. Nothing critical is missing for an agent to invoke it correctly.

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

  Parameters5/5

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

  The input schema has 0% parameter descriptions, so the description must compensate. It fully documents all nine parameters, enumerates valid condition values, marks value1 as required, explains value2's conditional requirement, and provides a range format example. This goes well beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb ('Add') and a clearly defined resource ('cell-value conditional formatting rule') scoped to a range. This distinguishes it from sibling tools like add_color_scale, list_conditional_format_rules, and clear_conditional_format_rules.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is the tool for adding cell-value conditional formatting rules based on comparison conditions. It does not explicitly name alternatives or exclusions, but the condition list and the 'cell-value' qualifier make the intended use obvious enough for an agent to select it correctly.

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

• clear_rangeA
  4.6/5.0
  Behavior4/5

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

  The destructiveHint annotation already signals risk, and the description adds meaningful behavioral detail beyond it: clear_formatting chooses between Range.ClearContents and Range.Clear, revealing that formatting may also be reset. It also notes the return value is JSON confirmation, which is helpful since no output schema exists.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the primary action. The Args block is minimal but complete, and the Returns line adds necessary confirmation about the response format. There is no filler or redundant restatement.

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

  Completeness5/5

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

  For a straightforward destructive tool with four optional parameters and no output schema, the description covers the essential inputs, the formatting behavior, and the return type. Combined with destructiveHint, it gives an agent enough information to invoke and understand the tool safely.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must carry parameter meaning on its own. It does: workbook/sheet active defaults are explained, range_address is given with an A1-style example, and clear_formatting is described in terms of what gets reset. All four parameters are effectively documented.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Clear cell contents from a range'. This immediately distinguishes it from sibling tools like delete_rows, delete_columns, and clear_conditional_format_rules, since it targets only a range's contents rather than structural changes.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: whenever cell contents in a range need clearing. It does not explicitly name alternatives or exclusions, but the phrase 'cell contents from a range' provides enough context to differentiate it from destructive row/column deletion and conditional-format clearing.

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

• find_replaceA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true, so the description adds the return format (JSON of sheets with replacements) and clarifies scoping behavior. It does not mention that cell contents are overwritten, but the destructive annotation covers that. The description adds value beyond annotations by detailing return information.

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

  Conciseness5/5

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

  The description is well-structured with a purpose line, a bullet-style Args section, and a Returns line. Each sentence earns its place, and the most important info (purpose) is front-loaded. No unnecessary filler.

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

  Completeness5/5

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

  For a tool with 6 parameters and no output schema, the description provides all necessary operational details: defaults, required parameter (find_text is 'required' per text, though schema shows default '', but the description clarifies), and return value. Together with the destructiveHint annotation, an agent has enough to call it correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It provides a one-line explanation for each of the six parameters, clarifying types and semantics (e.g., 'match_case: Case-sensitive match', 'whole_cell: Match the entire cell contents'). This fully compensates for the schema's lack of descriptions.

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

  Purpose5/5

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

  The description states a clear verb and resource: 'Find and replace text in an open workbook.' It also provides a concise summary that distinguishes it from sibling operations (none of which perform find/replace). The purpose is immediately obvious.

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

  Usage Guidelines4/5

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

  It provides clear context on how the tool behaves by default ('None = active workbook', 'None = every sheet'), which helps an agent decide scope. There are no direct alternatives among siblings, so explicit exclusions are unnecessary; the defaults and parameter explanations imply usage.

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

• get_merge_infoA
  4.6/5.0
  Behavior4/5

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

  readOnlyHint already flags this as safe, and the description adds the return behavior: JSON containing is_merged and, when true, the full merged area's address. No side effects or contradictions are mentioned.

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

  Conciseness5/5

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

  The one-sentence purpose is front-loaded, followed by a compact Args list and a short Returns line. Every sentence adds information; no filler or repetition.

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

  Completeness5/5

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

  For a simple read-only check with three optional parameters and no output schema, the description covers the inputs, the defaults, and the return shape. An agent has everything needed to invoke it correctly.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by explaining workbook (name or path, None = active), sheet (name, None = active), and cell (A1-style reference with an example). Each parameter's meaning is unambiguous.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Check whether a cell is part of a merged range.' This clearly defines the tool's purpose and distinguishes it from mutating siblings such as merge_cells and unmerge_cells.

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

  Usage Guidelines4/5

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

  The purpose statement makes the intended use obvious: call this when you need to know if a cell belongs to a merged range. It doesn't name alternative tools or give explicit when-not-to-use guidance, but no close alternative is needed for this inspection operation.

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

• list_chartsA
  4.6/5.0
  Behavior4/5

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

  The description discloses the return behavior — JSON with each chart's name and position/size — which goes beyond the readOnlyHint annotation. It also explains the workbook/sheet resolution behavior. No side effects are mentioned, which is consistent with the readOnlyHint annotation. No contradiction detected.

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

  Conciseness5/5

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

  The description is concise and well-structured with three labeled sections: purpose, Args, and Returns. Every sentence adds value, and the core purpose is front-loaded in the first line. There is no repetition, filler, or ambiguous wording.

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

  Completeness5/5

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

  For a simple listing tool, the description provides everything needed to call it correctly: target workbook/sheet, optional parameter semantics, and the return shape. Since there is no output schema, the Returns line sufficiently communicates what the agent will receive. The readOnlyHint annotation covers the safety profile, so no additional behavioral caveats are needed.

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

  Parameters5/5

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

  The input schema properties have zero descriptions (0% schema description coverage), so the description carries the full burden of parameter documentation. It defines workbook as 'Workbook name or path' and sheet as 'Worksheet name', and clearly states that None means the active workbook or sheet. This fully compensates for the bare schema.

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

  Purpose5/5

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

  The description opens with 'List charts on a worksheet' — a specific verb ('list'), resource ('charts'), and scope ('worksheet'). This clearly distinguishes it from sibling tools like create_chart, delete_chart, set_chart_type, and list_worksheets based on the operation and resource. The Returns line further clarifies that the output is chart inventory data.

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

  Usage Guidelines4/5

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

  The description clearly establishes when the tool is appropriate: to list charts on a worksheet. It provides contextual guidance on targeting a specific workbook or sheet, including the None-means-active fallback. It does not explicitly name alternatives or exclusion cases, but for a simple read-only listing tool, the intended usage is clear.

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

• list_conditional_format_rulesA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses the exact return shape and an important behavioral limitation: cell-value rules only report formulas, while color scales report just the type. This helps the agent set expectations correctly and avoids assuming all rule types expose the same data. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is compact and well-structured with a purpose sentence, an Args list, and a Returns section. Every sentence contributes value, and the main action is front-loaded before parameter details.

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

  Completeness5/5

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

  Given there is no output schema, the description adequately explains what the tool returns, including per-rule indices, COM codes, formulas, and rule-type limitations. All optional parameters and defaults are covered, so an agent has enough information to invoke the tool correctly.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by documenting all three parameters: workbook and sheet accept None for active context, and range_address is described as an A1-style address with an example. This adds meaning beyond the bare schema properties.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'List conditional formatting rules applied to a range.' The Returns section further clarifies it is a read-only inspection tool for existing rules, which clearly distinguishes it from siblings like add_conditional_format_rule and clear_conditional_format_rules.

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

  Usage Guidelines3/5

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

  The description implies usage: it lists rules, contrasting with add/clear conditional formatting siblings. However, it does not explicitly state when to choose this tool over alternatives, such as 'use this to inspect rules before modifying them.' It provides clear context but no exclusions or direct alternative guidance.

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

• list_named_rangesA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description goes beyond by stating that hidden/internal names are omitted and that the return is JSON with each name and what it refers to. This adds behavioral detail about the output format and filtering behavior, which annotations do not cover. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is short, well-structured with clear sections (Args, Returns), and every sentence adds value. It front-loads the core purpose and then provides necessary details without fluff. It is appropriately sized for a one-parameter read-only tool.

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

  Completeness5/5

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

  For a simple list tool with one optional parameter and no output schema, the description covers the purpose, the parameter semantics, the return format, and important filtering behavior. There is no missing information an agent would need to call it correctly. The note about hidden names being omitted is critical and provided.

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

  Parameters5/5

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

  The schema provides only the parameter name and default, with 0% description coverage. The description fully compensates by explaining 'workbook: Workbook name or path (None = active workbook)', giving both the meaning and the default behavior. This is exactly the kind of semantic clarification the description should provide.

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

  Purpose5/5

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

  The description clearly states the action (list), the resource (named ranges), and the scope (user-defined, in a workbook). It explicitly distinguishes from other named-range tools by noting that hidden/internal names are omitted, which separates it from read_named_range or write_named_range. This is a specific, unambiguous purpose.

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

  Usage Guidelines4/5

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

  The description gives clear context about what the tool returns and what it excludes (hidden/internal names), but it does not explicitly state when to choose this tool over alternatives like read_named_range or create_named_range. The sibling tools are self-explanatory, but there is no direct 'use this for ... instead of ...' guidance. It provides a clear context without explicit exclusions for alternatives.

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

• set_chart_titleA
  4.6/5.0
  Behavior4/5

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

  With no behavioral annotations beyond the title, the description carries the burden and does disclose key behavior: empty string or None removes the title, omitted workbook/sheet target the active workbook/sheet, and the tool returns a JSON confirmation. It does not discuss error cases or overwrite semantics, but 'set' and 'clear' make those reasonably clear.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line purpose, an Args list covering all four parameters, and a Returns line. Every sentence contributes useful information with no filler.

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

  Completeness5/5

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

  Despite having no output schema and minimal annotations, the description provides all essential information an agent needs: purpose, every parameter's meaning and defaults, removal behavior, and the return type. It is complete for a simple chart-title setter.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must fully explain the parameters. It does: workbook and sheet include default behavior, chart_name is explicitly called required, and title explains how empty/None values behave. This adds substantial meaning beyond the bare schema properties.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'Set or clear a chart's title.' This clearly distinguishes it from chart-type or chart-creation siblings, and the additional clearing behavior adds precision beyond the tool name.

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

  Usage Guidelines4/5

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

  The use case is clear from the verb phrase and parameter semantics: use this tool when you need to set or remove a chart title. It does not explicitly name alternative tools or when-not conditions, but the context is unambiguous among the chart-related siblings.

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

• get_range_valuesA
  4.8/5.0
  Behavior5/5

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

  Annotations already include readOnlyHint=true, and the description confirms a read operation. It goes beyond annotations by disclosing the return format (JSON with a 2D array even for a single cell) and default parameter behavior (None = active workbook/sheet), which is valuable context.

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

  Conciseness5/5

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

  The description is concise and well-structured with Args and Returns sections. The main purpose statement is front-loaded, and every sentence provides necessary information. No fluff.

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

  Completeness5/5

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

  There is no output schema, so the description properly explains the return format. It covers all parameters, defaults, and return behavior. The tool's simplicity and read-only nature means nothing critical is missing for an agent to invoke it correctly.

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

  Parameters5/5

  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 each parameter in the Args section, including example for range_address ('A1' or 'A1:C10'). This fully covers the parameter semantics.

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

  Purpose5/5

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

  The description states 'Read values from a cell or range in an open workbook,' which is a specific verb and resource. It clearly distinguishes from sibling get_range_formulas by emphasizing 'values' rather than formulas. The scope is well-defined.

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

  Usage Guidelines4/5

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

  The description provides clear context: it reads values from a range, and the default behavior for workbook/sheet is explained. However, it does not explicitly mention when not to use it (e.g., when formulas are needed) or name an alternative tool, so it lacks explicit exclusions.

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