singularis_fft

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

With no annotations, the description carries the full burden and does much of it: it discloses the return shape ([real, imag] pair with first axis), the Parseval energy check, that inputs/outputs may be inline or .npy paths, and the O(N log N) cost profile. It omits failure modes (invalid shapes), whether input arrays are mutated, and any overwrite semantics for file paths.

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?

Purpose leads, followed by inputs, outputs, the inverse round-trip, and complexity — each short sentence adds distinct operational information with no filler or repetition of the schema.

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

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

An output schema exists, so return values need not be re-explained, yet the description still supplies the essential pair shape and energy check. Combined with the clear input-format guidance, an agent has enough to call the tool; only edge-case behavior and x/path mutual exclusivity are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: x is 'inline or path', the inverse flag's meaning and the required round-trip input format ([real, imag] pair) are spelled out. It does not clarify resolver precedence when both x and path are supplied, which is the one real ambiguity.

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 ('Fast Fourier transform (or inverse) of a real 1D signal or 2D field') and enumerates the target workloads (spectra, convolution, circulant systems, filtering). An agent can immediately distinguish this from siblings like singularis_solve_heat, singularis_gemm, or singularis_blur.

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 clear usage context via the application list and gives an explicit recipe for the inverse case ('pass that same [real, imag] pair back as x with inverse=true'). However, it names no alternatives or when-not-to-use conditions, so routing between this and any overlapping sibling is left to inference.

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