2D Fourier transform

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

Annotations already cover safety (destructive=false, idempotent=true, openWorld=true), so the description's job is lighter. It still adds real value: the input is a real field of any shape, cost scales as N log N, and a Parseval energy check accompanies the result — none of which appears in the annotations or schema. Minor tension: it reads as a pure computation while readOnlyHint=false implies state change, though no explicit read-only claim is made.

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?

Roughly four sentences, each earning its place: capability, use cases, input routes, return shape, cost, and sibling disambiguation. The most load-bearing information (what it computes) is front-loaded, and the sibling note is correctly deferred to a parenthetical at the end.

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-but-pure numeric tool with an output schema (so return values need no prose) and full annotations, the description covers capability, inputs, direction, and cost. The remaining gaps are the meaning of 'im' and the relationship between the x and path inputs when both are omitted.

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 0% schema description coverage, the description must carry parameter meaning, and it partially does: 'x inline or path' clarifies the two mutually exclusive input routes and 'inverse flag' names the direction control. It never explains the 'im' parameter (imaginary component) or the null-default/optionality semantics, leaving one of four parameters undocumented in both schema and prose.

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 ('2D fast Fourier transform (or inverse) of a real 2D field') and adds concrete applications (image spectra, 2D convolution, field filtering). It also names the nearest sibling and positions itself against it: 'singularis_fft also accepts a 2D field; this tool is the explicit 2D entry.'

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 clear use contexts (spectra, convolution, filtering) and explicitly points at the alternative entry, singularis_fft. However it never states a rule for choosing between them — it only notes both accept 2D input — so the agent is left to infer which entry to prefer.

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