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

Annotations already carry the behavioral profile (idempotent, non-destructive, not read-only, closed-world), and the description adds nothing beyond what those flags say. Notably it does not explain why readOnlyHint is false for what read like pure computations, nor how the session/workspace state is affected.

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

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

Two sentences, zero filler, with purpose stated first and the routing hint second. Every clause 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?

Output schema exists, so return values need not be described, and params are fully covered by the schema. Minor gap: the operation enum includes 'reduce', which the description omits, and the non-read-only annotation is left unexplained.

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 documents session, operation, expression, and num_variables on its own. The description adds only loose mapping of operation names and 'Boolean expression', which is baseline-level value over 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?

Names a specific domain ('Boolean polynomials over GF(2)') and enumerates the concrete operations (evaluate, list variables, degree, zero/one tests). It also explicitly separates itself from the nearest sibling by naming evaluate_sage, so an agent can distinguish the two 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?

'Prefer this over evaluate_sage for boolean algebra' gives an explicit routing rule with the condition that selects it. It stops short of stating when NOT to use it or naming other overlapping siblings (e.g. polynomial_ring_operation, number_theory_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?

Annotations supply the safety profile (idempotent, non-destructive, closed-world) but flag readOnlyHint=false, implying possible state effects, which the description never addresses. It also says nothing about session/workspace side effects, errors, or timeouts, so it adds little 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?

A single front-loaded sentence with no wasted words, action and return described together. It is arguably too terse for the tool's ambiguity, but as pure conciseness it is efficient.

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?

An output schema and detailed param schema exist, but the description still leaves a critical gap: why use this versus evaluate_sage, and whether evaluation mutates workspace state given readOnlyHint=false. For a tool in a crowded sibling cluster, that omission is significant.

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% and the session parameter is richly documented in the schema itself, so the baseline of 3 applies. The description adds no parameter-level meaning 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?

States a specific verb (Evaluate) and resource (SageMath expression) plus what it returns (numeric/string forms). However, it does not distinguish itself from the sibling evaluate_sage or evaluate_sage_streaming, which appear to overlap heavily.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to pick this over evaluate_sage, evaluate_sage_streaming, or verify_claim. The agent must infer the distinction from names alone.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is partly covered. The description does add the non-obvious behavioral fact that the worker is restarted, but it never says what that restart destroys (in-memory variables, session state) or whether the workspace survives, which is the key question for a destructive operation.

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

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

A single front-loaded sentence with zero filler. It earns its place, though it is arguably under-specified rather than optimally concise given the tool's destructive nature.

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?

An output schema exists and the sole parameter is fully documented in the schema, but the description is the only place an agent could learn how this differs from the three sibling session-control tools, and it omits that entirely. For a destructive tool in a dense sibling cluster, this is materially incomplete.

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% and the session parameter is documented in exhaustive detail in the schema itself (name vs. portable handle, bearer-credential warning). The description contributes nothing about the parameter, so the baseline 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?

States a specific verb (cancel) plus resource (running Sage computation) and adds the secondary effect of restarting the worker, so the agent knows what happens. However, it does nothing to distinguish itself from the nearly identical siblings interrupt_sage_session, stop_sage_session, and reset_sage_session.

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?

There is no when-to-use guidance and no mention of alternatives, which is a serious gap given four sibling tools (cancel/interrupt/stop/reset) that look interchangeable from the name alone. The agent is left to guess which of these should be called to halt a runaway computation.

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?

Goes beyond the annotations by disclosing the worker start/reuse side effect (which explains why readOnlyHint=false despite being a probe) and the notable behavior that failures are returned in the result rather than raised. Does not mention auth or rate-limit characteristics, but adds meaningful context the annotations do not carry.

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?

One dense sentence that front-loads the action sequence and closes with the key safety guarantee. No filler or restatement of the name.

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?

An output schema exists, so return details need not be explained. Description covers behavior, side effects, and failure semantics adequately; only minor gaps such as what readiness/latency fields mean are absent.

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% and the single 'session' parameter is fully documented in the schema, so the baseline is 3. The description only echoes the workspace concept without adding syntax or handle 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 a specific verb (probe) plus the exact action sequence (starts/reuses worker, evaluates 1+1, reports readiness and latency). This is clearly distinguishable from siblings like evaluate_sage or start_sage_session.

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 'always safe to call' and 'works right now' imply preflight/diagnostic usage, but no sibling alternative is named and no explicit when-not condition is given. Usage is inferable rather than stated.

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

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

Annotations declare idempotent=true, destructive=false, openWorldHint=false, and readOnlyHint=false. The description adds domain scope but no behavioral details beyond annotations, such as workspace state effects or session handling. With annotations covering the safety profile, 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?

Two sentences, front-loaded with the tool's purpose and immediately followed by sibling routing. No filler or redundant text.

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

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

Output schema exists, so return values need not be explained. Annotations cover safety and idempotency. The description is complete for calling the tool, though it could clarify whether code_type accepts arbitrary Sage constructors or only the named families.

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 by the schema. The description enumerates operations that match the schema enum and lists code families that match the schema examples, adding little beyond what is already structured.

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 domain (error-correcting codes) and enumerates the exact computed quantities: length, dimension, minimum distance, rate, generator matrix. It also names supported code families (Hamming, generalized Reed-Solomon) and explicitly distinguishes itself from evaluate_sage.

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?

Includes an explicit routing directive: 'Prefer this over evaluate_sage for code parameters.' This tells the agent exactly when to choose this tool over a sibling without requiring inference.

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 idempotentHint=true and destructiveHint=false, and the only behavioral statement in the description ('All return a single integer') duplicates what the output schema already conveys. The description never explains the readOnlyHint=false signal or the session/workspace state implications, both of which are non-obvious for a computation 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?

Two sentences, zero filler. The operation list is front-loaded and the routing advice is placed second where it is most actionable.

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 an output schema present, return-value explanation is unnecessary, and the description covers scope plus sibling routing adequately. It is only slightly incomplete in not touching on session/workspace state, though that is handled by the schema's session parameter description.

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

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

Schema description coverage is 100%, so n, k, session, and operation are already fully documented in the schema, including the decimal-string requirement and the workspace_token credential note. The description adds no parameter meaning of its own, which is acceptable at baseline 3 when 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 names the domain (combinatorics) and enumerates the exact operations available (binomial, permutations, combinations, partitions, factorial, Catalan, Fibonacci, Bell), so an agent knows precisely what it computes. It is not a bare tautology, but it lacks an explicit verb like 'compute' and leans on the sibling-tool sentence to establish what it actually does.

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 explicitly routes the agent away from evaluate_sage for these operation types, which is a concrete when-to-use rule with a named alternative. It does not state any when-not conditions or prerequisites (e.g., session requirements), so it falls short of the full 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 cover the safety profile (non-destructive, idempotent, not read-only), but the description adds nothing beyond them. It says nothing about how the session/workspace state is affected, which is notable given readOnlyHint=false and the workspace-scoping semantics documented only in 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?

A single efficient sentence with the verb and resource front-loaded and no wasted words. It is arguably under-specified rather than over-long, but structurally clean.

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?

An output schema exists, so return values need not be described, and the schema fully documents parameters. However, for a non-read-only symbolic operation with session-scoped state, the description is thin on behavior and use context.

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

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

Schema description coverage is 100%, so all four parameters (expression, variable, order, session) are already documented in the schema, including the order default and workspace/bearer-credential nuances. The description adds no parameter detail beyond that, which is the expected baseline when the schema does the work.

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 (differentiate) and resource (expression) with the scope qualifier 'with respect to a variable'. It is distinguishable from siblings like integrate_expression or limit_expression, though it never names them explicitly.

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

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

No guidance on when to use this versus integrate_expression or other symbolic tools, and no prerequisites mentioned. The only context is the scope qualifier 'with respect to a variable', which is implied usage at best.

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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context: it never mentions that sampling is stochastic, that operations run inside a session workspace (the session param implies state), or what authorization/credential concerns apply. For a tool that writes into a workspace and supports random sampling, this is a significant gap.

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?

A single front-loaded line with no wasted words; the operation list is efficient. However, its extreme brevity means it trades away useful detail rather than being optimally structured for a six-parameter tool.

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

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

An output schema exists, so return values need not be described, and the parameter docs are rich. But for a stateful, multi-operation tool with a session/workspace parameter and sampling behavior, the description omits how sessions persist and which operations require which parameters, leaving it only minimally adequate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description merely restates the operation names already enumerated in the operation param schema and adds no extra detail about x, n, or parameters beyond what the schema 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 names a specific resource (probability distributions) and enumerates the concrete operations supported (PDF, CDF, quantile, mean, variance, sampling), which maps directly to the required 'operation' parameter. It is clear what the tool does, though it does not distinguish itself from siblings like statistics_summary or evaluate_sage.

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?

There is no guidance on when to choose this tool over alternatives such as statistics_summary or evaluate_sage, nor any mention of prerequisites (e.g., that a session/workspace must exist). Usage is only implied by the operation list, leaving the agent to infer routing.

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 declare openWorldHint=false, idempotentHint=true, destructiveHint=false but readOnlyHint=false, which is non-obvious for a pure computation tool and is left unexplained by the description. The description adds nothing about workspace state creation, session scoping, or whether computation can modify a workspace, so it does not resolve that ambiguity.

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

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

Two sentences, zero filler. The output enumeration and the disambiguation against evaluate_sage are both front-loaded, and nothing is repeated for padding.

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 a full output schema, the description need not describe return values, and it correctly covers what is computed and the alternative tool. It is slightly incomplete on workspace/session side effects and the mixed readOnly/idempotent signal, but nothing essential to invoking the tool is missing.

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 phrase 'from Weierstrass coefficients' loosely ties to the coefficients parameter, but the operation list and coefficient format are already fully documented in the schema, so the description adds no new parameter meaning.

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?

Names a specific class of operation (Elliptic curves over Q) and enumerates the exact results returned: rank, torsion order, discriminant, j-invariant, conductor, generators. It also names the sibling it supersedes, so an agent can distinguish it from evaluate_sage 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 the agent: 'Prefer this over evaluate_sage for curve invariants.' That covers the primary alternative-selection decision. It does not state exclusions or when a generic evaluator would still be preferable (e.g. non-invariant computations), so it falls short of a full when/when-not pair.

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 declare the write/open/idempotency profile, and the description adds the sandbox policy the agent cannot infer: deny-by-default execution with imports, external CAS interfaces, and file/display/persistence calls refused. It also discloses the namespace-persistence behavior that fundamentally changes how the tool is used, plus the fact that dedicated tools cannot see session state.

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

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

Front-loaded correctly: purpose, then the LAST RESORT directive, then the overriding exception, then the routing lists. It is long, but the bulk is a routing index that directly serves tool selection; the trade-off is length rather than wasted sentences.

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?

An output schema exists, so return values need not be explained, and the description still supplies everything else an agent needs: execution policy, session persistence, timeout/latex flags' existence via schema, and precise routing versus ~35 siblings. Nothing material is missing for a code-execution tool of this 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?

Schema description coverage is 100% and parameter docs already cover code, session workspace semantics, timeout, want_latex, and capture_stdout. The description adds session-state context ('variables persist', 'builds on values defined earlier in the same session') but no per-parameter syntax or format guidance. Baseline 3 is appropriate when 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?

States a specific verb and resource ('Run SageMath code') plus the scope that matters most ('in a persistent session; variables persist across calls'). It then explicitly positions itself against its many siblings ('LAST RESORT for a single self-contained calculation'), so an agent can distinguish it from evaluate_sage_streaming, calculate_expression, and the domain-specific tools without opening any 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?

Names the when-not condition ('only for what those do not cover') and enumerates the alternative tools by category, then carves out the one case that overrides the steer: multi-step work where a built object must be revisited, because dedicated tools evaluate in a fresh namespace. Concrete example snippets show exactly what qualifies.

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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the safety profile. The description adds the streaming of print() output and notes final result behavior, which is useful beyond annotations, but omits side-effect details like workspace state mutation or timeout semantics. With annotations already covering safety, 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?

Two short sentences, front-loaded with the core action and then the distinguishing streaming behavior. Every sentence earns its place with no waste.

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?

An output schema exists, so return values needn't be explained. The description covers the distinctive streaming behavior, and session/timeout details are fully handled by the rich schema. It is complete enough for an agent to invoke correctly, though it could note side effects more explicitly.

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 already fully documents all three parameters. The description adds no parameter-level meaning beyond what is in the schema, making the baseline 3 correct.

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 (Execute) and resource (SageMath code), and distinguishes itself from the non-streaming sibling evaluate_sage by describing intermediate print() streaming. It does not name the sibling explicitly, but the streaming behavior is a clear differentiator.

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

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

No explicit guidance on when to use this tool versus evaluate_sage or other siblings. The streaming behavior implies a use case, but there is no when-to-use/when-not-to-use instruction or named 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds nothing beyond a bare verb — no note that expansion can blow up expression size, no mention that it operates within a workspace/session, nothing on the session persistence behavior that the schema itself warns about. With structured hints present, the bar is lower, but this description still adds almost no 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?

A single short sentence that is front-loaded and wastes no words. It is concise, though arguably under-specified rather than optimally concise.

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

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

With an output schema present, return values needn't be explained, but the description still fails to say what expansion produces, how it relates to session state, or why it differs from the numerous other symbolic-operation siblings. For a tool in a dense family with mutation-ish annotations (readOnlyHint=false), the description is incomplete.

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 'session' parameter has an unusually rich description (workspace scoping, portable handles, bearer-credential warning). The tool description adds nothing 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?

States a recognizable verb+resource ('Expand a mathematical expression'), which is clearer than a tautology. But it gives no differentiation from the many similar symbolic-operation siblings (simplify_expression, factor_expression, evaluate_sage), so an agent cannot easily tell why it should pick expand over them.

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

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

No statement of when to use this versus alternatives like simplify_expression or factor_expression, and no context about preconditions. The reader is left to infer everything about tool selection.

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

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

Annotations already provide the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds nothing beyond them. It does not explain that the tool operates within a session/workspace, whether results are stored, or how the odd readOnlyHint=false with idempotentHint=true combination manifests.

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?

A single front-loaded sentence with zero padding. It is efficient, though arguably too thin given the complexity of the sibling landscape it must be distinguished from.

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?

An output schema exists, so return values need not be described, and parameters are fully covered by the schema. The remaining gap is routing guidance against the many overlapping symbolic siblings, which the description does not address.

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 both parameters are documented in the schema, and the description only echoes the expression parameter. The session/workspace semantics are fully handled by 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?

States a specific verb and resource ('Factor a mathematical expression or integer'), and the 'or integer' clause usefully signals it handles numeric input as well as symbolic input. However, it does not distinguish itself from close siblings like simplify_expression or expand_expression, leaving the agent to infer the difference.

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?

There is no when-to-use guidance and no mention of alternatives, despite a large sibling set (simplify_expression, expand_expression, calculate_expression, solve_equation) that plausibly overlaps. The agent gets no signal about when factoring is the right operation versus those.

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 idempotent=true, destructive=false, and readOnlyHint=false. The description adds that the root is numeric and interval-bound, hinting at approximate/iterative behavior, but does not disclose failure modes, precision, or session side effects. This is modest additional context 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?

One efficient sentence, front-loaded with the core action and scope. There is no filler 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?

An output schema exists, so return values need not be explained. However, for a tool that overlaps with solve_equation, the description omits routing guidance and assumptions about numeric versus symbolic solving. It is adequate but leaves a notable 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%, so the schema already documents all five parameters, including bounds and session behavior. The description mentions expression/equation and interval but adds no syntax or precision details beyond the schema. Baseline 3 is appropriate when 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?

States a specific verb ('Find') and resource ('numeric root of an expression or equation') with an interval scope. It is clear on its own, but does not distinguish itself from the sibling solve_equation tool, which likely overlaps in finding solutions.

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 gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not say when to prefer find_root over solve_equation, nor when a numeric root is appropriate versus symbolic solving.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds no behavioral context about computation cost, numerical precision, or what the output contains. It doesn't contradict annotations, but adds little beyond them.

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

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

Two sentences, front-loaded with the core purpose and operation list, with the alternative routing as a compact second sentence. No waste.

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 read-only computational tool with full schema coverage and an output schema, the description provides adequate context. Missing only minor details like expected output format or edge-case behavior, but nothing 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?

Schema description coverage is 100%, so all parameters (points, session, operation) are documented in the schema. The description mentions 'point sets' which implies the points parameter, but adds no syntax, format, or constraint details beyond the schema. 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?

States a specific verb+resource (computational geometry on point sets) and enumerates the exact operations (euclidean distance, polygon area, polytope volume, convex hull vertices, convexity tests). This clearly distinguishes it from the broad evaluate_sage sibling.

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 names the preferred alternative: 'Prefer this over evaluate_sage for these.' However, it doesn't state when NOT to use it (e.g., for operations not in the list) or point to other geometry-specific siblings, leaving some inference to the agent.

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, idempotentHint=true, and destructiveHint=false, conveying the safety/mutation profile. The description adds that graphs are named and created within a session, but says nothing about state persistence, workspace scoping, or side effects beyond what annotations and the session param provide.

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?

A single compact sentence with the core purpose front-loaded and no wasted words. It is efficient, though the parenthetical operation list is partly redundant with the schema.

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

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

An output schema exists so return values need not be described, and the schema is fully documented. However, a multi-operation dispatcher tool benefits from stating when to pick which operation, and the description omits that routing context.

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

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

Schema description coverage is 100%, so the schema already documents graph, source, target, session, and operation comprehensively, including the shortest_path prerequisite. The description adds no parameter meaning beyond restating a few operation names, so the baseline 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?

States a specific verb+resource combination: 'create named graphs' and 'compute properties,' naming concrete operations like chromatic_number and diameter. It is clear this is a graph-theory dispatcher, though it doesn't contrast itself against a hypothetical graph sibling.

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

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

No guidance on when to use this tool versus alternatives, nor prerequisites (e.g., that shortest_path requires source and target, which only appears buried in the operation enum). The agent must infer usage entirely from the schema.

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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description corroborates the non-read-only nature by saying it 'constructs' groups, which plausibly mutates session/workspace state, but it never says whether constructed groups persist in the workspace, whether they consume named slots, or what happens on repeated calls. Given the annotation coverage, this is an acceptable but thin addition.

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?

One compact sentence with the domain front-loaded and the capability list immediately following. No filler, no restatement of the tool name.

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?

An output schema exists, so return-value documentation is not required, and all three parameters are richly described in the schema. What remains under-covered is behavioral: whether the group construction is ephemeral or persisted into the named session, and how a previously constructed group is referenced in later calls. For a simple constructor+query tool this is close to complete, but that persistence question is non-trivial.

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 group, session, and operation are already fully documented (including the session bearer-credential warning). The description's list of operations ('order, is_abelian, center, etc.') only loosely restates the schema's exact enumeration ('center_order', 'conjugacy_classes_count'), adding no syntax or semantics beyond the schema. Baseline 3 per the rules.

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 concrete verb set ('construct groups and query properties') and the domain resource (group theory), with example properties (order, is_abelian, center). The domain naming clearly separates it from sibling operations like number_theory_operation, combinatorics_operation, or graph_operation. It falls short of 5 only because 'construct groups' leaves ambiguous what happens to the constructed object (is it stored, named, returned?).

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 by the domain: an agent can infer that this tool is for group-theoretic questions rather than polynomial or number-theory ones. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g., needing a session/workspace), and no statement of which sibling operations overlap or when to prefer evaluate_sage 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?

Annotations already declare idempotentHint=true and destructiveHint=false, so safety is partly covered, but readOnlyHint=false is unusual for a compute operation and the description does nothing to clarify it. The description omits session-state effects and the fact that workspace variables persist, which the schema mentions but the description ignores.

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?

A single front-loaded sentence with no wasted words, and the indefinite/definite distinction is front-loaded. It is arguably under-specified for a tool with session and bound semantics rather than over-long.

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?

An output schema exists, so return values need not be explained, and the required/optional parameter split is clear from the schema. However, for a symbolic-computation tool with session reuse and bound handling, the description is minimally complete and omits behavioral context an agent would want.

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% and every parameter (expression, variable, bounds, session) is documented there. The description adds no syntax, format, or default-value meaning beyond the schema, so baseline 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?

States a specific verb (integrate) and resource (expression) and even distinguishes the two operating modes (indefinite vs definite with bounds). It does not name or contrast any sibling tool explicitly, so it stops short of the top score.

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 parenthetical hints at indefinite vs definite modes but gives no guidance on when to choose this over alternatives like symbolic_sum, limit_expression, or evaluate_sage. No prerequisites, no when-not-to-use conditions.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is covered. The description usefully adds that variables are preserved, but says nothing about what happens to the interrupted computation's partial result or whether the interrupt is graceful vs. forceful.

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?

One sentence, zero waste, with the operation and its distinguishing side effect front-loaded. Nothing extraneous.

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?

An output schema exists, so return values need not be described, and the annotations cover the safety profile. The description is nearly complete for this simple tool, only missing what happens to the in-flight computation after interruption.

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% and the single 'session' parameter is fully documented in the schema (workspace naming, bearer-credential warning, default). The description adds no parameter information beyond that, so baseline 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?

States a specific verb ('Interrupt') and resource ('a running Sage computation') plus the key side effect ('keeping variables defined so far'). This implicitly distinguishes it from stop_sage_session, cancel_sage_session, and reset_sage_session, which presumably tear down state, but no sibling is named explicitly.

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

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

The phrase 'while keeping variables defined so far' implies the use case (stop work without losing state), which is the same thing that separates it from stop_sage_session and cancel_sage_session. However, no explicit when-to-use vs. when-not-to-use guidance or alternative is named.

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 state readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds no behavioral context, such as why the operation is not read-only (likely because it mutates the session workspace) or how the workspace is affected. It neither contradicts nor enriches 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 a single front-loaded sentence with no filler or repetition. It is appropriately terse, though it leaves many details to the schema and annotations.

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 (five parameters including a session bearer credential, an output schema, and many sibling math tools), the description is too sparse. It does not mention session/workspace management or when this tool is preferred over related operations, leaving the agent to rely entirely on the schema and name.

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 thoroughly documents all five parameters including defaults and the session token. The description adds no parameter semantics beyond what the schema already provides. 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 restates the tool name ('limit_expression' → 'Compute the limit of an expression') without adding scope, constraints, or distinguishing features from sibling calculus tools like differentiate_expression or integrate_expression. It identifies the verb and resource but provides no selection value.

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

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

No guidance is given on when to use this tool versus alternatives, no prerequisites are stated, and the session/workspace context is ignored. The agent must infer usage entirely from the name and schema.

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, idempotentHint, non-destructive, and non-open-world, so the safety profile is fully covered. The description adds that it lists workspaces for 'this client', which is the key behavioral scoping context. It doesn't mention ordering, pagination, or return shape, but an output schema exists so return values are documented elsewhere.

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?

A single efficient sentence that front-loads the action and scope. No filler or repetition.

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 zero-parameter, read-only listing tool with an output schema and rich annotations, the description is nearly complete. It could mention ordering or that results are scoped to the current session/client, but those are optional.

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?

Zero parameters, so the baseline is 4. The description correctly implies no parameters are needed, aligning with the empty input schema.

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

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

States a specific verb+resource ('List the named Sage workspaces') and scopes it to 'belonging to this client'. Clearly distinct from all siblings, which are computation, plotting, and session lifecycle 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 scope constraint ('belonging to this client') implies when to use it, but there is no explicit guidance on alternatives or when not to use it. 'List' implies a read-only enumeration, which is the usual case.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds what information is returned, but does not discuss rate limits, auth, or other behavioral traits.

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?

A single short sentence that front-loads the resource and the two outputs. No filler or repetition.

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 an output schema, complete parameter documentation, and rich annotations, the description provides enough context for a lookup tool. It could be stronger with explicit routing guidance, but nothing essential is missing.

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 single parameter is documented with examples in the schema. The description merely echoes the concept of a SageMath name without adding syntax or format details 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?

States a specific resource (a SageMath name) and exactly what is returned: documentation links plus whether the server offers that name for evaluate_sage. It distinguishes itself from evaluate_sage by focusing on documentation and availability rather than evaluation.

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 mention of evaluate_sage caller code implies a use case, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like check_sage_health or evaluate_sage. Usage is only inferable.

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 declare readOnlyHint=false and idempotentHint=true, implying stateful/workspace behavior, but the description says nothing about the session workspace, whether results are stored, or how the computation interacts with workspace variables. It only restates the return format, which the output schema already covers.

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?

A single tight sentence with no wasted words and the core action front-loaded. It is just sparse rather than bloated, so no penalty for verbosity.

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

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

The tool takes a session/workspace parameter whose semantics (independent variables, cross-reconnect handles) are non-trivial, yet the description omits it entirely and gives no routing versus 'matrix_operation'. Low operation complexity and an existing output schema mitigate this, but key context is missing.

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 already documents matrix_a, matrix_b (including the 2^53 string convention) and the session parameter in detail. The description adds no extra parameter meaning, 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?

Clear specific verb + resource (multiply two matrices) and it states the return shape. However it does nothing to distinguish itself from the sibling 'matrix_operation', which an agent would reasonably consider for the same 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the closely related 'matrix_operation' sibling that could also perform matrix math. The agent must guess which one applies.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows the safety and idempotency profile. The description adds no behavioral context beyond that—it doesn't explain why the tool is not read-only (e.g., whether it writes to the session workspace) or any side effects. With annotations covering the profile, this is adequate but adds nothing.

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

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

Two tight sentences: the core operation list is front-loaded, and the routing preference follows immediately. No filler or repetition of schema details.

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

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

Given that an output schema exists and schema coverage is complete, the description needn't explain return values or parameter formats. It covers purpose and routing well, but does not address the non-read-only nature flagged by annotations or explain any interaction with the session workspace, which 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 description coverage is 100%, and both the matrix and session parameters are fully documented in the schema with important details about exact integers, string representations for large numbers, and workspace credential semantics. The description adds no parameter meaning beyond what the schema already provides, 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 a specific operation class ('Linear algebra on one matrix') and enumerates the six supported operations, which lets an agent distinguish it from matrix_multiply and other siblings. It also explicitly names evaluate_sage as the alternative, making the tool's scope 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 gives a clear preference rule: 'Prefer this over evaluate_sage.' This names the primary alternative, though it does not state when evaluate_sage would be the better choice or any other exclusion conditions.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description need not restate safety. However, it adds no behavioral context of its own — nothing about cost, determinism, or workspace side effects beyond what the schema's session field already explains.

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

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

Two sentences, zero waste, with the operation list front-loaded and the routing instruction last. Every clause 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?

With an output schema present and 100% parameter coverage, return values and argument mechanics are fully covered elsewhere, so the description only needs to establish scope and routing — which it does. It is slightly thin on workspace/session implications for a tool that takes a session parameter, but not enough to be blocking.

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 baseline is 3. The schema already explains the big-integer string rule, the b requirement for gcd/lcm, and the session/workspace semantics in detail; the description adds only the operation list, which largely duplicates the enum-adjacent schema text.

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 specific resource (number theory) and enumerates the exact operations (primality, factorisation, next prime, gcd, lcm) with a verb-level match to the 'operation' enum. It also names the sibling it supersedes, so an agent can distinguish it from evaluate_sage without opening a 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?

'Prefer this over evaluate_sage for any of these' explicitly routes the agent away from the general-purpose evaluator, which is strong guidance. It stops short of a 5 because it gives no when-not condition (e.g. what to do if evaluate_sage is needed alongside, or whether session/workspace setup is a prerequisite).

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds only the return modality ('rendered image'), which is useful but thin; it says nothing about what the image represents, whether a session must exist, or how results are delivered beyond the schema-documented image_format.

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?

A single sentence with the verb front-loaded and zero filler. Everything an agent needs at a glance is present.

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

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

With no output schema, the description should clarify what the 'rendered image' return actually is (inline blob, file path, or URL), and it does not. Annotations and the exhaustive schema cover safety and inputs, so it is adequate but leaves the output contract underspecified for a 9-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 description coverage is 100%, so every parameter is already documented in the schema, including the session/workspace semantics and image_format enum. The description only reinforces that expression takes two variables, which the schema already conveys. Baseline 3 applies when 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 states a specific verb and resource: 'Plot a 3D surface of a two-variable expression.' The qualifiers '3D' and 'two-variable' implicitly separate it from the sibling plot_expression and plot_multi_expression, but no sibling is named, so the distinction must still be inferred.

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?

There is no explicit when-to-use guidance. The '3D' and 'two-variable' phrasing hints at when this tool is appropriate over 2D plotting siblings, but no alternatives are named and no exclusion or scenario conditions are stated.

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

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

Annotations declare idempotent, non-destructive, closed-world, so the safety profile is partially covered. But the description says nothing beyond what annotations give: it doesn't explain the range/variable defaults, the session/workspace scoping, or the output format tradeoffs already hinted by the schema. For a tool with session-scoped state, this is thin.

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?

A single short sentence, front-loaded with the verb and resource, no waste. Nothing redundant.

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, no annotations covering behavior beyond safety, and no description of the returned image or defaults, the description is too thin for a 6-parameter plotting tool operating on session-scoped workspaces. The schema carries the parameter load but the description should at least name the range/variable conventions or model of use.

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

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

Schema coverage is 100%, so every parameter is documented in the schema itself (including the image_format enum and the session bearer-credential warning). The description adds no parameter semantics 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?

States a clear verb+resource ('Plot an expression') and the return type (rendered image). It doesn't differentiate from siblings like plot3d_expression or plot_multi_expression, which a reader must infer from those names.

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

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

No when-to-use guidance and no mention of alternatives such as plot3d_expression or plot_multi_expression. The agent gets no conditions that select this tool over its plotting siblings.

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 destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the return medium ('as a rendered image'), which is useful because there is no output schema, but says nothing about how the image is delivered, size limits, or rendering cost. Note readOnlyHint=false is set even though plotting mutates nothing, but the description makes no conflicting claim, so this is not a 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?

A single front-loaded sentence with no filler; the distinguishing qualifier ('multiple', 'single 2D graph') comes before the output form.

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, stating that the result is a rendered image is the key missing piece and it is present. The remaining gaps (how the image is returned in the response, session/workspace expectations) are covered by the schema or are minor for a plotting 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 description coverage is 100%, so all six parameters (session, variable, range_min/max, expressions, image_format) are already documented in the schema. The description's 'multiple expressions' merely echoes the expressions array and adds no format, default, or range semantics. Baseline 3 applies when 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 gives a specific verb (plot), a specific resource (multiple expressions), and the exact output form (overlaid on a single 2D graph, rendered image). The words 'multiple' and '2D' inherently separate it from the sibling plot_expression (single) and plot3d_expression (3D), so an agent can route to it from names alone.

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?

There is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer from 'multiple expressions' that single-expression plotting belongs to plot_expression, and nothing addresses 3D cases or session prerequisites. Implied routing only, with no stated conditions.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the mutation profile is partly covered. The description adds nothing beyond them – it does not mention that ring construction populates a session workspace with independent variables, nor that results depend on the chosen workspace. For a tool whose state lives in a session, this leaves the key behavioral trait to 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?

A single front-loaded sentence with no padding – it leads with the resource and follows with the capability list. It is appropriately sized, though the phrasing 'Polynomial ring operations:' is slightly redundant with the tool name.

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?

An output schema exists, so return values need not be explained. However, for a multi-operation tool with five operations, the description never clarifies what reduce, is_groebner, ideal_dimension, or ideal_variety actually compute, leaving the agent to infer semantics from terse names.

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%, including a detailed account of the session/workspace parameter, so the schema carries the semantic load. The description's operation list restates values already enumerated in the operation field's documentation and adds no syntax or format detail. 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 names a specific resource (polynomial rings) and concrete capabilities (construct rings, Groebner bases, ideals, quotients), which distinguishes it from computational siblings like matrix_operation or group_operation. It is clear enough that an agent can identify the domain, though it does not spell out each operation's meaning.

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?

There is no guidance on when to choose this over alternatives such as simplify_expression or solve_equation, and no prerequisites or exclusions are stated. The mention of operations describes what can be done, not when to reach for this tool.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds only the notion of clearing session state and does not say what specifically is destroyed (variables, definitions, workspace contents) or whether the session remains usable afterward.

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?

A single efficient sentence with the key concept front-loaded. It is tight but arguably too terse given the ambiguity against sibling session tools, so not a 5.

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 an output schema present, return values need no explanation, and the parameter semantics are fully covered by the schema. However, for a destructive operation sitting in a family of session tools, the description omits what reset preserves versus destroys and how it differs from stop/cancel.

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%, and the schema's parameter description is unusually rich (name vs. portable handle, bearer-credential warning, default behavior). The tool description adds nothing beyond this, 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?

States a specific verb and resource ("Reset the SageMath session state"), which is clearer than a tautology, but it does not differentiate from closely related siblings such as stop_sage_session, cancel_sage_session, or start_sage_session. An agent cannot tell from the text whether "reset" clears variables, restarts the kernel, or recreates the workspace.

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

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

No when-to-use guidance, prerequisites, or alternative tools are named, despite a crowded family of session-lifecycle siblings (start/stop/cancel/interrupt/list). The agent is left to infer that reset is the state-clearing operation rather than a teardown.

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 declare idempotentHint=true and destructiveHint=false, but the description adds nothing about behavior: no mention of which workspace/session state is touched, whether the result is returned or stored, or how the expansion interacts with session variables. With openWorldHint=false and readOnlyHint=false, the agent needs clarity the description doesn't provide.

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?

A single front-loaded sentence with zero waste, appropriate for the tool's scope. It is not padded, though it is also not maximally informative per word.

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?

An output schema exists, so return structure needn't be explained. However, for a symbolic math tool with a session/workspace parameter and 5 params, the description leaves the session semantics, point-in-expansion behavior, and the Taylor-vs-Laurent distinction entirely to 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?

Schema coverage is 100%, so every parameter is already documented in the schema, including defaults for order, point, variable, and session. The description adds no parameter-level meaning beyond the schema 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?

States a specific verb ('Compute') and resource ('Taylor/Laurent series expansion'), clearly distinguishing it from siblings like expand_expression or symbolic_sum. It doesn't need to name a sibling because the math term itself is distinctive.

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

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

No guidance on when to use this vs alternatives such as expand_expression, simplify_expression, or limit_expression, all of which are adjacent symbolic manipulations. An agent must infer the use case from the name alone.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, but the description adds nothing to them. In particular, readOnlyHint=false implies the call touches session/workspace state, and the description never mentions that simplification runs against a named workspace whose variables persist.

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?

It is a single short sentence with no filler, which is efficient, but the brevity is under-specification rather than disciplined conciseness. Nothing is front-loaded because there is nothing else to load.

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?

An output schema exists and the input schema is fully documented, so return values and parameters need not be explained. What remains missing is the operation's boundary against factor/expand/evaluate siblings and any note that results are produced inside a stateful workspace.

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 'session' workspace/bearer-credential semantics and the 'expression' input fully documented in the schema, so the baseline of 3 applies. The description adds no parameter meaning of its own.

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 phrase states a verb and a resource ('Simplify a mathematical expression'), so it is not a pure tautology, but it is nearly a restatement of the tool name and offers no distinction from siblings such as factor_expression, expand_expression, or calculate_expression. An agent cannot tell from the description which simplification form is intended.

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?

There is no guidance on when to use this tool rather than the many overlapping siblings (factor_expression, expand_expression, evaluate_sage, calculate_expression), and no prerequisites or exclusions are given. The single sentence supplies no context beyond the operation itself.

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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description adds no behavioral context beyond these hints—it doesn't explain that solving may return multiple solutions, how the result is structured, or whether the workspace state changes. With annotations covering safety and idempotency, the description should still clarify return semantics, but it is silent.

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?

A single, efficient sentence that front-loads the primary action. It is appropriately sized but could be slightly more informative without being verbose.

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

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

With an output schema present, the description need not explain return values. However, given the tool's complexity (systems of equations, multiple variables) and the presence of a related sibling (find_root), the description is minimal. It lacks any contextual hints about typical use cases or limitations, leaving the agent to rely entirely on schema and annotations.

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 all parameters are fully documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does all the work.

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 (solve) and resource (equation or system of equations). However, it does not differentiate from sibling find_root, which also solves equations numerically. A mention of the symbolic/exact nature vs find_root would fully distinguish it.

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

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

No guidance on when to use this tool versus find_root (numeric root finding) or solve_ode (differential equations). An agent must infer that this solves algebraic equations symbolically, but no explicit context or exclusions 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, destructiveHint=false and openWorldHint=false. The description adds that the return is a general solution with arbitrary constants, which is behavioral context beyond annotations. But it doesn't note that this may execute in a persistent session/workspace that affects state across calls (as strongly implied by the 'session' parameter).

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?

A single efficient sentence with the highest-value routing hint ('Prefer this over evaluate_sage') placed at the end. No 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?

Has an output schema, so return values need not be explained, and the equation format is shown in the schema. Routing to evaluate_sage covers the main sibling-confusion risk. Slightly incomplete on session workspace interactions, but overall fit for purpose.

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 parameters are fully documented in the schema (session/workspace semantics, equation format example, function name, variable name). The description adds nothing beyond the schema about parameters; baseline 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?

Specific verb (Solve) + resource (ordinary differential equation of any order) + output shape (general solution with arbitrary constants). Distinguishes clearly from siblings like solve_equation (algebraic) and evaluate_sage.

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

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

Explicitly says 'Prefer this over evaluate_sage', giving one clear alternative routing rule. However, it doesn't address when to use solve_equation (algebraic equations) vs this ODE solver, nor prerequisites for the session workspace handling.

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, idempotentHint=true, and destructiveHint=false, so the safety and repeat-call profile is covered structurally. The description adds the isolation semantics ('its own independent variables'), which is genuinely useful, but says nothing about what happens if the name already exists despite the idempotent hint, or about resource limits.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity leaves no room for the routing context an agent would benefit from.

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?

An output schema exists and annotations cover the safety profile, so return values and safety need not be restated. However, for a session-creation tool in a suite with reset/stop/list/interrupt siblings, the description omits lifecycle context such as duplicate-name behavior and how this session is subsequently referenced.

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 single 'name' parameter has 100% schema description coverage including examples ('curves', 'scratch'), so the schema does the heavy lifting. The description only echoes that the workspace is 'named', adding no format, uniqueness, or naming-rule detail 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?

States a specific verb ('Start'), resource ('named Sage workspace'), and a distinguishing property ('its own independent variables'), which separates it from session-management siblings like list_sage_sessions or reset_sage_session. It stops short of naming which sibling is the alternative, so it's clear but not fully 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?

There is no explicit when-to-use guidance, no indication that this is a prerequisite for evaluate_sage/calculate_expression, and no statement about when to reuse an existing session versus starting a new one. Usage is only implied by the word 'Start'.

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

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

Annotations are present (readOnlyHint=false, idempotentHint=true, destructiveHint=false), which carry the safety profile, so the description is not required to restate them. However, the description adds no behavioral context at all: it does not mention the session/workspace side effects implied by readOnlyHint=false, nor ordering, empty-list handling, or numeric tolerance. Adequate given annotations, but no added value.

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

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

Two sentences, zero waste, and the core capability is front-loaded ahead of the routing hint. Every clause earns its place by naming a returnable statistic or a sibling.

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?

An output schema exists, so return formatting need not be explained, and the enumerated statistics cover the semantic surface. The only gap is the absence of any note on the session/workspace interaction implied by readOnlyHint=false, though the schema parameter description partially covers it.

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%: both `data` (list of numbers) and `session` (workspace name/handle, secret handling, default behavior) are fully documented in the schema. The description adds nothing about parameters, so the baseline 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?

Names a specific operation (descriptive statistics) and enumerates exactly which statistics it returns (mean, median, population/sample variance and standard deviation, min, max), so the agent knows precisely what it computes. It also distinguishes itself from the sibling evaluate_sage, which is the closest ambiguous alternative.

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 the preference condition: 'Prefer this over evaluate_sage for summary statistics.' That is a clear routing rule with a named alternative. It does not state when-not to use this tool (e.g., single-value or symbolic cases), so it falls short of the top score.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description usefully adds that the worker is released, but it does not say what happens to in-flight or running computations, which is the key behavioral question for a stop/kill operation.

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

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

A single front-loaded sentence with zero filler; the verb and target lead, and the worker-release clause earns its place. It is perhaps too terse to be maximally useful, 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?

Rich annotations and an output schema reduce the description's burden, and it correctly identifies the effect. Still, for one of four near-synonymous session-termination siblings, the description omits the distinction and any caveat about consequences to running work, leaving the agent to guess which tool applies.

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?

There is a single parameter with 100% schema description coverage ("Workspace name to stop"), so the schema fully carries the parameter semantics. The description's word "named" conveys the same idea without adding format, naming-convention, or identifier details, matching the baseline 3 for high-coverage schemas.

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+resource ("Stop a named Sage workspace") plus the side effect of releasing the worker, so an agent knows exactly what entity is affected. However, it does not differentiate from the very similar lifecycle siblings cancel_sage_session, interrupt_sage_session, reset_sage_session, and start_sage_session, leaving the boundary implicit.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives. Given that cancel_sage_session, interrupt_sage_session, and reset_sage_session all plausibly mean "stop the session," the absence of disambiguation is a meaningful gap for agents choosing among them.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is largely carried by structured data. The description adds only the 'including infinite series' scope note; it does not explain anything about evaluation limits, timeouts, or the odd readOnlyHint=false flag on a pure computation. Adds some value but not rich 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?

Two sentences, zero waste, and the core capability is front-loaded ahead of the sibling-routing advice. 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?

An output schema exists, so return values need not be explained, and all six parameters are covered by the schema. The description supplies purpose and sibling routing, which is sufficient to call it correctly; only minor behavioral depth (e.g. infinite-series convergence handling) is absent.

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 every parameter (lower, upper, product, session, variable, expression) is already documented in the schema, including defaults and the session bearer-credential warning. The description adds no syntax or format detail beyond that, so the baseline 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?

States a specific verb and resource ('Closed form of a symbolic sum or product over an index variable'), and explicitly names the sibling it should be chosen over (evaluate_sage). An agent can distinguish it from evaluate_sage 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?

Gives a clear selection rule: 'Prefer this over evaluate_sage for summations.' This names the alternative and the condition that selects it. It stops short of a full 5 because it states no when-not/exclusion cases (e.g. numeric-only evaluation or cases where evaluate_sage is still correct).

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 provide idempotentHint=true, destructiveHint=false, openWorldHint=false, and readOnlyHint=false, so the safety profile is already largely covered. The description adds no behavioral context beyond the operation names: it does not mention session/workspace side effects, permissions, or what occurs when readOnlyHint is false. With annotations carrying the safety burden, this adds nothing extra.

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

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

The description is a single front-loaded sentence with zero wasted words, and the operation list is immediately useful. It is appropriately sized for a schema-rich tool with an output schema.

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

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

Given 100% schema description coverage, an output schema, and annotations, the description need not explain return values or parameter formats. It states the available operations clearly, though it could be more complete by clarifying when to choose this tool over sibling symbolic-math tools.

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 already documents parameter meanings and formats. The description adds no parameter semantics beyond what the schema provides. A baseline of 3 is appropriate when the schema does the heavy lifting and the description does not compensate.

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

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

The description explicitly states the tool performs vector calculus operations and enumerates the four available operations (gradient, divergence, curl, laplacian). This is clear and specific, but it does not differentiate the tool from sibling mathematical operations such as differentiate_expression or integrate_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?

Listing the operations implies when the tool is appropriate, but there is no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions. The usage is inferable from the operation names, which matches a 3.

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

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

With annotations present, the description adds substantial context beyond them: the verification 'ladder', the meaning of each verdict including that 'refuted' exhibits a counterexample and 'undecided' never means false, how decimal literals are read exactly, that float comparisons are reported as 'supported' not proof, and that session assumptions are honored and named. This is rich behavioral disclosure an agent needs and cannot infer from readOnlyHint/idempotentHint.

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 purpose and verdict taxonomy, then examples, then the ladder and exactness caveats. Dense and slightly long, but for a tool with nuanced semantics nearly every sentence carries needed information; minor verbosity keeps it from a 5.

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 an output schema exists and return values need not be explained, the description covers everything an agent needs: verdict semantics, exactness caveats, assumption handling, sampling, and precision. Nothing critical is missing for correct invocation or interpretation.

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 still adds meaning: it specifies the claim is a single comparison in Sage syntax with worked examples, describes sampling behavior ('says how many samples at what precision'), and explains precision_bits as controlling certified interval arithmetic, extending beyond the raw schema text.

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+resource ('Independently re-check a stated mathematical claim') and its output behavior (reporting how far evidence goes: proved, refuted, supported, undecided). This is clearly distinct from siblings like calculate_expression, simplify_expression, and solve_equation, so an agent can select it without opening the 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 states when to use it: 'Use this to verify your own algebra before presenting it.' That gives clear context for invocation. However, it names no alternatives and gives no explicit when-not-to-use or exclusions relative to the many sibling compute tools.

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