settings

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

No annotations, so the description carries the full burden, and it does well: it discloses reversibility (réversibles), the read-modify-reread behavior, and one notable refusal condition (cutting Wi-Fi when the link depends on it). This is genuinely useful behavioral context. It could go further on what failure looks like, but it's solid.

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?

Well-structured: one line for the read/write semantics, then per-setting value vocabularies in a compact block. Front-loaded and dense with useful detail. Minor verbosity from French phrasing but every sentence earns its place.

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 two params and no output schema, the description covers the read/write duality, value formats, and one refusal case. It's nearly complete; a brief note on error reporting or the return value (re-read state) would finish it, but the essentials are present.

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 must compensate, and it does: it explains each enum value of name and the accepted value formats per setting (on|off, priority|alarms, 1-100/auto, 0-100). The only gap is that value is typed as a free string in the schema, and the description does convey format per setting, which is exactly what's needed 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?

The description states a specific verb+resource in French: read a phone setting (sans value) or change then re-read it (sinon le change puis le relit). It's clear this is a get/set for named device settings, distinct from siblings like info or phone. The only weakness is that it's in French while the tool ecosystem is otherwise English-named.

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?

It gives concrete per-setting value vocabularies (on|off for toggles, on|off|priority|alarms for dnd, 1-100|auto for brightness, 0-100 for volume) and one explicit refusal rule (coup de Wi-Fi refusé quand la liaison passe par lui). No sibling alternatives are mentioned, but the get-vs-set semantics are clear.

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