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

No annotations provided, so the description carries full burden. It explains arrowhead placement (at (x2,y2) and start if double_headed), double_headed option, and head_size default (10). This is sufficient for basic behavioral understanding.

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

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

Well-structured with a clear initial sentence. The Args section is slightly lengthy but necessary given no schema descriptions. Could be condensed, but no redundancy.

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

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

Covers all essential information: what the tool does, parameters with explanations, and return type (success message). Given no annotations, this is adequate for a tool with 7 parameters and an output schema.

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

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

Schema has 0% description coverage (only titles/types), so the description must add meaning. It provides detailed explanations for all parameters: graph_name, x1,y1 (tail), x2,y2 (head), double_headed option, head_size default.

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

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

The description clearly states 'Draw an arrow from (x1,y1) to (x2,y2) at data coordinates', specifying the verb (draw), resource (arrow), and coordinates. It differentiates from siblings like add_line (line without arrow) and add_text_annotation (text).

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies use for directional annotations, but does not mention cases where add_line or other annotation tools might be more appropriate.

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

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

No annotations provided, so the description carries full burden. It only mentions appending empty columns and a success message, but omits behavioral details such as column insertion position, effect on existing data, or error conditions.

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

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

The description is exceptionally concise: one sentence for purpose, then a clean Args/Returns block. Every element earns its place with no redundancy.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers essential parameters but lacks behavioral context (e.g., where columns are appended, count limits, error scenarios). It is functional but minimally complete.

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

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

With 0% schema description coverage, the description must compensate. It provides basic meaning for each parameter (e.g., 'count: Number of columns to add') but adds no extra constraints, format rules, or nuances beyond the parameter names.

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

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

The description clearly states the verb (append), resource (empty columns), and target (worksheet). It distinguishes the tool from its sibling 'delete_columns' by specifying the opposite operation.

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

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

The description implies the tool is used to add columns but provides no explicit guidance on when to use it versus alternatives (e.g., adding other elements like rows). No context on prerequisites or exclusion criteria.

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

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

With no annotations, the description must disclose behavior. It conveys that the tool adds a layer and returns a success message with the new layer index. It does not cover side effects, authentication, or error scenarios, but it adequately describes the core action and outcome.

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

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

The description is a compact, well-structured docstring with a clear purpose, args list, and returns. Every sentence adds value without redundancy, and the most important information comes first.

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

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

For a tool with simple inputs and an output schema, the description covers the essential aspects. It could be more complete by specifying that the graph must exist or describing the layer-index format, but it is sufficient for most use cases.

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

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

The description explains both parameters beyond the schema: layer_type lists possible values (right-y, top-x, inset, independent). Graph_name is minimally described but sufficient. Given 0% schema description coverage, the description adds essential context.

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

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

The description clearly states the action ('Add a new layer') and the target resource ('graph'), with examples of layer types. This immediately distinguishes it from sibling tools like add_second_y_axis, which are more specific.

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

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

The description lists valid layer types, giving agents a hint for correct usage. However, it does not explicitly state when to choose this tool over alternatives (e.g., add_second_y_axis) or mention prerequisites like graph existence.

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

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

No annotations provided; description mentions it draws a line and returns a success message but does not disclose potential side effects, permissions, or whether the line is permanent. 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.

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

Very concise with clear structure: purpose, usage, arguments, returns. Only 6 lines, front-loaded with key information.

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

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

Covers purpose, usage, all 5 parameters, return type, and alternative tool. Complete for a simple drawing tool with an output schema.

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

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

Description explains each parameter in the Args section, including that coordinates are in data coordinates, adding meaning beyond schema titles (0% schema description coverage).

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

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

Description states 'Draw a straight line between two data points on a graph' with specific verb+resource and distinguishes from sibling add_arrow.

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

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

Explicitly says 'Useful for guides, connectors, and trend indicators' and provides alternative tool: 'For a line with an arrowhead, use add_arrow instead.'

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

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

No annotations provided, so description carries the burden. It explains parameters and returns a success message but does not disclose side effects, permission needs, or behavior on overwriting vs appending. Adequate but incomplete.

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

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

Short introductory sentence followed by a clear, structured list of arguments. Every sentence is purposeful with no redundancy.

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

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

For a tool with 7 parameters and no annotations, the description covers parameters well but omits error handling details and output schema specifics (only says 'Success message'). Mostly complete.

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

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

Schema coverage is 0%, yet the description provides detailed explanations for each parameter: meaning of column numbers (1-based), optional error column (0=none), and plot_type options. This adds significant value beyond the schema.

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

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

Description clearly states 'Add another data series to an existing graph', specifying the action and resource. It distinguishes from siblings like create_graph or add_arrow by focusing on data series addition.

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

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

The description implies usage for adding data to an existing graph but does not explicitly state when not to use or mention alternatives. The context is clear enough for an agent to decide.

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

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

With no annotations, the description fails to disclose behavioral traits such as whether the line is added cumulatively, any side effects, or permission requirements. It only mentions the parameters and a generic success message.

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

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

The description is concise with two sentences plus a bullet list for parameters, front-loading the main action with no wasted words.

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

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

For a simple tool with 3 parameters and an output schema, the description covers the core function and return type but misses usage guidelines and deeper behavioral context.

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

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

Schema coverage is 0%, so the description adds meaning by listing and explaining each parameter (graph_name, orientation, value) in the args section, though it lacks constraints or examples.

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

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

Description clearly states the tool draws a horizontal or vertical reference line at a data value, specifying the verb 'draw' and resource 'reference line', and distinguishes from siblings like 'add_line' or 'add_arrow'.

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

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

The description implies usage for adding reference lines to graphs but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like 'add_line' or 'add_arrow'.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It explains arguments but does not mention that the tool modifies an existing graph, requires the graph to already exist, or that it adds a new axis and series. Side effects are not discussed.

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

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

The description is concise: a one-sentence summary followed by a structured bullet list of arguments and a return statement. Every sentence adds value with no redundancy.

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

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

Given the tool has 6 parameters and an output schema (not shown), the description covers purpose and parameters well. However, it could mention prerequisites (graph must exist) and that it modifies the existing graph. Overall, it is mostly complete.

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

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

Schema description coverage is 0%, and the Description compensates fully by explaining each parameter: graph_name as 'Existing graph', data_book/sheet as source data, x_col/y_col as 1-based columns, and plot_type with allowed values (scatter, line, etc.). This adds significant meaning beyond the schema's type-only definitions.

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

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

The description uses a specific verb 'Add' and resource 'right-side Y axis layer', clearly distinguishing it from siblings like add_layer or add_plot_to_graph. It also mentions plotting a second dataset, making the purpose unmistakable.

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

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

The description does not explicitly state when to use this tool versus alternatives like add_layer or add_plot_to_graph. Context is implied by the name and description, but no exclusions or conditional guidance are provided.

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

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

No annotations are present; the description gives basic behavioral info (returns success message, text constraints) but omits details about side effects (e.g., overwriting existing annotations), coordinate validation, or impact on the graph state.

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

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

The description is reasonably concise with clear Args/Returns formatting. It is front-loaded with the main action. Minor improvement: could be slightly more compact by integrating the parameter notes inline.

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

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

Given no annotations and a moderate number of parameters, the description covers parameter semantics well but lacks usage context and behavioral details (e.g., error handling, coordinate system). The output schema exists but is not shown; the description at least mentions the return value.

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

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

The description fully explains all 5 parameters: graph_name, text (with restriction on characters), x, y, and name (default). This adds crucial meaning beyond the input schema's minimal titles, compensating for 0% schema coverage.

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

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

The description clearly states 'Add a text label to a graph at data coordinates,' specifying the action (add) and resource (graph) with the type of annotation (text label). This distinguishes it from sibling tools like add_arrow or add_line.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., add_arrow, add_reference_line). There is no context about prerequisites, typical scenarios, 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.

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

No annotations are provided, so the description bears full responsibility. It discloses that the graph must already be a colormapped plot and that the tool changes the color mapping. It does not mention whether the operation is reversible, if it overwrites existing palettes, or any side effects, which would be helpful for a mutation tool.

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

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

The description is concise and well-structured, with a clear one-sentence summary followed by a parameter list. No redundant information; every sentence adds value.

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

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

The description covers the tool's purpose, parameter details, and return value (success message). Given the tool's simplicity and the presence of an output schema (though not shown), it is nearly complete. Minor omissions like case sensitivity or error handling prevent a perfect score.

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

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

With 0% schema description coverage, the description fully compensates by explaining graph_name as a graph that must hold a colormapped plot and palette with a rich list of recommended options, including bundled colorblind-safe maps and built-in Origin palettes, far exceeding the schema's minimal type hints.

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

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

The description explicitly states the tool applies a color palette to contour/heatmap/surface graphs, using a specific verb and resource. It distinguishes from siblings like set_colormap_levels, which adjusts levels, and set_plot_style, which changes line style, by focusing solely on palette application.

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

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

The description provides context for when to use by listing recommended palettes and noting the graph must already hold a colormapped plot. However, it does not explicitly exclude alternatives or state when not to use this tool, leaving room for ambiguity among sibling tools.

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

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

No annotations are provided, so the description carries full burden. It explains the tool applies a complete set of styles but does not explicitly state whether it overwrites existing styles, what side effects occur, or any prerequisites. The behavioral description is adequate but not fully transparent.

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

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

The description is well-structured with a bold summary, bullet-like styling list, and an Args section. It is front-loaded with the main purpose and each sentence adds value, though slightly verbose.

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

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

Given the complexity (9 parameters, no schema descriptions or annotations, but with an output schema), the description is highly complete: it explains the tool's purpose, efficiency benefit, all parameters with guidance, and return value. The output schema covers return details, so no further explanation needed.

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

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

Schema description coverage is 0%, but the description's Args section details each parameter with examples and default behaviors (e.g., 'None=auto' for min/max, 'e.g. Sample A,Sample B' for legend_entries). This fully compensates for the missing schema descriptions.

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

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

The description clearly states it applies complete publication styling to a graph in one call, listing specific styling elements (bold Arial labels, muted palette, etc.) and explicitly distinguishes from sibling tools by noting it replaces many separate calls.

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

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

The description explicitly says 'Designed to minimize token usage — call this instead of many separate tools', providing clear when-to-use guidance and implying alternatives (the individual styling tools). It does not explicitly list when not to use, but the guidance is sufficient.

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

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

No annotations are provided, so the description bears full burden for behavioral disclosure. It indicates the tool returns a JSON object with specific stats but does not state whether the operation is read-only, whether it modifies the worksheet, or any required permissions. No caveats about missing data or edge cases 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.

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

The description is extremely concise: one sentence stating the purpose followed by a bullet list of returned fields. No unnecessary words, and the key action (returns descriptive statistics) is front-loaded.

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

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

Although an output schema is indicated as present, it is not provided, so the description's listing of return fields compensates partially. However, the tool has three parameters with no explanatory text, and the description omits behavioral context like read-only status or data type requirements. For a tool with no annotations and minimal schema coverage, the description falls short of being fully self-contained.

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

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

With 0% schema description coverage, the description provides no additional meaning for the three required parameters (data_book, data_sheet, col). While parameter names are suggestive, the description does not clarify expected formats, units, or how the column is identified (e.g., index vs. name). This forces the agent to rely solely on the minimal schema.

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

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

The description clearly states it provides descriptive statistics for one worksheet column, listing the specific measures returned (mean, sd, se, variance, median, min, max, sum, n). This distinguishes it from sibling tools like compare_means or curve_fit, which serve different analytical purposes.

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

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

The description lacks guidance on when to use this tool versus alternatives. It does not specify prerequisites (e.g., numeric column), exclusions, or mention related tools for multi-column or grouped statistics. The user must infer usage context from the tool name alone.

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

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

No annotations are provided, so the description must carry the full burden. It discloses the return fields (t, df, p_value, etc.) and mentions the 'equal_variance' parameter, hinting at Welch's t-test by default. However, it omits assumptions, side effects, 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.

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

The description is very concise and front-loaded with the core action. However, it is too terse, especially missing parameter explanations. It could be slightly more informative without losing conciseness.

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

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

For a tool with 5 parameters and a statistical test, the description is incomplete. It lacks prerequisite information (e.g., numeric columns, data existence) and does not guide parameter usage. The output schema is described, but input context is scant.

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

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

Schema description coverage is 0% and the description does not explain any parameters (data_book, data_sheet, col1, col2, equal_variance). It only describes the output, leaving parameter semantics entirely to the schema, which lacks descriptions.

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

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

The description states 'Two-sample t-test between two columns,' which is a specific verb and resource. It clearly distinguishes from sibling tools like 'column_statistics' or 'curve_fit' that have different statistical purposes.

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

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

The description implies usage for comparing means but does not explicitly guide when to use this tool versus alternatives like 'column_statistics' or 'curve_fit'. No exclusion criteria or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses a key behavioral detail: the returned graph name may differ from graph_name if taken. However, it does not mention permissions, destructiveness (does it modify worksheet data?), or other side effects. The description is adequate but could be more transparent.

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

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

The description is well-structured with a concise opening line and a clear bullet list of parameters. Every sentence provides necessary information; there is no redundancy or fluff. It is appropriately sized for the complexity of the tool.

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

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

Given the tool's complexity (9 parameters, multiple plot types) and the presence of an output schema, the description is quite complete. It covers all parameters and return value behavior. Minor omissions: it does not mention preconditions like the worksheet existing or error handling, but these are not critical for basic usage.

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

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

Schema description coverage is 0%, so the description must explain parameters thoroughly. It does so admirably: each parameter has a clear explanation, including constraints (e.g., x_col is 1-based, ignored for box/histogram) and when parameters are required (e.g., z_col required for contour and 3d_scatter). This adds substantial value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Create a graph from worksheet data.' This is a specific verb-resource pair (create graph) with a data source. It distinguishes well from siblings that modify existing graphs (e.g., add_arrow, add_plot_to_graph).

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

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

The description implies that this tool is for creating new graphs from worksheet data, which contrasts with sibling tools for modifying graphs. However, it lacks explicit guidance on when to use this tool versus alternatives like add_plot_to_graph or save_graph_template. The context is clear but not explicitly stated.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It clearly states that the operation creates a matrix book and specifies that the returned name may differ from the requested book_name if the name was taken. However, it does not mention whether the tool overwrites existing books 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.

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

The description is brief yet comprehensive, with a clear purpose statement, a bulleted Args section, and a Returns note. Every sentence serves a purpose and the structure is logical and front-loaded.

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

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

Despite the presence of an output schema (as indicated by context signals), the description adequately covers the return value. It provides enough detail for a straightforward creation tool, though it could mention potential errors (e.g., invalid name) or side effects.

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

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

Given 0% schema description coverage, the description adds meaningful value by explaining each parameter: book_name is the name, rows and cols have defaults and are initial sizes. This compensates for the schema's lack of descriptions, though it could further clarify constraints like minimum values.

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

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

The description clearly states 'Create a new matrix book in Origin' and explains that matrices back 3D surface, contour, heatmap, and image plots, which differentiates this from sibling tools like create_worksheet (for worksheets) and create_matrix_plot (for plots on matrices). The verb-resource pair is specific and unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives such as create_worksheet or create_matrix_plot. It only describes the tool's own function without contextual selection advice or exclusions.

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

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

No annotations are provided, so description carries full burden. It mentions only basic return value (created graph name) but does not disclose side effects, error conditions, or prerequisites like needing an existing matrix.

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

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

Well-structured with Args and Returns sections. Slightly lengthy but clear; could be more concise by trimming redundant phrasing.

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

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

Adequate for a tool with 4 parameters and no annotations, but missing usage guidelines and behavioral transparency. Return type is covered by description.

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

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

Schema has 0% description coverage, but the description explains all four parameters in detail: matrix_book with cross-reference, plot_type with allowed values, graph_name optional, and z_label effects. This adds significant meaning beyond schema.

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

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

The description clearly states the tool plots a matrix as surface, contour, heatmap, or image. It distinguishes from sibling tools by focusing specifically on matrix plots, though it does not explicitly contrast with alternatives.

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

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

No guidance on when to use this tool versus alternatives like create_graph or add_plot_to_graph. The description lacks when-not scenarios or prerequisites.

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

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

Without annotations, the description bears full burden. It discloses the return behavior (may differ from book_name if taken) but omits other details like side effects, permissions, or failure modes. Adds some context beyond schema but insufficient for full transparency.

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

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

The description is concise: one sentence for purpose, followed by Args and Returns sections. No wasted words, front-loaded with the core action. Every sentence adds value.

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

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

Given the tool's simplicity, the description adequately covers creation of a workbook with a worksheet, parameters, and return behavior. However, it lacks usage guidelines and does not discuss potential errors or constraints, leaving minor gaps for a complete understanding.

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

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

The description adds meaning beyond the input schema by explaining 'book_name' (name for new workbook) and 'sheet_name' (with default 'Sheet1'). It also notes the returned name may differ, which is not in the schema. Schema coverage is 0% in structured fields, so the description compensates well.

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

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

The description clearly states 'Create a new workbook with a worksheet in Origin,' specifying the action (create) and the resource (workbook + worksheet). It distinguishes itself from sibling tools like import_csv_to_worksheet or add_columns, which have different purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context for preferred use, leaving the agent without decision-making support.

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

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

With no annotations, the description discloses key behaviors: fitted curves can be plotted on existing graphs (paper style), and report sheets are kept. It does not specify error handling or side effects, but covers main outcomes.

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

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

Well-structured with Args and Returns sections. Slightly verbose but every sentence adds useful information. The lead sentence is concise.

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

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

Covers all parameters, defaults, and output format. Could mention error handling for invalid inputs or missing graphs, but overall complete for a fitting tool with output schema.

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

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

Schema description coverage is 0%, but the description explains every parameter in detail, including the list of built-in functions and the effect of 'plot_on_graph'. This adds significant value beyond the schema.

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

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

The description clearly states the action ('Perform curve fitting') and the resource ('worksheet data'), and distinguishes it from sibling tools like 'find_peaks' or 'smooth'.

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

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

No explicit guidance on when to use vs. alternatives (e.g., 'list_fitting_functions'), but the purpose is clear enough to infer usage context.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether deletions are permanent, if undo is possible, or if any confirmation is required. This is a significant gap for a destructive action.

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

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

The description is concise with a clear Args/Returns structure. No unnecessary information, though some behavioral notes could be added without bloat.

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

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

Given the simple parameters and lack of output schema complexity, the description covers the core functionality but lacks behavioral context (e.g., undo, permission requirements) that would make it fully complete for a destructive tool.

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

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

With 0% schema description coverage, the description compensates well by explaining each parameter: 'col' is 1-based and 'count' defaults to 1, adding meaning beyond the bare schema.

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

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

The description clearly states the action ('Delete one or more columns') and the resource ('starting at a position'), with a specific verb-resource pair that distinguishes it from sibling tools like 'add_columns'.

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

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

No guidance on when to use this tool versus alternatives. While the purpose is clear, there is no explicit when-not or mention of related tools like 'delete_rows' or 'clear_worksheet'.

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

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

Without annotations, the description fails to disclose side effects (e.g., whether the original columns are modified), data requirements, or error conditions; only states it returns a success message.

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

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

The description is concise with two sentences and front-loaded, but it omits crucial details that could be included without verbosity.

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

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

Given four required parameters, no annotations, and no output schema details, the description is grossly incomplete; it does not explain parameter roles, return format beyond a message, or any behavioral context.

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

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

Schema coverage is 0%, and the description does not explicitly describe the four parameters (data_book, data_sheet, x_col, y_col), though it implies x and y columns by mentioning derivative of Y with respect to X.

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

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

The description clearly states the tool computes the derivative dY/dX and adds a new column, distinguishing it from sibling tools like integrate, interpolate, or smooth.

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

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

No guidance on when to use this tool versus alternatives like integrate or curve_fit; no mention of prerequisites or context.

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

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

Without annotations, the description carries full burden. It discloses the clipboard replacement side effect and notes that dpi, width, and height parameters are unused (kept for API compatibility). This provides important behavioral context beyond the schema.

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

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

The description is front-loaded with purpose and key behavioral note, followed by an Args section. It is clear and efficient, though the Args section format is slightly verbose. No extraneous information.

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

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

Given the tool has 5 parameters, 1 required, no annotations, but an output schema indicating return value (per-graph list), the description covers major aspects: behavior, side effects, unused parameters, and return type. It lacks prerequisites (e.g., open project) but is largely complete for an export tool.

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

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

Schema coverage is 0%, so description must compensate. It explains output_dir ('Output directory (Windows or WSL style). Created if missing.') and format ('Image format: png, jpg, tif, bmp') while marking dpi, width, and height as unused. This adds significant value over the schema, though not all parameters get detailed usage syntax.

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

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

The description explicitly states 'Export every graph in the project to image files (one per graph).' This specifies the verb (export), resource (graphs), and scope (all graphs in the project), clearly distinguishing it from sibling tools like export_graph (single graph) and export_graph_sized (single graph with dimension control).

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

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

The description warns about clipboard replacement ('Windows clipboard contents are replaced during export'), providing a condition to consider before use. However, it does not explicitly state when to prefer this tool over alternatives like export_graph or export_graph_sized, though the sibling names imply the use case for bulk export.

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

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

With no annotations, the description fully discloses behavioral traits: clipboard replacement during export, unused parameters (width/height/dpi have no effect), and file path handling (Windows/WSL paths, missing directory creation). This exceeds the minimum required.

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

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

The description is efficient, with a clear opening sentence and structured Args list. While not overly long, it could be slightly more concise by omitting the unused parameter defaults, but each sentence adds value.

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

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

Given the tool's complexity (6 parameters, 2 required, no schema coverage) and the presence of an output schema (though not shown), the description covers all essential aspects: purpose, parameters, behavioral notes, and return value. It is fully adequate for correct invocation.

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

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

Schema coverage is 0%, so the description must explain all parameters. It details graph_name, file_path (with path style examples), format (allowed values), and explicitly marks width, height, dpi as unused but retained for API compatibility. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states 'Export a graph to an image file,' specifying the verb (export) and resource (graph to image). This distinguishes it from sibling tools like export_all_graphs, export_graph_sized, and export_worksheet.

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

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

The description mentions the clipboard side effect but does not explicitly state when to use this tool versus alternatives (e.g., export_graph_sized for size control). No when-to-use or when-not-to-use guidance is given.

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

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

With no annotations, the description carries full burden. It explains pixel size control and special height behavior (0 = keep aspect ratio) and mentions return info. However, it doesn't disclose if existing files are overwritten or required permissions.

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

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

The description is concise: a short purpose sentence, a comparative sentence, then a structured Args list and Returns line. No fluff, all sentences add value.

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

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

Given the presence of an output schema, the description only briefly mentions return values but covers parameters well. Missing error conditions or prerequisites (e.g., graph must exist), but overall adequate for a simple export tool.

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

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

Schema coverage is 0%, so description must add meaning. It lists all 5 parameters in Args section with explanations, defaults, and the special height=0 case, fully compensating for missing schema descriptions.

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

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

The description clearly states the tool exports a graph to an image at a chosen pixel size, and explicitly contrasts with export_graph (clipboard, page-size only), making its unique purpose unambiguous.

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

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

The description directly compares to export_graph, telling agents when to use this tool (when pixel size control is needed) and providing all arguments with defaults, aiding correct usage.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that the export includes column headers and returns path and row/column counts, but does not mention file overwrite behavior, permissions, or side effects. 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.

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

The description is concise with a single sentence summarizing the functionality, followed by structured Args and Returns sections. No unnecessary information is present.

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

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

Given the presence of an output schema, the description adequately explains the return value. It covers all parameters and provides basic usage context, but lacks guidance on prerequisites or file overwrite behavior.

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

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

The input schema has 0% description coverage, but the description provides meaningful explanations for all four parameters, including a list of valid delimiters. It adds value beyond the schema, though it omits the default delimiter value.

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

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

The description clearly states the tool exports a worksheet to a CSV/text file with column headers. The verb 'export' and resource 'worksheet' are specific, and it distinguishes itself from sibling export tools for graphs.

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

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

The description implies this tool is for exporting worksheets, but does not explicitly state when to use it versus alternatives like export_graph. No exclusions or alternatives are mentioned.

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

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

No annotations exist, so description must disclose behavioral traits. It mentions sampling interval derivation and return value, but does not specify if the tool creates a new sheet or modifies data, nor any prerequisites for column types or sampling regularity.

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

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

Three concise sentences with no waste, front-loading the purpose and key details.

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

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

Covers core function and return value, but lacks details on side effects (new sheet?), data requirements (numeric, evenly sampled), and the exact structure of the output spectrum sheet (though output schema exists). Adequate but not fully comprehensive.

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

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

Schema coverage is 0%, so description must add parameter meaning. It explains x_col's spacing is used as sampling interval, but leaves data_book, data_sheet, and y_col undefined. Does not fully compensate for missing schema descriptions.

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

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

Clearly states it performs a forward FFT on a signal and outputs a spectrum sheet, distinguishing it from sibling signal processing tools like differentiate or integrate.

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

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

Does not provide explicit guidance on when to use FFT vs alternatives like differentiate or find_peaks; assumes prior knowledge.

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

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

No annotations provided. Description mentions method and return format but lacks details on edge behavior, noise handling, or performance. Partial transparency but incomplete.

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

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

Description is short, front-loaded with purpose, and structured with Args/Returns. No redundant text.

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

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

Output schema exists and return format is described, but 4 required parameters are undocumented, making the description incomplete for practical use.

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

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

Schema coverage is 0%, so description must compensate. It explains 'direction' and 'local_points' but omits required parameters 'data_book', 'data_sheet', 'x_col', 'y_col', leaving significant gaps.

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

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

Description clearly states 'Find peaks in an XY curve (local-maximum method)', specifying the resource and method, and distinguishes from sibling tools like integrate, smooth, and differentiate.

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

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

No explicit guidance on when to use this tool versus alternatives. Sibling tools include many curve analysis operations, but the description fails to provide context for selection.

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

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

With no annotations, the description must disclose behavioral traits. It mentions the output structure (JSON list with center, end, count, cumulative), which is helpful, but does not indicate side effects, permissions needed, or whether the tool modifies data. This is minimally adequate for a read-only tool.

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

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

The description is short and front-loaded with purpose, but the parameter list covers only half the params, making it inadequate. Every sentence is useful but incomplete.

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

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

Given the tool has 6 required parameters and no annotations, the description is insufficient. It fails to explain three essential parameters (data_book, data_sheet, col) and does not provide context about selecting data sources, which is crucial for correct invocation.

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

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

Schema coverage is 0%, so the description must explain all parameters. It only explains bin_min, bin_max, and bin_size, ignoring data_book, data_sheet, and col. These three are critical for specifying the data source and column, and their omission leaves the agent guessing.

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

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

The description explicitly states it produces 'Histogram-style frequency counts for one column,' which clearly defines the tool's purpose and distinguishes it from siblings that perform other statistical operations like curve_fit or column_statistics.

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

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

No guidance is provided on when to use this tool versus alternatives such as column_statistics or compare_means. The description lacks context about prerequisites, data preparation, or scenarios where this tool is appropriate.

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

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

With no annotations, description carries full burden. It discloses that missing numeric variables return 0 and typed variables are script-local. It also states return type. However, it doesn't cover behavior for missing string variables 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.

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

Extremely concise: one-line purpose, gotchas presented clearly, then args/returns. Every sentence adds value, no wasted words.

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

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

For a simple tool with one parameter and output schema, description covers purpose, parameter semantics, return type, and behavioral gotchas. Minor gaps: missing behavior for non-existent string variables. Still adequate.

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

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

Despite 0% schema coverage, the description adds critical details: the naming convention ($ suffix for strings) and example ('str$'). This clarifies parameter usage far beyond the raw schema.

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

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

The first sentence clearly states the tool retrieves the value of a LabTalk variable. It differentiates from siblings like run_labtalk which executes scripts, and set_* tools which modify variables.

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

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

Gotchas provide guidance on when to use this tool: it notes that numeric non-existent variables read as 0 and typed variables vanish, advising to use untyped assignment in run_labtalk for persistence. While not explicitly stating when-not, it implies using run_labtalk for setting persistent variables.

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

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

The description mentions the return format and that empty cells are null, but lacks explicit statements about read-only behavior, side effects, or safety. Since no annotations are provided, the description partially covers behavioral transparency but not fully.

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

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

The description is concise and front-loaded with the purpose, then structured with args and returns. It is efficient but not overly brief, earning its place without unnecessary fluff.

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

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

Given the tool's simplicity (1 param, read-only, output schema exists), the description covers the essential aspects: what it does, the input parameter, and the output structure. It lacks error handling details but is otherwise complete for typical use.

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

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

The description includes an 'Args' section with 'book_name: Matrix book name', adding meaningful clarification beyond the bare input schema, which had 0% description coverage. This compensates well for the schema gap.

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

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

The description clearly states 'Read a matrix back as JSON', providing a specific verb and resource, and implicitly distinguishes from sibling tools like set_matrix_data (write) and create_matrix (create).

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

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

The description does not provide any guidance on when to use this tool versus alternatives, such as get_worksheet_data or other retrieval tools, leaving the agent without context for selection.

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

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

The description indicates a read-only operation, which implies no side effects. However, without annotations, it does not disclose potential failure modes, required permissions, or behavior with empty worksheets. It is adequate but lacks detail.

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

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

The description is concise with clear sections for Args and Returns. Every sentence is necessary and the structure is front-loaded with purpose.

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

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

For a simple read tool with two parameters and an output schema (implied), the description is adequate. However, it lacks usage context, such as whether the workbook must be open or how column data is structured. The output schema likely covers return details, so completeness is acceptable but not exceptional.

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

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

The description merely repeats parameter names ('Workbook name', 'Sheet name') without adding meaning about format, case sensitivity, or how to specify paths. With 0% schema description coverage, the description should provide more context.

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

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

The description clearly states 'Read data from an Origin worksheet,' which is a specific verb (read) and resource (Origin worksheet). This distinguishes it from sibling tools that write or modify worksheet data.

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

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

No guidance is provided on when to use this tool versus alternatives like 'set_worksheet_data' or 'list_worksheets'. The description only lists parameters without usage context or prerequisites.

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

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

With no annotations, the description carries full burden. It discloses return value (workbook name), file path styles, and default behavior for book_name and delimiter. It does not cover error handling or side effects like overwriting, but covers essential behavioral aspects.

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

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

The description is concise and front-loaded with the purpose. It uses a clear Args/Returns structure with no wasted words. Every sentence adds value.

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

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

Given the tool's complexity (3 parameters, output schema exists), the description covers the purpose, parameters, and return value adequately. It is complete for typical usage, though error cases are not described.

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

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

Schema coverage is 0%, so description must add meaning. It fully describes each parameter: file_path with path style examples, book_name as optional with auto-generation, delimiter with default. This adds significant value beyond the bare schema.

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

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

The description clearly states 'Import a CSV/text file into an Origin worksheet.' The verb 'import' and resource 'CSV/text file into worksheet' are specific and distinguishable from sibling tools like 'import_excel'.

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

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

The description specifies the context of importing CSV/text files and provides defaults for optional parameters. However, it does not explicitly exclude alternatives (e.g., import_excel) or state when not to use this tool.

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

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

No annotations provided, and the description does not disclose side effects, permissions, error behavior, or limits. It only states it creates a new workbook, leaving behavioral gaps.

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

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

The description is concise and front-loaded with the main purpose. The args list is clear, but could be slightly more streamlined without losing information.

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

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

The description covers inputs, output, and basic behavior adequately for a simple import, but lacks details on error handling, file size limits, or edge cases that would make it more complete.

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

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

With 0% schema description coverage, the description adds meaning by specifying file path style and the optional nature of book_name, which 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.

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

The description clearly states the tool imports an Excel file into a new workbook, with specific verbs and resources, distinguishing it from sibling tools like import_csv_to_worksheet.

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

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

The description clarifies file path format and optional bookmark but lacks explicit guidance on when to use this tool vs. alternatives like import_csv_to_worksheet, which would help differentiate.

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

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

No annotations are provided, so description must carry behavioral disclosure. It only states returns JSON with area, lacking method, error handling, or edge cases.

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

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

Two sentences with no filler. Front-loaded with core purpose.

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

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

Output schema presence mitigates some gap, but with four required parameters and no parameter info, description is insufficient for correct invocation.

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

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

Schema coverage is 0%, and description mentions no parameters. Agent cannot infer which parameters map to X and Y or how data_book/data_sheet are referenced.

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

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

The description clearly states it integrates Y over X for area under the curve, specifying verb and resource. It distinguishes from sibling tools like differentiate and curve_fit.

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

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

No guidance on when to use integration vs other analysis tools. Lacks context for preferred scenarios or prerequisites.

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

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

No annotations are present, so the description carries full burden. It discloses that a new output sheet is created and returns resampled X and Y, but does not mention if original data is preserved, auth needs, or handling of edge cases (e.g., missing data).

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

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

The description is very short and front-loaded with the core action. It includes an args/returns section, which is helpful, but the lack of detail on required parameters prevents a perfect score.

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

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

The description is incomplete given the tool's complexity (6 parameters, output schema). It explains only the optional parameters and assumes the agent knows the format of 'data_book' and 'data_sheet'. No prerequisites or data format expectations are stated.

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

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

Schema coverage is 0%, and the description only explains 'num_points' and 'method' (2 of 6 parameters). Required parameters like 'data_book', 'data_sheet', 'x_col', 'y_col' get no explanation, forcing the agent to infer their meaning from names.

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

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

The description 'Resample an XY curve onto evenly spaced X values' uses a specific verb and resource, clearly distinguishing this interpolation tool from similar siblings like 'smooth' or 'integrate'.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. While the purpose is clear, the description does not help the agent decide between this and related tools like 'curve_fit' or 'smooth'.

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

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

Annotations are absent, so the description carries the full burden. It correctly indicates that the tool lists information and returns a JSON. No side effects or destructive behavior is implied, and the read-only nature is evident. The only minor gap is not explicitly stating that it requires no input, but the schema already shows zero parameters.

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

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

The description is extremely concise: two sentences, no redundant information. The first sentence defines purpose, the second describes the return format. Every word is necessary.

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

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

Given zero parameters, no annotations, and an existing output schema, the description provides a high-level summary of the return value. It is sufficient for an agent to understand the tool's basic functionality, though more detailed structural info is likely in the output schema.

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

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

The tool has no parameters, and the schema coverage is 100% by default. The description adds value by explaining the output structure (JSON grouped by category with parameter names). Since there are no parameters to describe, this is fully adequate.

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

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

The description clearly states the action 'List' and the resource 'available built-in fitting functions and their parameters'. It is specific and easily distinguishable from sibling tools which are mostly about creation, modification, or export.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. However, the context is clear for a listing tool; it serves as a reference before using curve_fit. No exclusions or when-not-to-use indications are given, which is acceptable for a simple read operation.

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

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

No annotations provided, so the description carries full burden. It clearly states the tool lists all open entities, implying read-only behavior, and provides the return format. Lacks mention of potential side effects or performance implications.

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

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

Two sentences, no wasted words. Information is front-loaded: verb, resources, and return format.

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

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

For a listing tool with no parameters and an output schema hinted in the description, the description is adequate. It explains exactly what is returned, though it could detail properties of each sheet.

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

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

No parameters; schema coverage is 100%. The description adds value by specifying the return structure, which is not present in the input schema.

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

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

The description uses a specific verb 'List' and clearly identifies the resources: open workbooks (with their sheets), graphs, and matrices. This distinguishes it from sibling tools like get_worksheet_data or export_worksheet.

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

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

The description implies the tool is for exploring the current workspace structure, but it does not explicitly state when to use it vs alternatives. No guidance on when not to use it or prerequisites.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does mention that the tool replaces the current project, but it omits critical warnings about potential data loss if unsaved changes exist. This is a significant gap for a destructive operation.

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

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

The description is extremely concise: two sentences plus a parameter and return value note. Every sentence is purposeful and the main action is front-loaded.

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

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

Given that the tool replaces the current project, the description should mention saving behavior or error handling. The return value is simply 'Success message', and there is no output schema to supplement. It is minimally adequate but lacks important context.

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

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

The schema only specifies a string parameter with title 'File Path' and no description. The description adds meaning by specifying the expected file extensions (.opj or .opju) and path style (Windows or WSL), which compensates for the 0% schema coverage.

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

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

The description clearly states the tool opens an Origin project file and replaces the current project. This verb+resource combination is specific and distinguishes it from siblings like new_project and save_project.

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

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

The description implies when to use this tool (to load an existing project) and that it replaces the current project, but does not explicitly state when not to use it or mention alternatives like save_project before loading.

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

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

With no annotations, the description fully discloses the critical behavior of closing the current project without saving, which is essential for the agent to understand the tool's impact.

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

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

Single sentence of 10 words, front-loaded with key information, no redundant or extraneous content.

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

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

Given zero parameters and the existence of an output schema, the description adequately covers the tool's purpose and primary behavioral trait (closing without saving), making it complete for effective agent usage.

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

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

No parameters exist, so schema coverage is 100%. Baseline is 4, and the description adds no additional param info, but none is needed.

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

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

Description clearly states the action 'create' and resource 'new empty Origin project', and distinguishes from siblings like 'load_project' or 'save_project' by noting it closes current without saving.

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

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

No explicit guidance on when to use this tool versus alternatives like 'load_project' or 'save_project'. The description implies the use case but does not provide exclusions or recommendations.

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

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

No annotations are provided, so the description carries the burden. It states the tool executes a LabTalk script, which is clear. However, it does not disclose behavioral traits such as potential side effects, authentication needs, or error handling beyond a generic success/failure message.

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

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

The description is concise, with one short paragraph front-loading the action. Every sentence serves a purpose: stating the action, distinguishing from siblings, and explaining the parameter. No wasted words.

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

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

Given the complexity of the sibling tools and the presence of an output schema, the description is mostly complete. It covers purpose and usage well, though the return value description is minimal ('Success/failure message') but the output schema likely provides detail.

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

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

With 0% schema description coverage for the single parameter 'script', the description adds minimal value by merely restating it as 'LabTalk script to execute'. No formatting, examples, or constraints are provided beyond what the schema already shows.

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

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

The description clearly states the verb 'Execute a LabTalk script' and the resource 'Origin Pro'. It also distinguishes this tool from siblings by noting it is for operations not covered by other tools, providing high clarity.

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

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

The description explicitly says when to use this tool: for any Origin operation not covered by other tools. This implies when not to use it (when a specific tool exists), but it does not elaborate on alternatives or provide explicit when-not guidance.

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

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

Without annotations, the description takes on full transparency burden. It explains the forced extension behavior and the old_format option, but does not disclose whether it overwrites existing files, if the graph must exist, or any required permissions. It adds value beyond the schema but is not exhaustive.

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

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

The description is concise with a clear structure: a one-line summary followed by Args and Returns sections. Every sentence provides necessary information without redundancy.

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

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

The description covers all parameters and the return value. It explains the forced extension behavior and the legacy format. However, it lacks error conditions or preconditions (e.g., graph existence). Given the output schema exists and the tool is straightforward, it is largely complete.

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

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

The description explicitly lists all three parameters with explanations: graph_name, file_path (with note about Windows/WSL style and forced extension), and old_format (with version info). The schema has no descriptions, so the description fills the gap effectively.

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

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

The description clearly states the tool saves a graph as a reusable Origin template (.otpu/.otp). The verb 'save' and resource 'graph' are specific. It distinguishes from sibling export tools by mentioning 'reusable template' and the specific file formats.

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

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

The description does not provide any guidance on when to use this tool versus alternatives like export_graph or save_project. No when-not-to-use or context-based advice is given.

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

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

No annotations are provided, so the description carries full burden. It reveals that '.opju' is appended when missing and that empty path saves to current location. However, it fails to disclose critical behaviors: whether saving overwrites an existing file, whether unsaved changes are preserved, or any potential destructive effects. This is insufficient for a save operation.

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

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

The description is reasonably concise, with a clear purpose line, enumerated argument description, and returns note. It fits in a few lines without wasted text. The structure with Args: and Returns: is clean. Minor improvement could remove the empty line after 'Args:'.

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

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

For a simple tool with one parameter and an output schema (despite not showing it here), the description covers the basics: operation, path behavior, and confirmation output. However, it lacks completeness for a save operation: no mention of overwrite behavior, error cases (e.g., invalid path), or whether it preserves unsaved changes. Adequate but with notable gaps.

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

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

The only parameter, file_path, is described with useful details beyond the schema: Windows/WSL style, automatic '.opju' appending, and default save location behavior. This adds significant meaning that the schema's minimal definition (type string, default empty) lacks.

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

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

The description clearly states 'Save the current Origin project.' This is a specific verb+resource. While it doesn't explicitly distinguish from siblings like load_project, the sibling set is diverse enough that confusion is unlikely. The purpose is clear.

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

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

The description implies usage (saving a project) but provides no explicit guidance on when to use this tool versus alternatives (e.g., load_project for loading, new_project for creating). No when-not-to-use or prerequisite conditions are mentioned.

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

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

The description does not disclose behavioral traits beyond the basic action, such as whether existing labels are overwritten, what happens if the graph does not exist, or any side effects. With no annotations, the description carries the full burden and fails to provide adequate behavioral context.

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

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

The description is concise with a clear Args list and Returns line. It is front-loaded with the purpose. However, the Args section is somewhat redundant with the input schema.

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

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

Given the tool's simplicity (4 parameters, 1 required), the description covers the basic operation and return value. However, it lacks explicit mention that the graph must already exist, which is implied but not stated. The output schema is implicitly described as a success message.

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

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

Schema description coverage is 0%, so the description must add meaning. However, it merely repeats parameter names and types from the schema without providing additional semantics like format constraints, valid values, or relationships. It adds minimal value.

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

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

The description clearly states the tool's action: 'Set axis labels and title for a graph.' This is a specific verb-resource combination that distinguishes it from sibling tools like set_axis_range or set_legend.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only lists parameters without contextual usage notes.

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

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

The description only states what the tool does (set axis range) and returns a success message. No annotations are provided, so the description carries full burden. It does not disclose any side effects, requirements, or error conditions.

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

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

The description is concise and well-structured: a one-sentence purpose, followed by an Args list and a Returns line. Every sentence adds value, and the format is easy to parse.

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

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

The description covers the essential aspects for a simple setter tool. The output schema exists (not shown), so a 'Success message' return is likely sufficient. However, it does not mention edge cases like non-existent graph_name or invalid ranges.

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

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

With 0% schema description coverage, the description adds meaning by explaining each parameter (e.g., 'x_min: X axis minimum (None=auto)'). This clarifies that None means auto-scaling, which is not evident from the schema alone.

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