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

Annotations already provide idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying the mathematical domain (GF(2)) and the set of operations, which is consistent with the annotations. It does not disclose side effects or session behavior, but no annotation contradiction exists.

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

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

Two sentences with no filler. The first sentence front-loads the resource and operations, and the second provides routing guidance that 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 full schema coverage and an output schema, the description does not need to explain parameters or return values. The only notable gap is that the 'reduce' operation is omitted from the operation list, though the operation enum documents it as an option.

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 session, operation, expression, and num_variables with defaults/descriptions. The tool description adds no parameter-level detail beyond the general GF(2) context, 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 opening phrase 'Boolean polynomials over GF(2)' names a specific mathematical resource, and the colon list names concrete operations: evaluate, list variables, degree, and zero/one tests. It also explicitly differentiates this tool from evaluate_sage, so an agent can tell what this tool is for without opening schemas.

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 explicit routing guidance: 'Prefer this over evaluate_sage for boolean algebra.' This names the alternative tool and the condition under which this tool should be selected, leaving little to 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?

Annotations already supply idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are 'numeric/string forms', but it does not clarify possible session-side effects, especially since readOnlyHint=false. No contradiction with the annotations exists.

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

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

The description is a single focused sentence that leads with the verb and object and then states the expected result. It contains no filler, repetition, or unnecessary detail.

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

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

The schema documents all parameters, an output schema exists, and annotations cover idempotency and destructiveness, so an agent has enough to invoke the tool correctly. The main gap is the lack of sibling differentiation, but for a simple evaluation tool the description is otherwise 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 input schema already documents both parameters, including the session workspace semantics and bearer-token warning. The description itself adds no parameter-level detail beyond the schema, matching the baseline for high schema coverage.

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

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

The description clearly names the verb ('Evaluate') and the resource ('a SageMath expression') and states the output shape ('numeric/string forms'). It does not explicitly differentiate the tool from overlapping siblings such as evaluate_sage or evaluate_sage_streaming, but the core purpose is unambiguous.

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

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

There is no guidance about when to use this tool versus alternatives. Given several closely related siblings (evaluate_sage, evaluate_sage_streaming, simplify_expression, solve_equation), the absence of selection criteria leaves the agent to guess which tool fits a given request.

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 and idempotentHint=true, and the description adds concrete behavioral context by revealing that the worker is restarted and that running computations are canceled. This goes beyond the structured hints and gives an agent a clear picture of the main side effect, though it does not enumerate all state loss implications.

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

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

The description is a single, direct sentence with no filler or repetition. It front-loads the primary action and states the key side effect efficiently, which is ideal for an agent scanning tool definitions.

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 only one optional parameter and a rich schema plus output schema present, the core call is well covered. However, the description leaves ambiguous whether cancellation is scoped to the supplied session or applies globally to the worker, and it does not clarify how this relates to the sibling session-control tools. This is a meaningful gap for a destructive operation.

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

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

The input schema has 100% coverage and provides a rich explanation of the optional 'session' parameter, including scoping and bearer-credential warnings. The description itself adds no parameter-level meaning, but the schema already carries that burden, so the baseline score of 3 is appropriate.

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

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

The description names a specific action ('Cancel any running Sage computation') and a concrete side effect ('restart the worker'), so it is not a tautology and clearly identifies this as a cancellation/restart tool. It does not explicitly differentiate itself from the sibling interrupt_sage_session or reset_sage_session, but the 'restart the worker' phrase gives a useful distinguishing hook.

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 about when to prefer this tool over interrupt_sage_session, stop_sage_session, or reset_sage_session. The description implies a heavier operation by mentioning worker restart, but it never states the conditions or exclusions an agent should use to route to the correct sibling.

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

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

The description discloses important behaviors beyond annotations: it starts or reuses the workspace's worker, evaluates 1+1, reports readiness and latency, and never errors by returning failures in the result. This is especially valuable because annotations only label idempotent and non-destructive, not the worker-starting side effect.

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

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

The description is two sentences with no wasted words. The core purpose is front-loaded, followed by concrete behavioral details and a safety guarantee, making it easy for an agent to parse quickly.

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

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

Given the output schema exists and the parameter schema fully documents the only parameter, the description covers the essential behavioral context: worker lifecycle, probe behavior, latency reporting, and failure handling. An agent has enough to decide whether to call it and what to expect.

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 a detailed description covering defaults, scoping, bearer credentials, and secrecy. The tool description adds no further parameter-level information, so the schema carries the burden; 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 uses a specific verb ('Probe') and resource ('whether SageMath evaluation works right now'), and clearly distinguishes the tool from siblings like evaluate_sage by describing a health check that evaluates 1+1 and reports readiness/latency. It also signals a key differentiator: failures are returned in the result rather than raised as errors.

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 clearly states when to call it: to probe whether SageMath evaluation works right now. It also implies suitability as a safe preliminary check by noting it reports failure in the result rather than erroring. It does not explicitly name alternative tools or exclusions, but the intended context is clear.

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, covering the safety profile. The description adds no behavioral context beyond the operations themselves (e.g., no mention of side effects, performance, or prerequisites). It does not contradict annotations, but also adds little value 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 with no filler. The first sentence front-loads the purpose and scope, the second provides usage guidance. Every word 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 are covered. The description covers purpose and usage adequately. It does not mention prerequisites like needing an active Sage session, but the session parameter is optional with a default, so this is a minor gap. Overall, the tool is simple enough that the description is sufficient.

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

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

Schema coverage is 100%, and the schema already provides examples for code_type and lists operation values. The description repeats these lists without adding new meaning. It offers no additional syntax or edge-case details, so it does not significantly enhance parameter understanding.

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

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

The description states a specific resource ('Error-correcting codes') and enumerates the operations (length, dimension, minimum distance, rate, generator matrix) and code types (Hamming, generalized Reed-Solomon). It explicitly differentiates from a sibling by saying 'Prefer this over evaluate_sage for code parameters', making the tool's purpose unambiguous.

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

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

The description gives explicit guidance to prefer this tool over evaluate_sage for code parameters, naming the alternative and the condition. It does not mention when not to use it or other alternatives, but the stated preference is clear and actionable.

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 the agent knows this is a safe, non-destructive operation. The description adds no behavioral context beyond the operation list; it doesn't mention side effects, permissions, or return behavior beyond what the schema states. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is two sentences with zero waste. The operation list is front-loaded, and the preference over evaluate_sage is stated immediately after. Every word earns its place.

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

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

Given the tool's simplicity and the presence of an output schema, the description is complete enough. It covers the operations and the key alternative. The session parameter is documented in the schema, and return values are stated in the operation parameter description ('All return a single integer'). Minor gaps like error handling aren't necessary here.

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 (operation, n, k, session) are already documented in the schema. The description's list of operations mirrors the operation parameter's description without adding new information. It doesn't explain parameter formats or edge cases 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?

The description clearly states the tool performs combinatorics operations and enumerates the specific types (binomial, permutations, combinations, partitions, factorial, Catalan, Fibonacci, Bell). It distinguishes itself from the sibling evaluate_sage by explicitly saying to prefer this tool for these operations, so an agent can tell them apart.

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 an explicit when-to-use directive: 'Prefer this over evaluate_sage for any of these.' This names the primary alternative and the condition for choosing this tool, which is exactly the kind of guidance needed. It doesn't list other siblings but the key alternative is covered.

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, and the description does not contradict them. The description adds no extra behavioral detail such as session side effects or result format, but for a simple pure computation the annotation profile carries much of that burden.

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, focused sentence with no filler. The core operation and the key variable parameter are front-loaded, making it easy for an agent to parse quickly.

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

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

Given the fully documented schema, safe annotations, and presence of an output schema, this terse description is sufficient for typical differentiation calls. It does not provide example syntax, but the surrounding structured metadata compensates for that 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 expression, variable, order, and session. The description mainly restates the variable relationship and adds no extra meaning about order or session semantics, 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?

The description uses a specific verb ('differentiate') and resource ('an expression'), and specifies the target variable ('with respect to a variable'). This makes it unambiguous and clearly distinct from siblings like integrate_expression or limit_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?

The description implies the usage context: call this tool when a derivative is requested. However, it provides no explicit when-not-to-use guidance or named alternatives, so the agent must infer selection from the tool name and the sibling list.

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 provide idempotent/readOnly/destructive hints, but the description adds no behavioral context beyond the operation names. It does not mention that sampling draws random values, whether session state is consulted or modified, or whether results are computed symbolically/numerically, so it fails to add value beyond the structured fields. No direct contradiction with annotations is present.

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

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

The description is a single front-loaded sentence with no filler; it leads with the domain and immediately specifies the available operations. Every word contributes, and the list format is easy to scan.

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 parameter descriptions are rich, so the tool is reasonably invokable without the description explaining return values. However, for a dispatcher with six operations, eight distributions, and many sibling tools, the description omits behavioral caveats (notably sampling randomness) and any guidance for choosing between this and related statistical 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 explains operation, distribution, parameters, x, n, and session. The description repeats the operation names but adds no parameter semantics beyond the schema's own example ('[0, 1] for standard normal'), which puts it at the baseline.

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

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

The description names a specific domain (probability distributions) and lists six concrete operations (PDF, CDF, quantile, mean, variance, sampling), so an agent can see it is a distribution-focused dispatch tool rather than a general calculator. It lacks an explicit verb like 'perform' or 'compute', and it does not name sibling tools, but the resource and operation set are clear.

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

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

There is no explicit statement of when to use this tool versus a sibling such as statistics_summary or calculate_expression, and 'mean, variance, sampling' overlaps with general statistics tools. The intended use is only implied by the operation list, with no exclusions or alternatives.

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 idempotentHint=true and destructiveHint=false, and the description adds no behavioral detail beyond the operation list. The readOnlyHint=false annotation is not addressed: the description implies a pure computation, while the annotation suggests possible side effects (e.g., session/workspace changes). No permissions, rate limits, or mutation behavior are disclosed.

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

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

Two short sentences convey the full purpose and routing guidance. The first sentence front-loads the operation list and curve domain; the second provides the sibling-tool preference. 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?

Given the output schema exists and annotations cover idempotence/destructiveness, the description is largely sufficient: it names the curve domain, lists all operations, and points to the preferred tool. The only minor gap is that it does not clarify the session/workspace side-effect behavior hinted by readOnlyHint=false.

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 schema fully documents all three parameters. The description's 'from Weierstrass coefficients' mirrors the coefficients schema and its operation list repeats the operation schema, adding marginal semantic value. This meets the baseline for high schema coverage but does not go beyond it.

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

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

The description clearly identifies the resource (elliptic curves over Q) and enumerates the available invariants (rank, torsion order, discriminant, j-invariant, conductor, generators), and it explicitly distinguishes itself from evaluate_sage. However, it lacks a direct verb like 'computes' or 'returns', relying on a noun phrase with a colon, so it stops just short of the strongest clarity standard.

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

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

The description explicitly says 'Prefer this over evaluate_sage for curve invariants.' This tells the agent when to use this tool and names the alternative, leaving no ambiguity about the routing decision for elliptic curve invariant calculations.

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

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

Beyond the annotations, the description discloses important behavioral traits: session persistence across calls, deny-by-default restrictions, refusal of imports/external CAS/file/display/persistence calls, and the contrast that dedicated tools run in a fresh namespace. This adds substantial operational context that annotations alone do not provide, and it does not contradict any annotation.

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 long, but every section earns its place: core behavior, routing guidance, categorized alternatives, and worked examples. It is well-structured and front-loaded with the most important facts before the lengthy lists. The length is justified by the large sibling set and the need to disambiguate.

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, the rich sibling set, and the existing output schema, the description covers everything an agent needs: restrictions, persistence semantics, session selection, timeout override, and detailed routing examples. The presence of an output schema means return-value details need not be repeated here.

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 schema already documents all five parameters. The description still adds meaning by showing valid SageMath code examples, explaining that the default session persists, and clarifying when session handles are bearer credentials. This goes beyond the schema's basic property descriptions.

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

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

The description opens with a specific verb and resource: 'Run SageMath code in a persistent session; variables persist across calls.' It also differentiates itself from the many dedicated sibling tools by explicitly framing itself as the LAST RESORT for self-contained calculations and the right choice for persistent multi-step workflows. The purpose is unmistakable and not confused with any 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?

The description gives explicit when-to-use and when-not-to-use guidance: dedicated tools should be preferred for single calculations because they validate arguments and return typed results, while evaluate_sage should be used for multi-step work requiring state persistence. It even lists alternate tools by category and supplies concrete examples of cases not covered by those tools.

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

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

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds the streaming behavior, which is a useful behavioral trait. However, it does not disclose potential side effects of executing arbitrary SageMath code (e.g., state changes in the session), which is a notable gap given the tool executes code.

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, efficient sentence that front-loads the core action and streaming behavior. There is no wasted wording, and it is immediately scannable.

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

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

For a tool that executes arbitrary code, the description is thin. It does not mention session handling, error behavior, or that execution may have side effects on the workspace. The presence of an output schema covers return values, but the description leaves out important context about the execution environment and potential state changes.

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 three parameters (code, session, timeout_seconds) are already described in the schema. The description adds no additional parameter-level meaning beyond what the schema provides. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the action (execute SageMath code) and the distinguishing feature (stream intermediate print() output line by line). It also mentions the final result is returned as usual, which clarifies the full behavior. This differentiates it from siblings like evaluate_sage, which presumably does not stream.

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

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

The description implies the use case: when streaming intermediate output is needed. However, it does not explicitly name an alternative or provide when-to-use/when-not-to-use guidance. The streaming feature is a strong signal, but the lack of explicit comparison to evaluate_sage leaves some ambiguity.

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

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

The description provides no behavioral traits beyond what the annotations already state. It does not clarify whether session state is modified, whether the operation is purely computational, or what side effects might occur; readOnlyHint=false leaves this unclear.

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 short sentence with no redundancy, but it is so minimal that it borders on under-specification. It is concise without being informative beyond the title.

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 large sibling set and the existence of similar tools, the one-line description is not enough for correct tool selection. The output schema reduces the need to describe return values, but the description still lacks scope, input expectations, and relationship to alternative operations.

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 both parameters. The description adds no meaning beyond naming the expression parameter, which is the baseline for fully covered 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?

The description clearly states a verb and resource: expand a mathematical expression. It is understandable on its own, but it does not differentiate from siblings like simplify_expression, factor_expression, or series_expansion.

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 about when to use this tool versus alternatives. An agent must infer from the tool name alone that expand is the right choice instead of simplify, factor, or series expansion.

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 and destructiveHint=false, but the description adds no behavioral context of its own. Notably, readOnlyHint=false suggests possible side effects (likely session/workspace interaction), yet the description says nothing about this or about failure behavior for unfactorable expressions. With no annotation coverage of these behaviors, the description leaves a real transparency 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 sentence with zero redundancy. It is appropriately sized for the tool's simplicity, though it contributes little beyond the title 'Factor Expression' aside from the 'or integer' qualifier.

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 straightforward computation with full schema coverage and an output schema present, the definition is minimally adequate. The notable gap is the large sibling family (simplify, expand, solve, calculate) with no guidance on when factoring is the correct operation — an agent gets no help in selecting among them. The detailed session description in the schema partially compensates.

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 'session' (with workspace semantics and credential warning) and 'expression' (with examples) are fully documented. The tool description adds nothing beyond what the schema already states, 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?

The description states a specific verb ('factor') and resource ('a mathematical expression or integer'), which semantically distinguishes it from siblings like simplify_expression, expand_expression, and calculate_expression. However, it provides no explicit sibling differentiation; the agent must infer the distinction purely from the verb.

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 the many math siblings (simplify_expression, expand_expression, solve_equation, evaluate_sage). The schema examples ('x^2 - 1', '60') illustrate inputs but do not explain selection criteria, and no alternatives or exclusions are 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 declare idempotentHint=true and destructiveHint=false, covering safety and repeatability. The description adds only the 'numeric' qualifier, which signals approximate rather than symbolic behavior, but does not disclose algorithm behavior, no-root outcomes, or potential caveats.

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 efficient sentence with no filler. It front-loads the core operation ('find a numeric root') and includes the essential scope ('in a given interval') without 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?

Given the rich input schema, presence of an output schema, and annotations, the description is largely sufficient for an agent to invoke the tool correctly. The main gap is the lack of explicit routing guidance versus solve_equation, but that is a minor omission here.

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 the expression format and bounds. The description reinforces the domain but does not add meaning beyond what the parameter descriptions already provide.

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

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

The description clearly states a specific operation: find a numeric root of an expression or equation within a given interval. It is unambiguous about the resource and action, though it does not explicitly distinguish itself from the sibling solve_equation tool.

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 'numeric root... in a given interval' implies this tool is for numerical interval-based root finding, which hints at when it should be used versus symbolic solving. However, it does not explicitly name alternatives or state when not to use it.

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

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

The annotations already convey idempotentHint=true and destructiveHint=false, so the safety profile is mostly covered. The description adds no behavioral context about side effects, session interaction, or error behavior, and readOnlyHint=false is not explained, though it is not contradicted.

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

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

The description is two sentences with no wasted words: the first fronts the capability set, and the second gives a direct routing instruction. Every sentence contributes useful information.

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

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

Combined with a rich schema, output schema, and annotations, the description gives an agent enough to select and invoke the tool correctly. It could add geometric preconditions such as consistent dimension or point-count expectations, but those are minor gaps rather than fatal omissions.

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 already documents points, session, and the allowed operation values. The tool description mostly repeats the operation names without adding a meaningful layer of detail about coordinate formats, dimensionality, or minimum point counts.

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 clear subject, 'Computational geometry on point sets,' and enumerates five concrete operations: distance, polygon area, polytope volume, convex hull vertices, and convexity tests. This lets an agent know exactly what the tool computes and differentiates it from siblings, especially 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?

The description explicitly says to prefer this tool over evaluate_sage for these geometry operations, naming the most likely alternative. It lacks more detailed conditions about when evaluate_sage might still be the better choice, so it falls just short of fully explicit when-not guidance.

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

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

Annotations already carry idempotentHint=true and destructiveHint=false; the description adds that graphs can be constructed/named and properties computed. It does not say whether named graphs persist in a session or what happens on repeat creation, but the annotations cover most of the safety profile.

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 definition is one short, front-loaded sentence with a parenthetical list of operations and no filler. Every word contributes to scoping the tool.

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

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

Given a rich schema, output schema, and annotations, the description is nearly sufficient: it names the domain and the action. It only lacks usage-selection context and side-effect detail, which are captured in other dimensions.

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

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

Schema description coverage is 100%, so the schema fully documents graph, source, target, session, and operation. The description merely restates the operation domain and does not need to add parameter-level 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?

The description anchors the tool with 'Graph theory' and names concrete actions ('create named graphs and compute properties') plus example operations, so an agent can tell it handles graph objects. It does not explicitly contrast with sibling tools such as group_operation or matrix_operation, which keeps it from a 5.

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

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

There is no guidance on when to choose this tool over the many math siblings; it relies entirely on the 'Graph theory' prefix to imply applicability. No exclusions or alternative tool mentions are present.

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 convey idempotence and non-destructiveness; the description adds the construction/query framing but does not disclose whether constructed groups persist in the session or how workspace state is affected. The session parameter documentation covers workspace mechanics, but the description itself does not.

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 short, front-loaded sentence with no wasted words. It is concise, though slightly vague around 'construct groups' versus query-only operations.

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 input schema and output schema carry the detailed group constructors, operation values, and session semantics, so the description only needs to orient the agent. The main missing nuance is how invalid constructors or session-specific evaluation errors are handled, which is minor.

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 merely echoes operation examples and adds no new parameter meaning. The parenthetical 'center' is also a loose shorthand for the valid 'center_order' value, a small accuracy risk.

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 anchors the tool in group theory and names concrete query properties, so an agent can distinguish it from calculus, polynomial, or graph siblings. It is not a tautology, but 'construct groups and query properties' is slightly broader than the actual operation list, which only queries group properties.

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 'Group theory:' provides an implied domain, but the description never states when to prefer this tool over siblings like number_theory_operation or combinatorics_operation, nor does it give exclusions. It relies on the tool name and domain label to route 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 convey idempotency and non-destructiveness, and the description adds the useful distinction between indefinite and definite integration. However, it does not disclose subtler behavior such as how malformed bounds or mismatched variable references are handled; descriptions here do not contradict 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. It communicates the operation and the key mode distinction (indefinite vs definite) in minimal space.

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

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

Given the rich input schema, output schema, and annotations, the description is sufficient for an agent to select and invoke the tool. The only minor gap is that it does not explicitly state that both lower_bound and upper_bound are needed for a definite integral, but 'with bounds' reasonably implies this.

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 (session, variable, expression, lower_bound, upper_bound) is fully documented in the schema. The tool description itself adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Integrate') and resource ('an expression'), and immediately clarifies the two modes: indefinite or definite with bounds. This clearly separates it from siblings like differentiate_expression, calculate_expression, and symbolic_sum by naming the core operation.

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

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

Usage context is implied rather than stated: an agent can infer this tool is for integration from the name and description, but there is no explicit guidance on when to prefer it over related siblings such as differentiate_expression or calculate_expression. No exclusions or alternative routing are provided.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the key behavioral trait that variables are preserved, which goes beyond the annotations. It does not contradict annotations and provides useful context about the non-destructive nature of the interrupt. Minor gaps remain, such as what happens to the session after interruption (e.g., becomes idle or can resume), but the description covers the core behavior.

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

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

The description is a single sentence with zero fluff, front-loading the verb and resource, and immediately conveying the key preservation guarantee. Every word adds value.

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

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

For a tool with one optional parameter and an output schema, the description sufficiently conveys purpose and effect. It does not mention error conditions (e.g., no running computation) or session lifecycle after interrupt, but these are minor for a simple interrupt operation. The description is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the session parameter is fully documented in the schema. The tool description does not add any parameter-specific guidance beyond what the schema already provides, so it earns the baseline score of 3 for a well-covered schema.

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

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

The description clearly states the verb 'interrupt' and the resource 'Sage computation', and explicitly notes that variables defined so far are preserved, distinguishing it from siblings like reset_sage_session (which would clear variables) and stop/cancel session (which likely end the session). It is specific and non-tautological.

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

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

The description implies the usage context: use when a computation is running and you want to stop it without losing the workspace state. However, it does not explicitly name alternatives or state when-not to use it, such as 'if you want to end the session, use cancel_sage_session instead'. The 'while keeping variables defined so far' clause provides partial differentiation but leaves the exclusion implicit.

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 (idempotentHint=true, readOnlyHint=false, destructiveHint=false) carry the safety profile, but the description adds no behavioral context beyond them. It doesn't disclose that computation occurs in a Sage workspace, that results may be undefined or symbolic, or that the 'session' parameter implies stateful behavior — all of which would be valuable context for a computational tool.

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

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

The description is a single six-word sentence with zero filler and the key action front-loaded. It is appropriately terse, though arguably so minimal that it borders on under-specification for a tool with five parameters.

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 100% schema coverage, an output schema, and informative annotations, the structured data carries most of the load. The description is complete for stating the core purpose, but lacks usage context such as when a limit is appropriate versus a series expansion or direct evaluation, and gives no hint of the tool's limitations for a math-computation context with many siblings.

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

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

Schema description coverage is 100%, so the schema fully documents all five parameters including defaults and the session credential warning. The description adds no parameter-level detail, but the baseline of 3 applies because 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 ('Compute') and resource ('the limit of an expression'), which clearly identifies the mathematical operation. It is distinguishable from siblings like differentiate_expression and integrate_expression primarily through the tool name rather than the description text itself, but the purpose is unambiguous.

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

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

The description provides zero guidance on when to use this tool versus alternatives. There is no mention of when a limit is the right operation versus series_expansion, solve_equation, or evaluate_sage, and no exclusions or prerequisites 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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about 'named' workspaces and client scoping, which goes beyond the annotations without contradicting 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?

The description is a single, front-loaded sentence with no filler. It states the action, resource, and scope directly, achieving high efficiency.

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

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

For a simple listing operation with no parameters and a rich annotation set, the description covers the essentials. It doesn't mention return format or pagination, but the output schema exists to handle that. Minor gap: could clarify whether it lists all sessions or only active ones, but this is not critical given the scope.

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 are zero parameters and the schema coverage is 100% vacuously. The description adds no parameter details, but none are needed. Baseline 4 is appropriate for a no-parameter tool.

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

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

The description uses a specific verb ('List') and resource ('named Sage workspaces') with a clear scope ('belonging to this client'). It distinguishes itself from sibling session tools like start/stop/cancel by focusing on enumeration rather than lifecycle management.

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

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

The description implies usage (listing existing workspaces) but does not explicitly state when to use this tool versus alternatives like start_sage_session or cancel_sage_session. No exclusions or alternative conditions 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 the operation read-only, idempotent, and non-destructive. The description adds that the tool returns both documentation links and an availability flag, but does not disclose additional behavioral details such as error handling or whether missing symbols produce empty results.

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 conveys the core function and the availability-check nuance without wasted words. The key purpose is front-loaded.

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

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

Given the single parameter, fully specified schema, and safety annotations, the description is complete. The existence of an output schema means return-value details do not need to be in the 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 coverage is 100% and the single 'symbol' parameter is well described with an example. The description confirms it is a SageMath name but does not add substantial meaning beyond the schema.

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

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

The description clearly states the tool returns 'Documentation links for a SageMath name' plus availability information for the evaluate_sage tool. This distinguishes it from the many computation-oriented sibling tools.

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

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

The description implies when to use the tool: when documentation or availability for a SageMath name is needed, especially in relation to evaluate_sage caller code. It does not explicitly name alternatives or exclusions, but the context is clear enough.

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 convey idempotency and non-destructive behavior, and the description adds that the result is returned as nested lists. It does not disclose behavior on dimension mismatch, session state changes, or error handling, but given the annotation coverage the description is adequate, 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?

The description is a single sentence with no filler and front-loads the action. It is appropriately concise, though it is thin on usage and edge-case details; this keeps it from a perfect score but it is not verbose or 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?

For a simple operation with a fully documented schema and an output schema, the description plus annotations are mostly sufficient for calling the tool. However, it omits any mention of matrix dimension compatibility and provides no help distinguishing this tool from sibling Sage operations, leaving a meaningful 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?

The schema already documents all parameters thoroughly, including session behavior and exact integer handling, with 100% description coverage. The tool description only repeats that two matrices are multiplied and adds no parameter-level meaning beyond the schema, so the baseline score 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 uses a specific verb ('Multiply') and resource ('two matrices'), and states the output shape ('nested lists'). It clearly identifies the operation, but it does not explicitly differentiate itself from sibling tools like matrix_operation or evaluate_sage, so it falls one step short of a perfect 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?

There is no explicit guidance on when to use this tool versus alternatives, and no mention of matrix_operation or evaluate_sage as possible substitutes. The intended use is only implied by the verb and object, leaving the agent to infer when this dedicated matrix multiplication tool is the right choice.

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 supply idempotentHint=true and destructiveHint=false, so the description's burden is lower; it doesn't repeat or contradict them. The description adds only the single-matrix scope and the supported operation set, but says nothing about possible failure modes (e.g., inverse/eigenvalues require square matrices) or whether session state is mutated. With no annotation contradiction, 3 is the right mid-point.

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 operation list and ending with a routing preference. There is no filler, and every word contributes either to scope or to sibling differentiation.

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 rich schema (matrix exactness, session/bearer semantics), an output schema present, and annotations covering idempotency/destructiveness, the description has all it needs for selecting and invoking the tool. It names the one relevant generic sibling and clearly scopes to a single matrix. Operation-specific mathematical constraints are standard domain knowledge and don't block 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 the baseline is 3; the schema itself documents matrix exactness (decimal strings for large values) and session/workspace semantics in detail. The description's operation list merely repeats values already described in the operation parameter. It adds no semantic information beyond the schema.

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

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

The description names the resource ('one matrix') and enumerates the exact supported operations (determinant, inverse, eigenvalues, rank, rref, transpose), so an agent knows precisely what the tool does. It also distinguishes it from siblings by noting 'one matrix' (vs matrix_multiply) and explicitly preferring it over evaluate_sage. The generic title is resolved by the specific operation list.

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

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

It gives a clear routing instruction: 'Prefer this over evaluate_sage,' which tells an agent to use this specialized tool before falling back to the generic Sage evaluator. The 'one matrix' phrase also implicitly excludes matrix_multiply. It stops short of a 5 because it doesn't explicitly name matrix_multiply or state the conditions under which evaluate_sage should be used 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 the safety profile is covered. The description adds no behavioral context beyond listing operations, which is acceptable given the annotations. No contradiction exists, but it does not elaborate on return format or error behavior, which the output schema presumably 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?

The description is a single, front-loaded sentence that states the purpose and then gives the routing directive. There is zero redundancy or filler; every word 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 a rich output schema present, the description does not need to explain return values. It covers the full set of operations and the preferred alternative. The only minor gap is that it doesn't spell out which operations require the b parameter, but the schema's description for b explicitly states 'required for gcd and lcm,' so this is adequately covered elsewhere.

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 (a, b, session, operation) is already fully documented in the input schema, including the string rule for large integers and session semantics. The description adds no parameter-specific detail, which is fine because the schema carries the burden.

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's purpose: 'Number theory: primality testing, integer factorisation, the next prime above n, gcd and lcm.' This is a specific verb-resource pairing that clearly distinguishes it from the generic evaluate_sage sibling by naming the exact operations covered.

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

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

It gives explicit routing guidance: 'Prefer this over evaluate_sage for any of these.' This names the alternative tool and specifies the condition (any of the listed number theory operations) for choosing this tool, leaving no ambiguity for 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 indicate idempotentHint=true, destructiveHint=false, but the description adds no behavioral context beyond stating that it produces a rendered image. It does not explain any side effects, session state implications, or failure modes, relying entirely on the annotations for safety signals.

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. It efficiently captures the action, resource, and output format.

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

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

With 9 parameters and no output schema, the description gives the essential purpose and output type ('rendered image'), but does not address session behavior or how the image is returned (e.g., data URL, file). It is adequate for a simple plotting tool but leaves some operational detail unspecified.

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

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

The input schema covers all 9 parameters with descriptions, so the baseline is 3. The description itself does not add any parameter-level meaning, but it does not need to because the schema handles that burden.

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 'Plot a 3D surface of a two-variable expression as a rendered image' uses a specific verb and resource, and clearly distinguishes from siblings like plot_expression (2D) and plot_multi_expression (multiple expressions). An agent can immediately tell this is for 3D surface plots of a single two-variable 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?

The description provides no guidance on when to use this tool versus alternatives such as plot_expression or plot_multi_expression, and does not mention any exclusions or prerequisites. An agent is left to infer usage from the name and schema 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?

The annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the tool is a safe, non-destructive operation. The description adds that it returns a rendered image in PNG or SVG formats, which is beyond the schema. It does not mention side effects or resource limitations, but for a plotting tool this is sufficient.

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 sentence, efficient and to the point. It is appropriately front-loaded with the primary action and output. No wasted words, though it could arguably include a brief note about usage context without bloating.

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 a relatively simple tool with a clear schema and no output schema, the description covers the core function and output. It lacks explicit guidance on how the expression should be formatted (e.g., valid Sage syntax), but the schema and sibling names provide context. For a standard plotting tool, this is 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 coverage is 100%, so all six parameters are described in the schema. The description adds general context (plotting an expression) but does not add details about parameter interactions or syntax beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the detail.

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

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

The description clearly states the action (plot) and the resource (expression), and mentions the output format (rendered image). It is specific enough to distinguish from most siblings, though sibling tools like plot3d_expression and plot_multi_expression are not explicitly differentiated.

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

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

The description implies usage for plotting an expression, but does not explicitly state when to use this tool versus alternatives like plot3d_expression or plot_multi_expression. No exclusions or conditions are mentioned, leaving the agent to infer based on tool names.

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

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

The description adds context beyond annotations by stating the output is a rendered image and that expressions are overlaid on a single graph. Annotations already indicate idempotency and non-destructiveness, but the output format is a valuable addition not covered by annotations.

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

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

The description is a single, efficient sentence that front-loads the core purpose and output. No wasted words; it conveys the essential information without redundancy.

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

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

For a plotting tool with full schema coverage, the description adequately covers the high-level behavior, output type, and the overlay aspect. It does not mention any caveats or additional details, but given the schema's completeness, the description is sufficient for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description adds minimal semantic value beyond the schema, mainly reinforcing that multiple expressions are plotted. It does not clarify parameter formats or constraints beyond what the schema provides.

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

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

The description clearly states a specific verb ('Plot'), resource ('multiple expressions'), and output ('a rendered image') on a single 2D graph. It differentiates from siblings like plot_expression (single) and plot3d_expression (3D) through the phrase 'multiple expressions overlaid' and '2D'.

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

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

The description implies usage for multiple expressions but does not explicitly state when to use this tool versus alternatives like plot_expression or plot3d_expression. No exclusions or explicit conditions are provided; the guidance is only implicit through the tool name and description.

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 idempotent/destructive hints, and the description adds little beyond that. It does not disclose whether constructing rings mutates a session workspace, whether some operations are expensive, or how failures might manifest. There is no contradiction with the annotations, but the description does not meaningfully go 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?

The description is a single short sentence that is front-loaded and contains no filler words. It is concise, though the brevity contributes to the lack of substantive guidance.

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

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

For a tool with five parameters, five distinct operations, and a session/workspace concept, this description is too thin for an agent to select and invoke it confidently. The output schema may document results, but operation semantics and workspace-state implications remain underspecified.

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 repeats some nouns like rings and Groebner bases but adds no extra meaning about how base_ring, polynomials, operation, or session interact. It does not compensate beyond what the schema already provides.

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

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

The description identifies the domain ('polynomial ring operations') and mentions constructing rings and computing Groebner bases, ideals, and quotients, so the resource is clear. However, it is a category-level phrase rather than a specific verb+resource statement, and it omits several actual operations such as reduce, is_groebner, ideal_dimension, and ideal_variety. It also does not explicitly distinguish itself from the many other math *_operation sibling 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?

There is no guidance about when to use this tool instead of siblings like solve_equation, factor_expression, or group_operation. The phrase 'polynomial ring operations' implies a domain, but no exclusions, prerequisites, or alternative tool mentions are provided.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description does not need to repeat those. It adds scope ('current MCP session') but does not disclose what state is destroyed (e.g., variables, history) or whether any cleanup happens. With annotations covering the safety profile, the description adds minimal but non-contradictory context.

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

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

The description is a single, front-loaded sentence with no redundant wording. It conveys the core action and scope efficiently, earning a perfect score for conciseness.

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

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

For a simple tool with one optional parameter and an output schema, the description is adequate but minimal. It does not explain what 'reset' does to the session (e.g., clears variables, resets kernel), which is relevant for an agent deciding whether to call it. The output schema exists, so return values are covered, but the behavioral effect is underspecified.

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 the optional 'session' parameter, including default and handle semantics. The description adds no additional parameter information, 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 verb (reset) on a specific resource (SageMath session state) and clarifies scope (current MCP session). It distinguishes from siblings like start_sage_session, stop_sage_session, and cancel_sage_session. However, it does not specify exactly what 'reset' entails (e.g., clearing variables, restarting kernel), which would sharpen the purpose.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention when to prefer reset over stop_sage_session or interrupt_sage_session, nor does it state any prerequisites or exclusions. The agent must infer usage from the name and description 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?

The description adds no behavioral traits beyond the annotations. Annotations provide idempotentHint=true and destructiveHint=false, but the description does not explain side effects, error handling, return details, or limitations (e.g., singularities, convergence). It does not contradict the annotations, but also adds no transparency.

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

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

A single sentence that front-loads the core purpose with no filler or redundancy. Every word earns its place, making it highly 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?

The schema fully documents parameters and an output schema exists, so basic invocation is well-covered. However, the description omits guidance on differentiating from expansion-like siblings and provides no behavioral or usage context, making it only partially complete.

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

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

Schema description coverage is 100%, with all five parameters (order, point, session, variable, expression) documented in the input schema. The description adds no additional parameter semantics, so the baseline score 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 uses a specific verb ('Compute') and identifies the exact resource ('a Taylor/Laurent series expansion'). This clearly distinguishes it from sibling tools like expand_expression or simplify_expression, which handle algebraic expansion rather than power-series expansions.

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

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

The description implies usage: an agent can infer this tool is for Taylor/Laurent series expansions. However, it provides no explicit guidance about when to prefer this over expand_expression or other series-related siblings, nor any exclusions or alternatives.

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

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

Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context beyond the name. It does not disclose side effects, limitations, or what happens with complex expressions. Since annotations exist, the bar is lower, but the description still fails to add value, providing no insight beyond the structured fields.

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 sentence with no fluff, which is concise. However, it is under-specified, bordering on a tautology of the tool name. It is not misleading, but it provides minimal information, so it earns a 3 for being appropriately concise but not adequately informative.

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

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

Given the presence of an output schema and annotations, the description need not explain return values or safety. However, the description fails to provide any context for selecting this tool among numerous siblings, nor does it clarify what 'simplify' means in the SageMath context. The minimal description leaves the agent without enough to confidently choose this tool over related operations.

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

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

The input schema covers both parameters (expression and session) with descriptions, giving 100% schema description coverage. The tool description adds no additional meaning to the parameters, so the baseline of 3 applies. The description does not clarify expression format or session semantics beyond the schema.

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

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

The description states the verb 'simplify' and the resource 'mathematical expression', making the core purpose clear. However, it does not distinguish from sibling tools like expand_expression or factor_expression, which also transform expressions. Since it names the specific operation but lacks differentiation, it earns a 4 rather than a 5.

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

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

No guidance is provided on when to use this tool versus its siblings. There is no mention of alternatives, prerequisites, or scenarios where simplification is preferred over expansion, factorization, or other operations. The agent is left to infer usage entirely from the name and description, which is insufficient.

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 communicate idempotence and non-destructiveness, but the description itself adds no behavioral context. It does not mention session-related state, possible lack of closed-form solutions, or whether the operation can be expensive.

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 that wastes no words and usefully extends the title from 'equation' to 'system of equations.' Every part of the 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?

With a fully documented schema, side-effect annotations, and an output schema present, the main missing element is guidance on scope boundaries versus related equation-solving tools. For a straightforward solve utility, the definition is nearly complete, though not exemplary.

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

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

The input schema covers all three parameters with 100% coverage, including defaults, the list form for systems, and the session/workspace semantics, so the baseline of 3 applies. The description contributes no parameter-level meaning beyond what the schema already establishes.

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 the exact action ('solve') and resource ('equation or system of equations'), so an agent can tell what the tool does. It stops short of explicitly distinguishing itself from siblings like solve_ode and find_root, so it misses the sibling-differentiation tier.

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

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

The description implies when to use the tool: whenever an equation or system needs solving. However, it gives no explicit guidance about alternatives, such as preferring solve_ode for differential equations or find_root for scalar root-finding, and includes no exclusions.

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

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

Annotations already disclose idempotency and non-destructive behavior. The description adds that it returns a general solution with arbitrary constants, which is useful but not extensive. It does not mention any side effects or workspace-specific behavior beyond what the 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?

Two concise sentences with no fluff. The core purpose is stated first, followed by a clear usage hint. Every word earns its place.

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

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

Given the output schema and full schema descriptions, the description provides sufficient context for an agent to call the tool correctly. It clarifies the return type and gives a usage preference. It could be more exhaustive about edge cases (e.g., initial conditions) but is adequate for its 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% with detailed descriptions for all parameters. The description does not add any parameter-specific meaning beyond the schema, so the baseline score 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 (solve), a specific resource (ordinary differential equation), and a clear outcome (general solution with arbitrary constants). It also explicitly differentiates itself from evaluate_sage, making its purpose unambiguous.

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

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

Provides an explicit preference for this tool over evaluate_sage, which is a direct usage guideline. However, it does not mention when not to use it or other sibling alternatives like solve_equation, so it lacks full coverage of exclusions.

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

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

Annotations already communicate idempotency, non-read-only behavior, and non-destructiveness. The description adds the useful context of variable isolation per workspace. It does not, however, explain what happens if the named workspace already exists, whether a backend is spawned, or whether starting affects other active sessions — though idempotentHint softens that 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 sentence that states the core action and its key behavioral property with no filler. It is front-loaded with the verb and resource, making it easy for an agent to scan and understand quickly.

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

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

For a one-parameter tool with an output schema and idempotency annotation, the description covers the essential behavior: creating a named, isolated workspace. It does not spell out how sessions relate to subsequent evaluation tools or duplicate-name behavior, but the annotations and schema compensate for the most critical gaps.

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

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

The input schema fully documents the single 'name' parameter with an example ('curves' or 'scratch'), so schema coverage is 100%. The description's mention of 'named' simply mirrors the schema rather than adding deeper parameter semantics such as naming rules, uniqueness expectations, or allowed characters.

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

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

The description uses a clear verb-resource pair: 'Start a named Sage workspace'. It also adds a distinguishing detail ('with its own independent variables') that separates it from session inspection and mutation siblings. However, it never explicitly names a sibling or contrasts scope, so differentiation relies on inference.

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 intended use is implied by the description: call this when you need a fresh named workspace with isolated variables. But there is no explicit guidance about when to prefer this over evaluate_sage, reset_sage_session, or list_sage_sessions, nor any mention of prerequisites or session-lifecycle ordering.

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 idempotentHint=true and destructiveHint=false, covering the main behavioral concerns for a pure computation tool. The description adds no further behavioral disclosure (e.g., session effects or resource usage), but it does not contradict annotations. It is adequate but not enriched beyond the structured data.

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

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

The description is a single, well-structured sentence that front-loads the tool's purpose, lists concrete outputs, and then gives the usage preference. No filler or redundancy; 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?

For a simple statistics tool, the description combined with the full input schema, output schema, and annotations provides everything an agent needs to call it correctly. It identifies the domain, expected input, outputs, and relationship to a sibling tool, with no significant missing 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 input schema already fully documents both parameters. The description reinforces that 'data' is a list of numbers but adds no additional parameter semantics 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?

The description states a specific verb and resource ('Descriptive statistics for a list of numbers') and enumerates the exact outputs (mean, median, variance, standard deviation, min, max). It also names the sibling alternative (evaluate_sage) and explains why this tool is preferred, making it clearly distinguishable from similar math tools.

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

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

The description explicitly says to prefer this tool over evaluate_sage for summary statistics, giving an agent a direct routing rule. This is sufficient guidance for when to use this tool versus its most relevant sibling.

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 and idempotentHint=true, so the description does not need to restate those. It adds the useful behavioral detail that the worker is released, but it does not explain what is destroyed or whether the action is reversible.

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 efficient sentence with the action and object front-loaded. It contains no filler or redundant 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?

The tool is simple, has one parameter, and benefits from rich annotations, but the presence of cancel_sage_session, interrupt_sage_session, and reset_sage_session leaves significant ambiguity. An agent may not know which session-control tool is appropriate without further guidance.

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

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

The schema covers 100% of the single parameter with a clear description ('Workspace name to stop'). The main description adds only the word 'named', so it provides no extra semantics 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?

The description uses a specific verb ('Stop') and resource ('named Sage workspace') and adds the consequence 'release its worker'. However, it does not differentiate from closely named siblings like cancel_sage_session, interrupt_sage_session, or 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?

No guidance is given on when to use stop instead of cancel, interrupt, or reset. The sibling list contains several overlapping session-control tools, and the description provides no exclusions or alternative 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 already convey idempotence and non-destructiveness. The description adds useful behavior about closed-form computation and infinite-series support, which goes beyond annotations. It does not mention failure modes when no closed form exists, but the output schema likely covers return behavior.

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

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

Two short sentences, front-loading the main capability and then giving a decisive sibling-routing recommendation. No filler or redundancy; 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?

For a compute tool with a rich schema and output schema, the description covers the key use case and the most important sibling distinction. It is complete enough for an agent to select and invoke it correctly; only minor behavioral details like fallback when no closed form exists 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%, so the schema already documents all six parameters. The description adds only a high-level note about summations/products and infinite series, which does not materially deepen parameter understanding 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 operation ('closed form of a symbolic sum or product over an index variable') and explicitly distinguishes itself from evaluate_sage for summations. The domain and scope are clear even 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 says to prefer this tool over evaluate_sage for summations, naming the sibling and the condition. It does not discuss exclusions or alternatives for products, but the core guidance for choose-vs-evaluate_sage is direct and actionable.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, but the description adds no further behavioral context. It doesn't mention session requirements, side effects, or any operational details beyond the operation names. With readOnlyHint=false, it's unclear if there are side effects, and the description offers no clarification.

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 concise sentence with no waste, but it lacks structure and detail. It front-loads the operations list but doesn't provide any elaborative sections or guidance. It is appropriately brief but could benefit from a bit more explanatory structure without becoming 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?

For a tool with multiple operations and complex input types (scalar vs vector fields), the description is minimal. While the schema clarifies parameter formats, the description doesn't explain the distinction between scalar and vector inputs, or how operations map to them. It also doesn't cover the session parameter's purpose. Given the output schema exists, return values aren't needed, but usage context is lacking.

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

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

The schema provides comprehensive descriptions for all parameters (operation, expression, variables, session), achieving 100% coverage. The description adds no additional semantic meaning beyond what the schema already documents, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as performing vector calculus operations and lists the specific operations (gradient, divergence, curl, laplacian). This distinguishes it from siblings like differentiate_expression or integrate_expression, though it doesn't explicitly state it computes or evaluates these operations.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention any exclusions or context for selecting vector calculus operations, nor does it reference sibling tools. The description simply states what it does without indicating preferred use cases.

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?

Discloses far beyond the annotations: the proof ladder, honest-by-construction verdict semantics, that 'refuted' always exhibits a counterexample/enclosure, that decimal literals are read exactly, and that session assumptions are honored. None of this is derivable from the annotations, and it does not contradict 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?

The description is front-loaded with purpose and usage, and every paragraph carries genuinely useful information rather than filler. It is long, but the length is justified by the tool's subtle correctness semantics; still, the exactness and verdict sections could be tightened slightly without losing value.

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

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

Given the tool's complexity, five parameters, and an existing output schema, the description covers input syntax, allowed claim shapes, verdict meanings, precision and sample behavior, exactness caveats, and assumption handling. An agent has enough context to invoke the tool correctly without needing the output schema to explain return values.

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 already strong, but the description adds meaningful semantics for the primary parameter: what counts as a single comparison, four concrete claim examples, exact-decimal parsing, and the fact that session assumptions affect verdicts. It does not need to add much for samples, timeout, or precision_bits beyond their schema descriptions.

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

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

Opens with a precise verb and object: 'Independently re-check a stated mathematical claim' and names the four possible verdicts, which clearly separates it from solving, calculating, or plotting siblings. It also narrows the input to a single comparison in Sage syntax with concrete examples, so an agent knows what the tool is for.

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 'Use this to verify your own algebra before presenting it' and gives important context about when a verdict can be exact versus merely 'supported', including the machine-float caveat. It does not explicitly name alternative sibling tools or say 'use X instead', so it stops just short of full when/when-not routing.

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