polynodes_isomorph_bp_center

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is covered structurally. The description adds almost nothing beyond the value range (which the schema itself already states) and a generic 'JSON confirmation' note; it says nothing about units, clamping behavior at the 0/5000 bounds, or whether the isomorph module must be active.

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 sentence is front-loaded and tight, but the 'Args: params: value' and 'Returns: JSON confirmation' boilerplate is pure filler given the schema and existing output schema. A single-parameter setter needs one sentence, not a stub docstring scaffold.

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 numeric setter with annotations and an output schema, the description is only just sufficient: it states the action and the range. Missing are the unit of measurement, behavior at boundaries, and any dependency on the isomorph switch, which an agent would need to call this correctly in 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 0% per the context signals, so the description carries the burden, yet 'Args: params: value' is a tautology that simply renames the parameter. The '(0-5000)' range is the only substantive detail and merely duplicates the schema's own min/max and nested description; no unit (Hz?) or effect on the signal is explained.

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 first sentence names a specific verb and resource ('Set isomorphic bandpass center frequency') plus a range, which distinguishes it from the many sibling setters like polynodes_set_filter_freq or polynodes_isomorph_mod_depth. It stops short of explicitly contrasting with those siblings, so it is clear but not sibling-differentiating.

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 statement of when to use this tool versus alternatives, nor any prerequisite such as needing polynodes_isomorph_switch enabled or a note about interaction with polynodes_isomorph_mod_depth. Usage is left entirely to inference from the name.

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