Restart the Betaflight flight controller safely; the command is refused if the craft is armed. The serial connection closes, so reconnect after a few seconds.
Redémarre le FC (refusé si armé). La connexion est fermée : rappeler connect après quelques secondes.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation already flags this as destructive and non-idempotent, so the description earns credit for going further: it discloses the guard condition ('refusé si armé'), the post-condition (the connection is closed by the call), and the required recovery step with timing. That is exactly the behavioral context an agent needs before invoking a destructive reboot.
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?
Two short sentences, both load-bearing: the first covers the action and its refusal condition, the second covers the side effect and recovery. Nothing is padded and the refusal condition 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 no-parameter destructive tool with no output schema, the description covers the essential pre-state, post-state, and recovery guidance. The only minor gap is the vague 'quelques secondes' timing and no note on what the agent should observe to confirm the FC is back up.
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 tool takes zero parameters, so there is no parameter semantics to explain; baseline is 4. The description correctly contains no parameter discussion, though there is nothing extra it could add here.
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?
States a specific verb and resource ('Redémarre le FC') and immediately couples it with a scope condition ('refusé si armé'). An agent can distinguish this from sibling connect/disconnect/get_fc_status without opening any 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?
Gives a clear precondition for refusal (armed state) and a follow-up action (call connect after a few seconds). It does not name an explicit alternative tool or say when a restart should be chosen over, e.g., disconnect + connect, but the operational context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.