micro_doppler_signature

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

With no annotations, the description must convey behavioral traits. It indicates a computational analysis (read-like) but does not mention side effects, permissions, computational cost, or whether it modifies state. The default parameter suggests it uses previously loaded data, but no details on dependencies or outcomes.

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 one sentence, front-loaded with the core action. However, it is overly terse and lacks structured details that would aid an agent without sacrificing efficiency.

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?

Despite an output schema being present, the description provides no context on the expected output or how the result relates to the input. For a specialized tool with domain jargon, more context (e.g., what a cadence spectrum is, what rotors vs flutters means) would improve completeness for an AI agent.

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%, and the description does not explain the only parameter 'source' (default 'last_loaded'). No insight into valid values, behavior when changed, or its impact on the extraction.

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 the tool performs 'cadence-spectrum periodicity extraction' specifically 'for rotor-vs-flutter style signature comparison', clearly indicating the operation and context. It distinguishes itself from sibling tools like range_doppler_map or ca_cfar_detect by targeting periodic micro-Doppler signatures.

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?

No guidance on when to use this tool versus alternatives. It does not specify prerequisites, data requirements, or scenarios where it is applicable, leaving the agent to infer usage from the description alone.

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