analyze_rf_signal

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

No annotations are provided, so the description carries the full burden. It mentions 'attack planning' and 'replay attack guides' which imply potentially destructive actions, but it does not disclose any behavioral traits such as required permissions, side effects, rate limits, or whether modifications are irreversible. This is a critical gap for a tool with attack capabilities.

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 a single sentence that efficiently lists core capabilities. It is front-loaded with key terms, but could be more structured with bullet points or separation of modes for clarity.

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?

The tool has 14 parameters, 8 modes, and no output schema. The description is too vague to fully guide an agent; it does not explain what each mode returns, prerequisites, or how parameters interact. For a complex tool, this is incomplete.

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 100%, and each parameter has a descriptive role (e.g., [setup_guide] for OS). The main description adds minimal additional meaning beyond the schema, just listing high-level capabilities. Baseline 3 is appropriate given the schema does the heavy lifting.

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 does 'RF signal analysis and attack planning' and lists specific capabilities like protocol identification, signal analysis, replay attack guides, and SDR hardware selection. This is a clear verb+resource, but it does not differentiate from sibling tools such as scan_wifi_networks or analyze_wifi_security which also involve RF analysis.

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. The description lists operation modes but does not explain when each mode is appropriate or exclude sibling tools. For example, an agent might not know whether to use analyze_rf_signal or find_wifi_attacks for a specific task.

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