Math MCP Learning

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

Adds 'Safely evaluate' implying sandboxing/security constraints, and lists specific supported functions/operations beyond what annotations provide; no contradictions with readOnly/idempotent hints.

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 clear sections (purpose, supported ops, note, examples); front-loaded with core verb; every sentence provides distinct 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?

Fully complete for a single-parameter tool; covers purpose, constraints, sibling differentiation, and examples without needing to describe return values (output schema exists).

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 100% schema coverage, adds valuable input/output examples in description text that demonstrate expected expression formats and return 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?

Explicitly states 'evaluate mathematical expressions' with specific supported operations, and clearly distinguishes from calc_statistics sibling by noting when to use the statistics tool instead.

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

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

Explicitly states when to use ('evaluate a single mathematical expression') and when not to use ('To compute descriptive statistics... use the statistics tool instead'), naming the specific 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?

Adds mathematical formula explaining the computation logic beyond annotations, though doesn't mention other behavioral traits like precision limits or performance characteristics.

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 formula explanation followed immediately by examples; every section serves a distinct purpose 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?

Appropriately complete for a calculation tool with existing output schema; formula and examples provide sufficient context for 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?

Examples illustrate parameter mapping and usage patterns (e.g., optional compounds_per_year), adding practical context to the 100% 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?

Clearly states it calculates compound interest for investments with specific formula, distinguishing it from general calc_expression and matrix tools, though doesn't explicitly contrast with simple interest.

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 implied usage through concrete examples showing different parameter combinations, but lacks explicit when-to-use/when-not-to-use guidance versus alternatives like calc_expression.

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 cover read-only/idempotent traits; description adds scope context (descriptive statistics vs single expressions) without contradicting structured hints.

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 front-loaded purpose, bulleted operations, clear Note section, and concise examples—every sentence earns its place.

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

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

Given the simple 2-parameter schema and presence of output schema, the description provides complete usage context without unnecessary verbosity.

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, baseline is met; examples in description add semantic value by demonstrating valid parameter combinations and return formats.

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

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

Clear verb-resource pair ('perform statistical calculations on a list of numbers') and explicitly distinguishes from calc_expression sibling via the Note section.

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

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

Explicitly states when to use ('compute descriptive statistics over a list of numbers') and when not to use ('To evaluate a single mathematical expression, use the calculate tool 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?

Adds minimal behavioral context beyond annotations (read-only, idempotent); omits details about precision, rounding behavior, or error responses for unsupported unit combinations.

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 clear header, categorized bullet list of units, and concrete code examples; no redundant or filler 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?

Comprehensive coverage of supported units and categories; sufficient given the presence of an output schema, though could note temperature conversion formula differences.

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 100% schema coverage, the embedded code examples effectively demonstrate parameter ordering and valid string formats for unit abbreviations.

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

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

Clear purpose ('Convert between different units') with specific unit categories listed, distinguishing it from mathematical calculation siblings like calc_expression and 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?

Usage is implied through examples and supported unit list, but lacks explicit guidance on when to prefer this over calc_expression for unit-related math or error handling for invalid conversions.

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 valuable behavioral context beyond annotations: it discloses the NumPy dependency and ValueError on unavailability, which annotations don't cover. While annotations already indicate read-only, idempotent, and closed-world behavior, the description provides practical implementation details that help the agent understand runtime constraints.

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?

Perfectly structured with a clear purpose statement followed by a note about dependencies and practical examples. Every sentence earns its place: the first defines the tool, the note warns about requirements, and examples demonstrate proper invocation. 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?

Complete for a mathematical computation tool with good annotations and output schema. The description covers purpose, dependencies, error conditions, and provides examples. With annotations covering safety properties and output schema presumably defining the return value, no additional information is 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?

With 100% schema description coverage, the schema already fully documents the single 'matrix' parameter. The description doesn't add parameter semantics beyond what's in the schema, but the examples provide concrete usage patterns that complement the schema's technical specification.

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 specific action ('Calculate the determinant') and resource ('of a square matrix'), distinguishing it from sibling tools like matrix_inverse or matrix_eigenvalues. It precisely defines the mathematical operation without ambiguity.

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

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

The description provides clear context by specifying it's for square matrices and noting the NumPy dependency, but doesn't explicitly state when to use this versus alternatives like matrix_eigenvalues for other matrix properties. The examples help illustrate proper usage scenarios.

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

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

The description adds valuable behavioral context beyond annotations by specifying the NumPy dependency and ValueError condition, which annotations don't cover. While annotations already indicate read-only, non-open-world, and idempotent behavior, the description usefully supplements with implementation details. No contradiction with annotations exists.

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

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

The description is perfectly structured with a clear purpose statement upfront, followed by a concise note about dependencies, and relevant examples. Every sentence adds value with no wasted words, making it easy for an agent to parse quickly.

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

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

Given the tool's mathematical nature, comprehensive annotations (readOnlyHint, idempotentHint), 100% schema coverage, and existence of an output schema, the description provides complete context. It covers purpose, dependencies, error conditions, and examples—sufficient for an agent to understand 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?

With 100% schema description coverage, the schema fully documents the matrix parameter including format, constraints, and examples. The description doesn't add parameter semantics beyond what's in the schema, maintaining the baseline score of 3 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 clearly states the specific action ('calculate') and resource ('eigenvalues of a square matrix'), distinguishing it from sibling tools like matrix_determinant or matrix_inverse. It precisely defines the mathematical operation without being vague or tautological.

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 implied usage through the examples showing diagonal matrices, but lacks explicit guidance on when to use this tool versus alternatives like matrix_determinant or when eigenvalues are appropriate versus other matrix operations. No explicit when-not-to-use or alternative recommendations 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it discloses the NumPy dependency and potential ValueError if unavailable, which are important implementation details not covered by annotations.

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

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

The description is perfectly structured: a clear purpose statement followed by a note about dependencies and concrete examples. Every sentence serves a distinct purpose with zero redundancy, making it easy to scan and understand.

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 mathematical nature, comprehensive annotations (readOnly, idempotent), 100% schema coverage, and existence of an output schema, the description is complete. It covers purpose, dependencies, error conditions, and examples—everything needed for an agent to use this tool correctly.

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

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

Schema description coverage is 100%, with the schema fully documenting the 'matrix' parameter format and constraints. The description doesn't add parameter details beyond what's in the schema, but provides helpful examples showing valid input formats, which slightly enhances understanding.

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 specific action ('Calculate the inverse') and resource ('square matrix'), distinguishing it from sibling tools like matrix_determinant or matrix_transpose. It precisely defines the mathematical operation without ambiguity.

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

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

The description provides clear context by specifying it's for square matrices and mentioning NumPy dependency, which helps determine when to use it. However, it doesn't explicitly state when NOT to use it (e.g., for non-square matrices) or name alternatives like matrix_determinant for related operations.

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 valuable behavioral context beyond annotations: it specifies a dependency requirement (NumPy) and error behavior (raises ValueError if unavailable). Annotations already indicate readOnlyHint=true, openWorldHint=false, and idempotentHint=true, but the description provides practical implementation details that help the agent understand runtime constraints.

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 perfectly structured: a clear purpose statement followed by a note about requirements and examples. Every sentence earns its place, with no redundant information. The examples are directly relevant and demonstrate different use cases without unnecessary elaboration.

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 mathematical nature, complete schema coverage, comprehensive annotations, and the presence of an output schema (which handles return values), the description provides exactly what's needed. It covers purpose, prerequisites, and examples without duplicating information available elsewhere in the structured data.

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 description coverage, the input schema already fully documents both parameters (matrix_a and matrix_b) with examples and constraints. The description doesn't add additional parameter semantics beyond what's in the schema, but provides usage examples that reinforce the parameter format. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the specific action ('Multiply two matrices') and distinguishes it from sibling tools like matrix_determinant, matrix_inverse, and matrix_transpose. It provides the mathematical operation (A × B) and includes examples showing different matrix dimensions, making the purpose unambiguous and well-differentiated.

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 states when NOT to use this tool ('Requires NumPy. Raises ValueError if NumPy is unavailable'), providing clear prerequisites. However, it doesn't explicitly guide when to choose this tool over alternatives like calc_expression for general calculations or other matrix operations, though the purpose clearly indicates it's for matrix multiplication specifically.

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 valuable behavioral context beyond annotations: it discloses the NumPy dependency requirement and the ValueError that occurs when NumPy is unavailable. Annotations already indicate this is a read-only, non-destructive, idempotent operation, but the description provides implementation-specific details that help the agent understand runtime behavior.

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

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

The description is well-structured with a clear purpose statement followed by a note and examples. The note about NumPy dependency is essential, but the examples could be more concise. Overall, most content earns its place, though slightly verbose in the examples section.

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, 100% schema coverage, comprehensive annotations, and the presence of an output schema, the description is complete. It covers the core operation, dependencies, error conditions, and provides illustrative examples—sufficient for an agent to understand and invoke this tool correctly.

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

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

With 100% schema description coverage, the input schema fully documents the 'matrix' parameter structure, constraints (maxItems: 10000), and format. The description adds minimal value beyond the schema, only reinforcing through examples what the schema already specifies about the 2D array format.

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

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

The description clearly states the specific action ('transpose a matrix') and defines what that means ('swap rows and columns'). It distinguishes this tool from sibling matrix tools like matrix_determinant, matrix_inverse, and matrix_multiply by focusing exclusively on transposition.

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 implied usage through the examples showing 2D arrays, but lacks explicit guidance on when to use this tool versus alternatives. No context is given about when transposition is needed versus other matrix operations available in sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about the matplotlib dependency, which isn't captured in annotations, but doesn't mention output behavior (e.g., display vs. save) or potential errors.

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 appropriately sized with two sentences: a clear purpose statement and two concise examples. It's front-loaded with the core functionality, though the examples could be slightly more streamlined.

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 moderate complexity, 100% schema coverage, and annotations covering safety/idempotency, the description is reasonably complete. It lacks output details (no output schema) and deeper usage context, but the dependency note and examples provide adequate guidance for basic 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 description coverage is 100%, so parameters are fully documented in the schema. The description's examples illustrate usage of data_groups and group_labels/title, but don't add meaningful semantic details beyond what the schema already provides.

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

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

The description clearly states the specific action ('Create a box plot') and resource ('for comparing distributions'), with explicit mention of the dependency ('requires matplotlib'). It distinguishes from sibling tools like plot_histogram or plot_scatter by specifying the exact chart type.

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

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

The description provides no guidance on when to use this tool versus alternatives like plot_histogram or plot_scatter. It includes examples but offers no explicit when/when-not instructions or comparisons to 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?

The description adds valuable behavioral context beyond annotations. While annotations indicate readOnlyHint=true (safe operation), openWorldHint=false (deterministic), and idempotentHint=true (repeatable), the description adds that it 'Creates realistic price movement patterns for educational purposes' and 'Does not use real market data' - important behavioral constraints not captured in annotations. No contradiction with annotations exists.

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

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

The description is well-structured and appropriately sized. It front-loads the core purpose, follows with important constraints, provides usage guidance in a dedicated 'Note:' section, and includes practical examples. Every sentence serves a distinct purpose with zero waste or redundancy.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description provides good contextual completeness. It covers purpose, constraints, usage guidelines, and examples. The main gap is lack of information about the output format (what kind of plot is generated, whether it's displayed or saved), but with annotations covering safety and determinism, and schema covering all parameters, it's 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?

With 100% schema description coverage, the baseline is 3. The description provides example usage that illustrates parameter combinations ('plot_financial_line(days=60, trend='bullish')'), which adds practical context beyond the schema's technical descriptions. However, it doesn't add significant semantic meaning about individual parameters beyond what the schema already documents.

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: 'Generate and plot synthetic financial price data' with specific verbs (generate, plot) and resource (financial price data). It distinguishes from siblings by specifying 'for educational purposes' and 'Does not use real market data', differentiating it from potential real-data tools. The explicit mention of 'requires matplotlib' adds implementation context.

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

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

The description provides explicit guidance on when to use this tool vs alternatives. The 'Note:' section states 'Use for time-series price data with optional moving average overlay' and explicitly names the alternative: 'For general XY data, use plot_line_chart instead.' This gives clear boundaries for tool selection and references a specific sibling tool.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, indicating safe, deterministic operations. The description adds valuable context about the matplotlib dependency, which isn't captured in annotations, but doesn't disclose other behavioral traits like error handling, performance limits, or output format details.

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

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

The description is front-loaded with the core purpose, followed by concise examples that reinforce usage without unnecessary elaboration. Every sentence earns its place by providing actionable information, and the structure is efficient for quick comprehension.

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 moderate complexity (mathematical plotting), rich annotations (safety and determinism hints), and 100% schema coverage, the description is mostly complete. However, without an output schema, it lacks details on return values (e.g., image format, error responses), leaving a minor gap in contextual 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?

Schema description coverage is 100%, so the schema fully documents parameters. The description provides examples that illustrate usage but doesn't add semantic meaning beyond what the schema already specifies (e.g., expression format, x_range as tuple). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Generate mathematical function plots') and the resource ('mathematical function plots'), distinguishing it from sibling plotting tools like plot_box_plot or plot_scatter by specifying it's for mathematical functions. The examples reinforce this specificity.

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

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

The description provides clear context for when to use this tool (for mathematical function plots) and mentions a prerequisite ('requires matplotlib'), but doesn't explicitly state when not to use it or name alternatives among the sibling tools (e.g., plot_line_chart for non-mathematical lines).

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

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

Adds valuable dependency context ('requires matplotlib') beyond annotations, but fails to disclose output format or side effects given no output schema exists.

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

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

Extremely compact and front-loaded; examples earn their place by showing valid syntax, though a brief output description would improve structure.

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?

Critical gap: no output schema exists and description fails to specify what the tool returns (file path, base64 image, or direct display).

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 100% schema coverage, the concrete examples effectively demonstrate parameter interactions (bins=5, title=...) that pure descriptions cannot convey.

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 creates statistical histograms with specific verb and resource, distinguishing it from sibling plotting tools like plot_line_chart or plot_scatter.

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 usage examples but lacks guidance on when to select this over similar visualization siblings like plot_box_plot or plot_function.

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 valuable context beyond annotations by stating 'requires matplotlib' (dependency requirement) and providing concrete usage examples. While annotations already cover readOnlyHint=true, openWorldHint=false, and idempotentHint=true, the description enhances understanding with practical implementation details.

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 perfectly structured with a clear purpose statement, important note about usage context, and practical examples. Every sentence serves a distinct purpose with zero wasted words, and information is front-loaded appropriately.

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 visualization tool with comprehensive annotations and full schema coverage, the description provides excellent context about when to use it versus alternatives and practical examples. The main gap is the lack of output schema, but the description compensates well with implementation guidance.

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 description coverage, the input schema already documents all 7 parameters thoroughly. The description provides examples showing parameter usage (e.g., title='Squares', color='red', x_label='Time') but doesn't add significant semantic meaning beyond what's in the 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's purpose with specific verb ('Create') and resource ('line chart from data points'), and explicitly distinguishes it from its sibling plot_financial_line by stating 'Use for general XY data' versus 'time-series price data with optional moving average'.

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

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

The description provides explicit guidance on when to use this tool ('Use for general XY data') and when to use an alternative ('For time-series price data with optional moving average, use plot_financial_line instead'), clearly differentiating between 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?

Adds useful dependency note ('requires matplotlib') beyond annotations, but omits output format and side effect details.

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?

Appropriately brief and front-loaded with purpose statement followed by illustrative examples; no wasted 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?

Adequate for inputs but missing output description (image format, file path return) which would be helpful given no output schema exists.

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% description coverage; description provides redundant examples without adding semantic 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?

Clear verb ('Create') and resource ('scatter plot'), but lacks explicit differentiation from sibling plotting tools like plot_line_chart or plot_histogram.

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 usage for correlation studies, but no explicit when-to-use guidance or comparison to alternative visualization 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?

Adds valuable persistence context ('Access across sessions') beyond annotations, confirming data survives session boundaries.

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, front-loaded action statement with efficient examples that 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?

Adequate for simple single-parameter tool; mentions persistence and provides examples, though could explicitly reference workspace_save relationship.

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, baseline is 3; examples illustrate usage but don't add semantic meaning beyond the schema's own 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?

Clear verb ('Load') and resource ('Variable' from 'workspace'), distinguishes from calculation/plotting siblings, though doesn't explicitly contrast with workspace_save.

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 usage context but lack explicit when/when-not guidance or reference to workspace_save as the paired 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?

Adds crucial persistence context ('survives restarts') beyond annotations, clarifying durability without contradicting idempotentHint:false.

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 with clear front-loaded purpose statement; examples earn their place but description is minimally sufficient.

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 simple 3-parameter tool with complete schema and output schema present, though lacks cross-reference to workspace_load retrieval workflow.

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% establishing baseline 3; examples illustrate usage but description prose adds no new parameter semantics.

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

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

States specific action (save) and resource (calculation to persistent workspace), with parenthetical distinguishing persistence from ephemeral calculation 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?

Provides examples but offers no explicit guidance on when to use versus calculation tools or workspace_load sibling.

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