reload_app

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It honestly states 'best-effort', 'may silently no-op with no error', and details the exact conditions under which the tool works (debug builds, classic non-bridgeless architectures). This provides excellent transparency about limitations and failure modes.

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 front-loaded with the core purpose ('Best-effort: trigger a Metro/JS reload...') and then efficiently covers prerequisites, limitations, and alternatives. Every sentence adds value, though the prerequisites section is slightly lengthy. Still, it remains focused and avoids redundancy, earning a high score for conciseness.

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 the complexity of the tool (best-effort, silent failures, strict environment requirements) and the absence of an output schema, the description is remarkably complete. It covers prerequisites, failure modes, conditions for effectiveness, and fallback alternatives. No additional information is needed for an agent to use this tool correctly.

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%, so the schema already documents both parameters adequately. The description does not add new semantic information about the parameters beyond what the schema provides (e.g., serial optional when one device, package format). Baseline score of 3 is appropriate as the description adds no extra value for parameter understanding.

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 clearly states the tool triggers a Metro/JS reload on React Native dev-client builds. It specifies the verb 'trigger', the resource 'Metro/JS reload', and the context 'RN dev-client build'. It also distinguishes from sibling tools like open_dev_menu and tap_on_text by providing alternative steps, making the purpose unambiguous.

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 when to use this tool ('debug builds of classic RN architectures') and when not to ('newer RN/Expo dev clients may silently no-op'). It provides a direct alternative ('use open_dev_menu then tap_on_text("Reload")') and a prerequisite ('run adb_reverse {device_port: 8081} first'), offering complete guidance on usage.

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