Lingshu Solver

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

With no annotations, the description carries the full burden and does so richly: it states the tool is closed-form, deterministic, exact to floating-point rounding, and returns identical output for identical input. It also explains the critical trust.trustLevel field with exact, definitely_none, and degenerate semantics, including what to report for degenerate inputs.

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, determinism, invocation pattern, and trust semantics before the long op catalog. The catalog is unusually long but necessary because the schema does not enumerate op values. It is dense rather than padded, though the length is significant.

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 complex computational tool with no output schema, the description supplies the op catalog, argument convention, and the important trust.trustLevel semantics. It does not fully describe the return shape or error behavior beyond trust, so an agent still has minor gaps about output structure, but the critical invocation and safety context are present.

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?

Although schema coverage is 100%, the schema only defines op as a string. The description goes far beyond it by listing the valid op values grouped by dimension, explaining that remaining args are passed flat and depend on op, and pointing to an unknown-op catalog for full signatures. This is essential parameter semantics not available in 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 a specific domain (deterministic 1D/2D/3D geometry) and enumerates concrete operations such as distances, intersections, areas, and hulls, so the tool's purpose is unambiguous. However, it does not distinguish itself from sibling tools like solve or poly_roots, leaving overlap for an agent to infer.

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

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

It explicitly says to use the tool instead of doing geometry manually, and it explains how to invoke it via {op, ...args}. It also provides a routing fallback: sending an unknown op returns the full catalog with signatures. No when-not or sibling-alternative guidance is given, but the core usage 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?

With no annotations, the description carries the full behavioral burden and discloses the key side effect: text is written to a local log only and never transmitted elsewhere. It does not cover log location, permissions, or return behavior, but the critical data-handling trait is stated.

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 efficient sentences. The primary purpose and trigger conditions are front-loaded, and the second sentence adds essential behavioral context 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?

For a simple two-parameter feedback tool with no output schema and no annotations, the description covers purpose, usage triggers, and data handling adequately. It could be slightly more complete by clarifying whether feedback should also be given when verify finds issues, but the core context 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 description coverage is 100%, and the schema already documents both context and message thoroughly. The description adds no parameter-specific syntax, format, or constraints beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and target: reporting a problem to the operator. It also specifies the exact triggering conditions tied to the sibling tool solve, making it easy to distinguish from computational siblings like solve, verify, and poly_roots.

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

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

It clearly says when to use the tool: when solve hits a dead end, returns an error, or produces something believed wrong. It does not state when not to use it or name explicit alternatives, but the contextual guidance is strong 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?

With no annotations, the description carries the full burden and largely does: it discloses that metering is off, no credential or call limit applies, there is no self-crediting step, no reconciliation wait, the operator reconciles against a corporate bank statement, and that payIntent.payTo can be null. The only gap is that the dense, duplicated parentheticals make the safety/mutation profile harder to extract than it should be.

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 text is front-loaded with a confusing claim that no payment is needed for a tool called 'pay', contains a literal duplication — '(metering off) (metering off: no credential required...)' — and runs long without clear ordering. Several clauses repeat the same 'free / no charge / no credential' idea three or more times.

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 no-annotation, no-output-schema, zero-required-param tool, the description does cover the key behaviors including the null payTo edge case. But the messaging is inconsistent enough (a payment tool that insists no payment is required) that an agent would still be unsure what calling it actually accomplishes, so it is not fully 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% and all four parameters are documented in the schema, so the baseline is 3. The description adds a little context (the corporate static channel, the retired selfReportPaid semantics) but mostly restates behavior rather than clarifying how to supply the parameters.

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 tool does eventually state a specific action — 'This tool records a support contribution of any amount' — which is a concrete verb+resource and unique among siblings (give_feedback, poly_roots, solve, verify are unrelated). However, the opening sentences ('no payment is needed at all', 'metering off') spend most of their space arguing that the tool named 'pay' is not actually needed, so the core purpose is buried and somewhat self-undermining.

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 indicates the tool is 'optional voluntary-support only' and describes the no-payment-method-configured case, so some usage context is implied. But it names no alternatives and never cleanly states when an agent should call this versus simply calling the endpoint with no credential — it in fact says to 'just keep calling the endpoint with no credential at all', which weakens the case for invoking this tool.

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

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

With no annotations, the description carries the full disclosure burden. It usefully discloses the certification method, strict error box, and real-only output, but says nothing about failure modes (no real roots, degenerate input), multiplicity handling, or determinism.

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

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

Three tight sentences with the core behavior front-loaded; the coefficient convention and exclusions are placed after the main statement. The 'instead of letting a language model estimate roots' line is slightly promotional but still earns its place as a usage cue.

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

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

There is no output schema, so the description must describe the return value; it only implies a list of roots with error boxes and never specifies the structure (e.g., intervals vs. points) or ordering. Adequate for a simple two-param tool, but the return contract is left partly implicit.

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 both parameters are already documented, and the description's coefficient-ordering example duplicates the schema text verbatim. The optional tolerance parameter is never mentioned in the description, so no value is added beyond the schema.

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

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

States a specific verb and resource ('All real roots of a polynomial') plus the method guarantee ('Krawczyk-certified with a strict error box'), which an agent can distinguish from generic solvers like solve/verify. It also explicitly bounds scope by excluding complex roots.

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

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

Gives a clear when-to-use directive ('Use it instead of letting a language model estimate roots') and states the exclusion (complex roots not returned). It does not contrast against the plausible sibling tools solve or verify, so the routing guidance is incomplete.

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

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

With no annotations, the description carries the full burden and does so well: it discloses determinism (identical result, safe for caching and retries), capability limits (algebraic + listed transcendentals, max 6 variables, no initial guess), a result-safety signal via the trust block, the truncated-result risk and how domain mitigates it, and the honorPaid payment semantics. This is the behavioral context an agent needs before calling.

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 purpose is front-loaded in the first sentence and the dense single paragraph is largely information-bearing rather than filler. It is longer than typical and somewhat run-on, but for a 6-parameter tool with no output schema and no annotations the length is justified.

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 no output schema and no annotations, the description covers limits, determinism, result-safety via the trust block, domain guidance and the payment flag. It is nearly complete; the only real gap is that the actual shape of the returned result (beyond the trust flag) is not described.

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 already 100%, so baseline is 3. The description goes beyond the schema by advising when to supply domain explicitly ('for exp/sin or large ranges, else truncated may be true'), which is operational guidance the schema only hints at. The meaning of honorPaid is also reinforced at a level the schema alone conveys more tersely.

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

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

States a specific verb and resource: a 'Deterministic (non-LLM) solver for systems of real equations', which an agent can immediately place. The exclusions ('Not for symbolic derivation, initial-value ODEs, or integer constraints') help separate it from general math work, but the description never names the obvious sibling poly_roots, so the boundary with that tool is left implicit.

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

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

Gives a clear positive trigger ('Use it instead of computing the math yourself whenever a wrong number has a cost') and explicit exclusions (symbolic derivation, IVP ODEs, integer constraints). It also points to the trust block and the domain parameter as conditions. It stops short of naming sibling alternatives such as verify or poly_roots, so it is strong context without full 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?

With no annotations, the description carries the full burden, and it delivers: it names the verdict values (verified / refuted_or_unverified), explains what they mean, and exposes the self-correction field (nearestCertifiedRoot) and determinism. It does not describe tolerance behavior or any failure/error modes, which keeps it below a 5.

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

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

One tight paragraph, front-loaded with the core action and followed by the outcome semantics an agent needs. Sentences are long but every clause (verdict meanings, nearestCertifiedRoot, determinism) earns its place; no filler.

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

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

There is no output schema, so the description must explain return values, and it does explain verdict and nearestCertifiedRoot. Combined with 100% schema coverage on inputs, an agent has what it needs to call and interpret the tool, though tolerance semantics remain unexplained.

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

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

Schema description coverage is 100%, so every parameter including tolerance and variables is already documented in the schema. The description reinforces the 'claimed answer' intent but adds no format or syntax detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb and resource ('Check whether a claimed answer is actually correct') in the first clause, and contrasts with the solving siblings (solve, poly_roots) by framing it as verification rather than computation. An agent can distinguish it from any sibling without opening a schema.

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

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

Gives explicit when-to-use guidance: 'call this on any number you computed yourself before passing it downstream.' That is a clear trigger condition. It does not name or exclude the alternative siblings (solve, poly_roots), so it stops short of full routing guidance.

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