Math MCP Learning

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

The annotations already declare readOnlyHint and idempotentHint, so the safe/non-mutating behavior is already communicated. The description adds some behavioral context by listing supported functions and noting 'safely evaluate', but it does not disclose potential edge cases like domain restrictions (e.g., log of negative numbers) or error handling. Given the annotations, the description adds modest value beyond them, so a 3 is appropriate.

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

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

The description is well-structured with a brief intro, a bulleted list of supported operations/functions, a clear usage note, and examples. Every sentence serves a purpose, and the information is front-loaded. It is concise while remaining informative, with no redundant or filler 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 that an output schema exists (so return values are already documented), the description covers the essential aspects: what expressions to provide, supported operations/functions, and an example. It also contextualizes when to use an alternative tool. However, it does not mention constants like pi or limits on expression length, but the maxLength is in the schema. Overall, it is fairly complete for a calculator tool of moderate complexity.

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

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

The input schema has full coverage of the single parameter 'expression', and the description goes beyond the schema by explicitly listing supported operations and functions, plus providing three concrete examples. This adds meaningful guidance on how to format the expression, which is not fully present in the schema. The examples help clarify expected input 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 clearly states the tool's purpose: 'Safely evaluate mathematical expressions' with a specific list of operations and functions. It also distinguishes itself from the statistics tool, which is a sibling, by explicitly noting that statistics should use a different tool. The verb 'evaluate' and resource 'mathematical expressions' are specific and unambiguous.

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

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

The description explicitly says 'Use this tool to evaluate a single mathematical expression' and provides a clear alternative for statistics ('use the statistics tool instead'). While it does not explicitly exclude other sibling tools like financial calc or unit conversion, the 'single mathematical expression' scope gives clear context for when to use this tool. This is clear usage guidance with one explicit exclusion.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the agent knows it's safe. The description adds the underlying formula, clarifies that the rate is a decimal, and provides example outputs, giving useful behavioral context beyond the annotations.

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

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

The description is well-structured: a one-sentence summary, then formula, parameter legend, and examples. All content is relevant and necessary for correctly invoking a compound interest calculator.

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 formula, parameter explanation, and example outputs cover the tool's behavior fully. The output schema covers return structure, and the schema constraints handle edge cases, making this description sufficient for reliable 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?

With 100% schema coverage, the baseline is 3, but the description significantly elevates understanding by presenting the formula A = P(1 + r/n)^(nt) and worked examples showing the role of each parameter, including the default for compounds_per_year.

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

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

The description opens with 'Calculate compound interest for investments', using a specific verb and resource. It clearly distinguishes itself from sibling calc tools (calc_expression, calc_statistics, calc_units) by focusing on compound interest specifically.

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 context is clear: investment and compound interest, reinforced by the formula and examples. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds examples of return values but does not disclose edge-case behaviors like handling of empty lists, sample vs. population standard deviation, or mode ties. It does not contradict annotations but adds limited 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 and front-loaded: a one-sentence purpose, an operations list, a usage note, and two examples. No fluff or redundant detail.

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

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

The tool is simple, has an output schema, and the description covers when to use it and alternatives. The examples are helpful. Minor gaps: the example call uses 'statistics' instead of the actual tool name 'calc_statistics', and it refers to 'calculate tool' rather than the exact sibling name 'calc_expression', which could cause slight confusion but not ambiguity about intent.

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

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

Schema description coverage is 100%, so the input schema already fully documents both parameters (numbers and operation) with descriptions and examples. The description repeats the allowed operations and provides example calls, but adds little beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Perform statistical calculations on a list of numbers' and enumerates the supported operations. It also distinguishes itself from siblings by explicitly pointing to the 'calculate tool' for single mathematical expressions, aligning with the sibling calc_expression.

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?

Explicit usage guidance is provided: 'Use this tool to compute descriptive statistics over a list of numbers. To evaluate a single mathematical expression, use the calculate tool instead.' This tells the agent when to use this tool and which alternative to pick.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds domain context (supported units and example outputs) without contradicting annotations. It doesn't discuss error handling for unsupported unit combinations, but that's a minor gap for a pure conversion function.

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: a concise opening, bullet-pointed unit categories, and two practical examples. It is front-loaded with the purpose, and every sentence contributes. The only minor issue is the example uses a different function name, but this doesn't detract from clarity.

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

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

Given the presence of an output schema, the description doesn't need to explain return values. The schema fully documents all parameters, and the description covers supported units and provides usage examples. For a straightforward conversion tool, this is complete and sufficient for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, with all four parameters (value, from_unit, to_unit, unit_type) fully documented including valid units. The description's unit lists largely duplicate schema content; the only extra is concrete examples, though they use 'convert_units' instead of the tool name 'calc_units'.

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 converts units of measurement and lists supported unit types (length, weight, temperature) with specific units. This specific verb+resource (convert units) distinguishes it from sibling calculation tools like calc_interest or matrix operations.

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

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

The description provides clear context by listing supported unit types and examples, making it obvious when to use this tool. However, it doesn't explicitly mention when not to use it or recommend alternatives among siblings, but the intent is unambiguous.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful context by stating that NumPy is required and that a ValueError is raised if unavailable, which is a behavioral trait not covered by annotations. Examples further demonstrate usage, though non-square matrix behavior is not explicitly disclosed.

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

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

The description is concise and front-loaded with the core purpose. The note about NumPy and the examples are useful and non-redundant, making every sentence earn 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?

For a simple tool with a well-documented schema and output schema, the description covers purpose, prerequisite, and examples. It would benefit from explicit mention of behavior for non-square inputs, but given the annotations and schema richness, it is adequately complete.

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

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

The input schema provides 100% coverage, describing the matrix parameter as a 2D list of numbers representing a square matrix with an example. The description's examples reiterate this but do not add new meaning beyond the schema, so it meets the baseline for high 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 states 'Calculate the determinant of a square matrix' with a specific verb and resource, clearly distinguishing it from sibling matrix tools like matrix_inverse or matrix_eigenvalues. The purpose is unambiguous and action-oriented.

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 determinant calculation but provides no explicit guidance on when to choose this over other matrix operations. It includes practical examples and a NumPy prerequisite, but lacks alternative comparisons or exclusions, so guidance is only implied.

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

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

Annotations already declare readOnlyHint and idempotentHint, so no contradiction. The description adds valuable behavioral context by noting 'Requires NumPy' and 'Raises ValueError if NumPy is unavailable', which is useful operational information beyond the annotations. It also provides concrete examples of invocation.

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

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

The description leads with the core purpose in the first sentence, followed by a brief dependency note and two illustrative examples. Every sentence contributes value with no redundancy or filler. It is appropriately sized for the tool's simplicity.

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

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

For a single-parameter tool with an output schema present, the description covers the main operational context: dependency on NumPy, error behavior, and usage examples. It does not mention edge cases like non-square matrices or the ordering of eigenvalues, but given the schema already specifies 'square matrix', this is a minor gap.

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

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

Schema coverage is 100%, and the schema already describes the matrix parameter with an example identical to the first example in the description. The description adds no new semantic information about the parameter; it merely repeats the schema's example and adds a diagonal matrix variant. Baseline of 3 applies.

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

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

The description clearly states 'Calculate the eigenvalues of a square matrix' with a specific verb and resource. It unambiguously distinguishes from sibling matrix tools like matrix_determinant, matrix_inverse, and matrix_multiply by focusing on eigenvalues.

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 tool's purpose implies when to use it (when eigenvalues are needed), and the sibling names provide context that this is the eigenvalue-specific tool. However, it does not explicitly state when not to use it or name alternatives, such as 'use matrix_determinant for determinants'.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds the requirement for NumPy and the ValueError if unavailable, which is useful behavioral context. It does not mention behavior for singular matrices, but given the annotation coverage and output schema, this is a minor omission.

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, front-loaded with the purpose, and includes a concise note about NumPy and two illustrative examples. Every sentence earns its place with no redundancy or filler.

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

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

For a single-parameter mathematical tool with full schema coverage, clear annotations, and an output schema, the description is sufficiently complete. It states the purpose, prerequisites, and provides examples. A minor gap is the lack of explicit error behavior for singular matrices, but this does not detract significantly from overall completeness.

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

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

Schema coverage is 100%, so the matrix parameter is fully described in the schema. The examples in the description reinforce the expected format but do not add semantic detail beyond the schema's existing description.

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

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

The description uses a specific verb 'Calculate' and resource 'inverse of a square matrix', making the tool's purpose unmistakable. It clearly distinguishes from sibling matrix tools like determinant or transpose by naming the specific operation and the square-matrix constraint.

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. The purpose is clear enough for selection, but no direct comparison or exclusion is provided. The NumPy dependency note is a prerequisite rather than usage guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds value by disclosing the NumPy dependency and the ValueError condition if unavailable. This is useful behavioral context beyond the structured annotations, though it does not cover all error cases like dimension mismatches.

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 compact and front-loaded with the core purpose, followed by a critical dependency note and two concise examples. No wasted sentences; the formula and examples earn their place.

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

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

With annotations, output schema, and full schema parameter coverage, the description sufficiently explains the tool's operation. The key missing explicit detail is the matrix dimension compatibility rule (A columns = B rows), though the examples illustrate it implicitly.

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

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

The input schema already provides 100% description coverage for both parameters with examples. The description's examples reinforce valid shapes but add no new semantic information beyond what the schema already offers, so the baseline of 3 applies.

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

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

The description states 'Multiply two matrices (A × B)' with a specific verb and resource, clearly distinguishing this from sibling matrix tools like determinant, inverse, and transpose. The formula notation and examples reinforce the exact 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?

Examples imply when to use this tool (valid multiplications with compatible dimensions) but there is no explicit guidance on when to choose this over sibling matrix operations or exclusions. The context is clear for a simple math function but lacks 'use this when' statements.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by disclosing the NumPy dependency and the ValueError condition if NumPy is unavailable, plus examples showing behavior on rectangular and single-column matrices.

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 core purpose. The note and examples are compact and directly useful, with no redundant or filler 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?

For a simple one-parameter tool with an output schema and safety annotations, the description covers purpose, dependency, error behavior, and usage examples. It is sufficiently complete for an agent to select and invoke correctly.

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

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

The schema already provides 100% coverage with a clear description of the matrix parameter, including type, structure, and example. The tool description adds calling examples but no additional parameter semantics beyond what the schema already states.

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

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

Description states the exact operation: 'Transpose a matrix (swap rows and columns).' This is a specific verb and resource, and it clearly distinguishes this tool from sibling matrix operations like determinant, eigenvalues, inverse, and multiply.

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 makes the tool's intent obvious and notes a critical prerequisite (requires NumPy), but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Usage is implied rather than explicitly guided.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds the dependency 'requires matplotlib,' which is useful environment context, but does not describe the return value or side effects (e.g., whether the plot is displayed or saved). This is a modest addition beyond annotations.

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

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

The description is two sentences plus two compact example calls. It front-loads the purpose and avoids filler, making it 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?

Given the tool's modest complexity and full schema coverage, the description sufficiently conveys the core purpose and example usage. It lacks return-behavior details, but the absence of an output schema and the presence of annotations reduce the need for more.

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

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

Schema has 100% coverage, describing all 5 parameters with types and examples. The description's examples reinforce usage of data_groups and group_labels but do not add meaning beyond the schema's existing parameter 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 a specific verb ('Create') and resource ('box plot') with a clear use case ('comparing distributions'), distinguishing it from sibling plot tools like plot_histogram and plot_scatter by the chart type.

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

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

The phrase 'for comparing distributions' implies the intended use case, but the description does not explicitly state when to prefer this over alternatives (e.g., plot_histogram) or provide exclusions. Examples show invocation but not selection guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds valuable context beyond them: it requires matplotlib, generates synthetic data for educational purposes, and explicitly notes it does not use real market data. It omits details about output/plot behavior, but this is not critical for a simple plotting 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 well-structured and front-loaded, but there is slight redundancy between 'Generate and plot synthetic financial price data' and 'Creates realistic price movement patterns for educational purposes.' The note and examples are valuable.

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

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

For a tool with four optional parameters and no output schema, the description covers purpose, use case, alternative, prerequisite, and examples. The only minor gap is the ambiguous 'optional moving average overlay' since no corresponding parameter exists in the schema.

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

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

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's examples demonstrate plausible parameter combinations but do not add semantic meaning beyond the schema.

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

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

The description opens with a specific verb-resource pair ('Generate and plot synthetic financial price data') and explicitly differentiates from sibling plot_line_chart by stating 'For general XY data, use plot_line_chart instead.' This makes the tool's 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?

Provides clear when-to-use guidance: 'Use for time-series price data with optional moving average overlay' and names the alternative for general XY data. Examples with parameter combinations reinforce 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds the 'requires matplotlib' dependency but does not disclose return format, whether the plot is displayed/saved, or error behavior. With annotations covering side-effect safety, this is adequate but not rich.

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

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

Description is two sentences plus two examples. The purpose is front-loaded, and every element earns its place. No redundancy or 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?

For a relatively simple tool with full schema coverage and safety annotations, the description is mostly sufficient. However, there is no output schema, and the description does not explain what the tool returns (e.g., plot object, file path), nor does it mention potential pitfalls. This creates a gap.

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

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

Schema description coverage is 100% for all parameters. The description adds example usage but no additional semantic information beyond the schema, so the baseline 3 is appropriate.

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

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

Description states 'Generate mathematical function plots' with concrete examples like "x**2" and "sin(x)", clearly distinguishing it from sibling chart tools that plot data points rather than math expressions.

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 purpose implies this is for mathematical expressions, but no explicit alternatives or exclusions are given. Examples show how to call it, but there is no guidance on when to choose this over plot_line_chart or plot_scatter.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering safety and side-effect concerns. The description adds the external dependency on matplotlib, which is useful behavioral context. However, it does not clarify whether the tool displays the plot, saves it, or returns a figure object, leaving some behavioral ambiguity beyond the annotations.

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

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

The description is brief and front-loaded with the core action, followed by two practical examples. Every sentence earns its place; there is no wasted wording, and the examples improve clarity 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?

The tool is simple (3 parameters, all documented, no output schema), and the description covers the essential usage with examples and a dependency note. It lacks details on the return value or display behavior, but given the low complexity and presence of annotations, the description is nearly complete for invocation purposes.

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

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

Schema description coverage is 100% with clear descriptions for data, bins, and title. The description's examples (e.g., bins=5, title='Test Scores') illustrate usage but do not add new semantic meaning beyond the schema. Since the schema fully documents each parameter, a baseline 3 is appropriate.

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

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

The description immediately states 'Create statistical histograms' with a specific verb and resource, and the tool's name matches. This clearly distinguishes it from sibling plot tools like plot_box_plot and plot_scatter, making its purpose unambiguous.

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

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

The description implies usage through the examples, showing how to call the tool with data and optional bins/title. It mentions a prerequisite ('requires matplotlib') but does not explicitly contrast with other plot types or state when to use a histogram over alternatives. Thus usage is implied, not explicitly guided.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds the prerequisite 'requires matplotlib' and scopes the tool to general XY data. It does not describe return values or rendering side effects, but the key behavioral traits are covered by annotations and the tool's purpose.

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

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

The description is brief but information-dense: a one-sentence purpose, a usage note with a sibling alternative, and two illustrative examples. No filler or redundant 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 the schema covers parameters and annotations cover safety, the description adds the required matplotlib dependency and the usage distinction from plot_financial_line. It does not explain what the tool returns, but for a plotting tool this may be self-evident. Overall it is sufficiently complete for agent use.

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

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

Schema describes all 7 parameters with 100% coverage. The description's examples supplement the schema by demonstrating call syntax and parameter order (e.g., x_data, y_data first), which adds practical usage meaning beyond the schema's static property list.

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 'Create a line chart from data points' with a specific verb and resource. It also explicitly differentiates from plot_financial_line, making the tool's scope clear and distinct among siblings.

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

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

The description provides explicit usage guidance: 'Use for general XY data. For time-series price data with optional moving average, use plot_financial_line instead.' This tells the agent when to use this tool and points to an alternative.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds the 'requires matplotlib' dependency and demonstrates parameter customization via examples, providing useful behavioral context beyond the annotations. It does not detail return values or side effects, but this is a minor gap given the annotation coverage.

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

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

The description is concise: one clear purpose sentence followed by two short, illustrative examples. Every sentence earns its place, and the structure front-loads the primary purpose while using examples to show parameter usage 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 is sufficient given the rich schema and annotations, covering the tool's purpose, dependency, and invocation pattern. It does not explicitly state what the function returns (e.g., a plot object), but for a visualization tool this is often implicit and not critical 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?

The input schema provides 100% coverage with descriptions for all seven parameters, including examples. The description's code examples reinforce usage but do not add new semantic meaning beyond what the schema already offers, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Create a scatter plot from data points' with a specific verb and resource, and the examples reinforce the use case. It distinguishes itself from sibling plot types like line chart, histogram, and box plot by explicitly naming 'scatter plot'.

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

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

The description implies usage through examples (passing x_data and y_data arrays) but does not explicitly state when to prefer this over alternatives like plot_line_chart or plot_histogram. No exclusions or alternative recommendations are given.

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

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

The annotations already declare the tool as read-only and idempotent, so the description does not need to cover those safety aspects. It adds value by mentioning 'previously saved' and 'Access across sessions,' indicating persistence behavior beyond the schema. No contradictions with annotations are present.

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 a single defining sentence followed by two helpful examples. Every sentence earns its place, and the overall length is appropriate for the tool's simplicity.

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 load tool with one parameter, an output schema, and annotations covering read-only and idempotent behavior, the description is complete. It explains the tool's purpose, provides usage examples, and notes cross-session access. No critical missing information is apparent.

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 already documents the only parameter, 'name,' with a clear description and example. The tool description also provides examples ('portfolio_return', 'circle_area'), reinforcing the expected format. Since schema coverage is 100%, the description adds no fundamentally new semantic information beyond what the schema already provides, but it does not need to.

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 function: 'Load previously saved calculation result from workspace.' It uses a specific verb (load) and resource (variable from workspace), and the examples ('load_variable("portfolio_return")') reinforce its purpose. It also distinguishes itself from the sibling tool workspace_save by focusing on retrieving saved results.

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

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

The description provides clear context: this tool is for retrieving previously saved calculation results, and the examples show typical variable names. It implies usage after workspace_save and across sessions, though it does not explicitly state when not to use it or name alternatives. The context is sufficient for an agent to choose this tool over calculation 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?

The description adds the behavioral detail that the workspace is 'persistent (survives restarts)', which is not captured in the annotations. The annotations (readOnlyHint=false, idempotentHint=false) already indicate a non-read, non-idempotent operation, so the description adds useful context about persistence. No contradiction.

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

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

The description is two sentences with examples, clearly front-loaded with the purpose statement. Every sentence serves a purpose, and the examples are concise and illustrative without redundancy.

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

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

For a simple save tool with a complete schema and an output schema, the description covers the key aspect (persistence) and does not need to explain return values. It could mention overwrite behavior or error cases, but these are not essential for basic understanding. The description is sufficient for the tool's complexity.

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

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

The input schema provides descriptions for all three parameters (name, expression, result) with 100% coverage, so the baseline is 3. The description's examples show sample values and ordering, but they do not add meaningful semantic detail beyond the schema's field 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 a specific verb ('Save') and resource ('calculation to persistent workspace'), with an added detail that it survives restarts. This distinguishes it from siblings like workspace_load and the calc_* tools.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies usage through the verb 'save' and the persistence note, but there is no explicit 'when to use' or mention of workspace_load as the counterpart. The examples illustrate usage but do not provide alternative guidance.

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