arithym

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

Annotations provide minimal safety hints (all false), so the description carries significant behavioral burden. It successfully discloses critical traits: exact vs. approximate precision models, IEEE 754 flagging for transcendental functions, 2,000 node limits for models, 5-second computation timeouts, and state accumulation across workspace calls. It does not disclose error handling behaviors or rate limits, preventing a perfect score.

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 lengthy due to the tool's complexity (79 parameters, 7 subsystems), but it is well-structured with clear visual separation between subsystems and consistent example formatting. Every section serves a distinct purpose in explaining a subsystem. It could potentially be more concise, but the density of actionable information justifies the length for this complexity level.

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 high complexity (79 parameters, nested objects, no output schema) and lack of return value documentation, the description has a significant gap regarding output formats. While it mentions that transcendental results are 'flagged,' it does not describe the structure of returned exact fractions, JSON models, or workspace states, which is critical information for an agent consuming the results.

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

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

With 95% schema coverage, the baseline is high, but the description adds substantial value through concrete examples showing parameter interactions (e.g., tool='compute' action='factorize' n='360'). It explains the 'tool' parameter's role as a subsystem selector and clarifies how 'action' values map to specific functionality, adding semantic meaning beyond the schema's mechanical descriptions.

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

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

The description clearly identifies the tool as an 'Exact precision math engine' and specifically enumerates the seven subsystems (compute, calculate, reference, model, workspace, analyze, optimize) with distinct purposes. It explains the core value proposition—exact fractions with zero floating-point error versus IEEE 754 for transcendental functions—providing specific scope and capabilities.

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 effectively delineates when to use each subsystem via the 'tool' parameter, contrasting 'compute' (single operations) with 'calculate' (multi-step chains) and 'reference' (knowledge lookup). While it provides rich examples for each mode, it lacks explicit 'when not to use' guidance or failure mode warnings that would help an agent avoid incorrect subsystem selection.

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