cellular

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 clearly indicates this is an emulation-only tool that affects radio state (which can disrupt connectivity), and that every field is optional. It does not disclose whether changes are reversible, what happens if two serials are attached, or if there are side effects like dropping ongoing calls. While reasonably transparent, there is room for more detail.

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 paragraph of about 60 words, front-loading the core action first. Every sentence adds information: purpose, parameters, use cases, constraints. It avoids redundancy but could be slightly more structured (e.g., separate sentences for each aspect) without adding length.

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?

Given there is no output schema and no annotations, the description covers the essential purpose, parameters, use cases, and constraints (emulator-only) adequately for a tool with 6 optional parameters. It explains how to specify throughput and latency both as named profiles and raw values. It could be more complete by mentioning that changes may affect other running apps or that serial is required when multiple devices are attached.

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?

The input schema already provides full (100%) coverage with descriptions for each parameter, so the baseline is 3. The description adds value by explaining the meaning of signal strength values and giving examples for network_delay and network_speed (e.g., 'lte', '<up>:<down> kbps'), which enriches understanding beyond the schema. However, it does not explain the enum values for data/voice or the effect of profiles like 'full'.

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 uses specific verbs ('Shape the emulated cellular radio') and clearly identifies the resource (cellular radio on an emulator). It enumerates the three controllable aspects (registration state, signal strength, throughput/latency) and distinguishes it from sibling tools like phone_call or send_sms which are also telecom-related but perform different actions.

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?

The description explicitly states the tool is 'Emulator-only', which is crucial for knowing when not to use it (e.g., on physical devices). It also provides example use cases ('Test offline/roaming/weak-signal and slow-network behaviour deterministically'), giving clear context. However, it does not mention alternatives or explicitly say when to avoid this tool in favour of others.

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