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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavior: what a match returns, that mismatches explain which dimensions differ, that units carrying values also yield a numeric result, and that errors name the offending input so it can be fixed and retried. Return-value shape is only sketched ('matches; otherwise explanation'), which keeps it from a 5.

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

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

Front-loaded with the two-mode split, then compact labeled examples; nearly every line carries information. The tradeoff is a slight telegraphic terseness (schema-style literals instead of prose) that may slow a first read but wastes no space.

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 five optional parameters, two operating modes, and no output schema, the description must carry mode selection and result shape — and it does both via examples plus the failure/explanation note. The remaining gap is precedence when conflicting parameter combinations are given, which matters for a zero-required-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by showing how expr/units/expect compose in a realistic call and by clarifying that the 'units' map values may embed magnitudes ('20 m'), a semantic the schema's 'Unit per variable, optionally with value' only hints at. It also constrains the symbol vocabulary (m, kg, N, J, km/h, m/s^2, dimensionless "1"), which the schema does not.

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

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

The description names two concrete operations — dimension checking of a formula and unit conversion — with worked JSON examples that make the resource ('units/dimensions of a physics/engineering formula') unmistakable. It does not, however, distinguish itself from the sibling verify_math, which an agent could plausibly confuse with this tool for formula checking.

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

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

It clearly delineates the two invocation modes by showing which parameter set selects which ('Check: {expr, units, expect}' vs 'Convert: {value, to}'), which is the main usage decision. It stops short of stating when to prefer verify_math or plot_function instead, and doesn't say what happens if both expr and value are supplied.

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 only declare the generic non-read-only, non-destructive, closed-world profile; the description adds real behavioral detail beyond them, notably that pdf returns a first-page preview and that failures surface errors with TeX problems pinpointed on the `!` line. It stops short of saying what docx/pptx return or where files are written.

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 core action is front-loaded in the first clause, followed by a compact example and layout notes. It is dense and slightly telegraphic ("On failure: follow errors") but nearly every sentence carries information an agent needs.

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 five parameters, a 20% schema coverage, and no output schema, the description does the heavy lifting on format/layout semantics and error handling. It leaves minor holes: no explanation of the `name` parameter and no statement of the return payload for docx/pptx.

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 only 20%, so the description must compensate, and it does: it explains what markdown may contain, the meaning of each format choice, and the structural contract implied by each layout value. The `name` parameter and the `title` parameter are only touched indirectly (title appears in the example, name is never explained), leaving a small gap.

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

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

States a specific verb and resource (save markdown as pdf/docx/pptx) and enumerates the supported content types (math, images, tables). It also implicitly separates itself from the render_*/plot_* siblings by naming them as the source of image paths rather than as alternatives for this task.

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

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

Gives conditional guidance for choosing a layout: cheatsheet means one A4 page in pdf, exam expects a problems section followed by an answers heading, flashcards means a two-column table in pdf. It does not state when to prefer this tool over siblings like read_document or get_template, so tool-selection guidance is absent even though configuration guidance is strong.

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 openWorldHint=false, so safety is covered. The description adds useful behavior the annotations do not: an empty name degrades to a listing operation, and there is a defined failure-recovery path. It does not describe the shape of a returned example (e.g. full TikZ source vs. summary), which is the main remaining gap for a tool with no output schema.

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

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

Three short, front-loaded lines with no filler: purpose, example, failure recovery. The telegraphic phrasing ("No name: list them") is slightly clipped and the example sits before the parameter rule it illustrates, but nothing is wasted.

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 one-parameter, read-only lookup with no output schema, the description covers purpose, the empty-argument case, and error recovery — enough to invoke it correctly. What return values actually look like is only implied by "examples... to adapt", which is a minor gap given the tool's simplicity.

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 documents the single parameter as "category/name; empty = list". The description's example call {"name": "circuits/rc_series"} and the "No name: list them" line restate that same semantics rather than adding new information, so this sits at the baseline.

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

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

The description states a specific verb and resource ("Read verified figure examples") and enumerates the covered domains (circuits, physics, math, diagrams). It also positions the tool relative to a named sibling, render_tikz, so an agent can distinguish the read/reference side from the render side without opening either schema.

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

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

It gives a clear moment of use ("to adapt before render_tikz") and covers two edge conditions: no name means list everything, and on failure pick an exact name from the list. It stops short of stating when this tool should NOT be used or naming any alternative beyond the sequencing with render_tikz.

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/openWorldHint/destructiveHint, and the description adds substantial context beyond them: the download side effect of saving a file to the materials folder, the credential model (token or calendar URL, never a password), the reduced capability of calendar-only connections, and a prompt-injection warning that LMS text is third-party data. That last point is a real behavioral safeguard an agent could not infer from the schema.

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

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

Front-loaded with the core purpose, then scoped per action in short lines, ending with the error path and an example. Every line carries information, though the clipped phrasing ('Calendar URL only (no token): deadlines only') is slightly terse and could be clearer at the cost of a few 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?

No output schema exists, but the description names the data domains returned (courses, deadlines, announcements, file listings) and explains the download artifact and its handoff to read_document. Setup prerequisites, error handling, and injection safety are all covered; only exact return fields and pagination remain unspecified, which is acceptable for a read-only aggregator.

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 75% and already documents days (1-120), item and course, so the baseline is already high; the description still adds meaning by tying each parameter to specific actions (download needs course + item, course is an id or name fragment, schools uses the school name). The worked example JSON reinforces the action/days pairing.

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?

Opens with a specific verb and resource: read-only access to the user's school LMS, naming the platforms (Canvas/LearningX, Moodle/Coursemos) and the four data types (courses, deadlines, announcements, files). It also states what the tool will never do ('Never submits or posts'), which separates it from any write-capable sibling and from read_document, which it hands downloaded files to.

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

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

Gives per-action guidance: 'schools' works without setup, calendar-URL-only connections yield deadlines only, download requires course + item from action='files'. It also covers the failure path, telling the agent to relay setup steps and never ask for a password. The only gap is that it doesn't explicitly state when to prefer a sibling over this tool beyond the implicit read_document handoff.

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=false, destructiveHint=false, openWorldHint=false, and the description adds error behavior ('errors name the series/column/row; fix it and call again') plus the statistical content of the result. However it never says what the call actually produces or writes, which matters because a non-read-only tool with a `name` ('File name') parameter presumably creates a file.

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

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

Front-loaded purpose sentence, then a compact JSON example, then the table alternative and the fit list; no filler sentences. The density of punctuation-separated clauses makes it slightly harder to scan than an ideally structured description.

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 13-parameter tool with no output schema, the description covers the two input paths, fit options, and failure recovery, which is substantial. It omits the return artifact (image path/reference) and the log-axis and labeling parameters, leaving real gaps for a moderately complex tool.

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

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

With only 54% schema coverage, the description compensates on the highest-risk parameters: it shows the `series` element shape (x, y, yerr), enumerates the fit modes, and explains the non-obvious table semantics (column selection by header name, and that '2.3 ± 0.1' means value ± error). It still leaves log_x/log_y, title, per-series fit override, and exact xerr/yerr forms undocumented.

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

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

States a specific verb and resource ('Plot measured data') plus the outputs it produces (error bars, fitted equation with standard errors, R²) and its intended use ('For lab reports'). The scoping word 'measured' implicitly separates it from plot_function, but no sibling is named explicitly, so it falls just short of a 5.

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

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

Gives a concrete worked example for the series path and an explicit alternative input path ('Or paste CSV/markdown table text in `table` and pick columns by header name'), plus enumerated fit modes. It lacks explicit when-not-to-use guidance versus plot_function or render_tikz.

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 only say the call is non-read-only, non-destructive, and closed-world; the description adds real value beyond that by disclosing that asymptotes, jumps, and domain gaps surface as warnings, that a preview is produced, and that errors identify the offending series and character. It still doesn't say where the file lands or what the preview contains.

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

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

Front-loaded with purpose, then example, then syntax rules, then failure handling – a logical order with no filler sentences. The telegraphic fragments ('expr: sympy syntax in x') are dense but readable; a little more connective wording would help without adding length.

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 an 8-parameter plotting tool with no output schema, the description covers formats, warnings, syntax, and error recovery, which is most of what an agent needs. It leaves the overlay 'points' parameter and the meaning of 'preview' unexplained, which are the main remaining gaps.

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

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

With 50% schema coverage, the description compensates on the highest-risk parameters: it documents sympy expression syntax for series[].expr with concrete tokens (x**2, sqrt, log=ln, pi, e), shows x_range accepting strings like "4*pi", and explains $...$ label formatting. The remaining params (name, title, points, y_range) are left to the schema, which describes them only thinly.

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

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

States a specific verb and resource (plot y = f(x)), names the output formats (SVG, PNG, PDF) and the preview, and explicitly contrasts itself with the sibling plot_data for measured data. An agent can distinguish it from plot_data and render_tikz without opening either schema.

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

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

Explicitly routes measured-data cases to plot_data and provides a runnable example call plus a retry instruction on failure ('fix it and call again'). It does not distinguish itself from other siblings like render_tikz or export_document, so the routing guidance is clear but not exhaustive.

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 openWorldHint=false, and the description adds the meaningful constraint that access is sandboxed to the materials folder plus the exact failure behavior for out-of-folder or unsupported files. It does not state whether listing includes file sizes or how part boundaries are computed, so it stops short of full behavioral disclosure.

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

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

Terse, front-loaded lines: purpose first, then the no-path case, then PDF paging, image mode, long-text paging, a concrete example, and failure handling. Every line carries information, though the telegraphic fragments ("No path: list files") are slightly terse for a first-time reader.

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

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

With no output schema, the description does the work of indicating what comes back (a file listing, page images, paginated text), which covers the main return shapes for a four-parameter read tool. Remaining gaps are minor: whether image mode returns paths or inline images, and how large a part is.

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 only 50% (path and pages are documented, mode and part are not), but the description compensates by explaining that mode="images" returns page images and that part=2, 3… pages through long text. It adds real meaning beyond the schema, though the enum semantics of mode="text" and how part interacts with pages are left implicit.

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 ("Read files the user put in the materials folder") and enumerates the exact supported formats (PDF, HWP/HWPX, docx, pptx, xlsx, txt/md/csv, png/jpg). None of the siblings (render_tikz, plot_data, export_document, etc.) do file reading, so the boundary is 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?

It gives explicit branch conditions: empty path lists files instead of reading, pages syntax for PDFs, mode="images" for scans and formula-heavy pages, part=N for long text. It also supplies a when-not path ("outside the folder or unsupported → ask the user to put the file there or save it as PDF"), which is unusually complete routing guidance.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses the produced artifact formats, that formula and molecular weight are returned for self-checking, and the shape of error messages (atom #index, ^ marker) plus the expected retry behavior. That is real behavioral context an agent could not infer. It doesn't say whether files are written to disk or where, which is the main remaining gap for a non-read-only tool.

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

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

Four short lines, front-loaded with the verb and input format, then an example, a verification rule, and a failure protocol. The inline JSON example earns its space. Minor redundancy: the reaction notation is repeated from the schema's smiles description.

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?

There is no output schema, so the description's mention of SVG/PDF/PNG output, preview, formula, and molecular weight is necessary and present, as is error-handling guidance. What's missing is where output files land and what `kind` toggles behaviorally; those leave a small residual gap for a 5-parameter tool.

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

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

Schema coverage is 60%, and the description adds meaning for the key parameter by spelling out the reaction syntax (reactants>>products) and showing a legend usage in the example. However, `kind`, `name`, and `show_atom_numbers` carry no explanation in either place, so the description only partially compensates for the coverage gap.

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

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

The description names a concrete verb and resource ("Draw a molecule or reaction from SMILES") and enumerates outputs (SVG/PDF/PNG, preview, formula, molecular weight). It also excludes a common wrong input with "(not a name)". It does not explicitly differentiate itself from the sibling render_tikz, so it stops short of a 5.

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

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

It sets a clear input condition (SMILES only, not a name), supplies a worked example, and prescribes a verification step ("Check that formula and mol_weight match the intended molecule"). The retry instruction on failure gives an explicit recovery loop. No guidance is given on when to prefer this over render_tikz or export_document.

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 only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false; the description adds real context beyond that — supported output formats, a returned preview image, auto-wrapping of bare \draw commands, and a precise error contract ('! line' plus 'l.N' = line N of your code). The phrase 'mostly automatic' for packages/libraries/labels is left vague, and it never says where generated files land despite readOnlyHint=false implying artifact creation.

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

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

Purpose is front-loaded, then domains, a runnable inline example, a verification checklist, and a failure-recovery rule — a sensible order with no filler sentences. It is dense but every block maps to a decision the agent must make; the only slack is the compressed 'mostly automatic' clause.

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 4-parameter tool with no output schema, the description covers what comes back (preview image plus SVG/PDF/PNG), how to prepare input (get_template), and how to recover from compile errors. The remaining gap is artifact lifecycle: with readOnlyHint=false and a `name` parameter, an agent still cannot tell where the compiled files are stored or whether export_document is needed to retrieve them.

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 baseline is 3, and most of the description's parameter-relevant content ('packages, libraries ... mostly automatic') merely restates the schema's own 'usually auto-detected' notes. The one genuine addition is that bare \draw commands get wrapped, which expands what the agent knows it may pass as `code` — useful, but thin overall.

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

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

The first sentence gives a concrete verb and resource ('Compile TikZ/circuitikz/pgfplots/chemfig code into a figure') plus concrete output formats and the returned artifact (preview image). The following sentence ('For circuits, free-body diagrams, vectors, geometry, block diagrams') implicitly separates it from plotting siblings like plot_function/plot_data, but it never names those alternatives, so the differentiation is by inference rather than explicit.

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?

'Adapt a similar example from get_template first' gives an explicit prerequisite workflow naming a real sibling tool, and the closing line tells the agent what to do after failure ('fix it and call again'). What is missing is a negative rule: no statement of when NOT to use this (e.g. use plot_function for function graphs, render_molecule for structures), which is the main ambiguity against this sibling set.

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 indicate read-only and closed-world, and the description adds substantial behavioral detail: it computes via sympy, does not solve, reports 'unknown' with numeric checks, provides counterexamples for mismatches, and describes error and timeout handling. This goes well 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 dense but well-organized, with a clear opening, an enumerated ops list, an example, and syntax notes. It is appropriately sized for a tool with 14 operations and 13 parameters, though the ops list is somewhat run-on and could benefit from slightly more 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?

Given the tool's complexity (14 ops, 13 params, no output schema), the description is thorough: it covers all operations, their parameter usage, syntax rules, constants, error handling, and return semantics for key ops. No critical gaps remain for an agent to invoke it correctly.

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

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

Despite 77% schema coverage, the description extensively documents how each parameter applies to specific operations (e.g., var for solve/diff/ode, bounds for sum, against for equal/ode, dist for probability). It adds op-specific meaning and syntax examples that enrich the schema.

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

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

The description clearly states the tool's purpose: 'Check math with sympy: a solution step, or whether an answer equals a reference in another form. You solve; this only computes.' It distinguishes from a solver and from sibling tools like plotting or rendering by specifying computational verification.

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

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

It provides clear context on when to use it: for checking math expressions or answers, not for solving. It implies boundaries with 'You solve; this only computes' and gives guidance on failure and timeouts. However, it does not explicitly name alternatives or when to avoid it beyond the solve/compute distinction.

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