Metro dev server (debug RN/Expo)

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

Annotations only declare the generic non-readonly/non-destructive profile; the description adds real behavioral context beyond that — start is consent-gated and performs adb reverse plus Metro launch, diagnose augments output with RedBox/logcat evidence and fixes. It still does not say what status returns or how long start takes to become ready.

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?

One dense sentence listing the actions with inline qualifiers, followed by a single follow-up routing sentence. Every clause earns its place and the operation list is front-loaded.

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 four-parameter, no-output-schema tool this is adequate but thin: the consent flow (approve vs consentId) and the meaning of sessionId are left unstated, and no return values are described. It covers enough to choose an action but not enough to call start confidently on the first try.

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 coverage is 0%, so the description carries the burden. It fully explains the action enum and implies the consent mechanism behind approve/consentId via 'consent-gated', but never explains what approve and consentId actually do or how sessionId scopes the call.

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?

Names a specific resource (the Metro bundler) and scopes it to debug RN/Expo builds, then enumerates the four operations (status, diagnose, start, stop) that map one-to-one onto the action enum. An agent can tell this apart from qa_build or qa_prepare_target without opening the schema.

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?

Each action is annotated with its purpose, and the definition explicitly routes the agent onward: 'After start, relaunch with qa_prepare_target.' It does not state when NOT to use this tool (e.g. release builds or non-Metro failures), which keeps it short of a 5.

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