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

Beyond the annotations (destructive/idempotent/openWorld), the description discloses that execution halts on first error, that the response carries a freshly read screen plus per-step verdicts (✓ verified, ~ sent but unverified, ✗ failure/refusal), that non-ASCII text is pasted via clipboard and echoed back verbatim to the user, and the wait timeout bounds (5s default, 30s max). These are exactly the side-effect and verification details an agent needs before committing a destructive action.

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 purpose and stopping rule are front-loaded, and nearly every clause carries unique information; the step list and the reporting legend both earn their space. It is, however, one dense run-on with stacked parentheticals that is harder to parse than it needs to be.

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 10-step, destructive, open-world tool with no output schema, the definition covers ordering, per-step field semantics, confirmation policy, and the shape of the return (verdicts + refreshed screen). It is only incomplete on the `then` output selector and never states the prerequisite of reading the screen with `look` before choosing targets.

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?

With reported schema coverage at 0%, the description does the heavy lifting by mapping each `do` value to its fields: `type` (target = field to touch first), `key` (key list plus the confirm rule for enter/KEYCODE_*), `scroll` (direction = reading direction, down to continue), `swipe` (target → to), `wait` (text appears, or gone=true), `open_url` (text = address). The notable gap is the top-level `then` parameter (both/image/elements/none), which is never explained and directly governs what the agent gets back.

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 opening sentence gives a specific verb+resource (gestures on the phone, executed in order, then the refreshed screen) and the enumeration of ten step types makes the scope concrete. It never explicitly contrasts itself with siblings such as `launch` or `settings` for the cases where those would be the right pick, so it falls just short of a 5.

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 real operational rules: steps run in order and execution stops at the first error, `confirm=true` is required for enter and other KEYCODE_* and only on explicit user instruction or after a "yes", and targets are resolved against the screen read just before the gesture. What is missing is a stated alternative or when-not-to-use (e.g. "use look first", "use launch to start an app").

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

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

Annotations declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is already structured. The description adds real value on top: it discloses that clean=true also wipes application caches and explicitly reassures 'sans perte de données', which is exactly the side-effect context an agent needs before setting the flag. It stops short of 5 because it never says what the checkup returns.

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 sentences, front-loaded with the scope enumeration and closing with the one conditional behavior that matters. No filler. The enumeration is a laundry list but each item is a distinct inspection target, so it earns its space.

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 diagnostic tool with no output schema and no return-value description, the agent learns the scope and the clean side effect but not the shape of the report it will get back, nor cost/duration. Annotations cover the safety profile, so the remaining gap is the output contract. Adequate but incomplete.

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 0%, so the description carries the full burden for the single 'clean' boolean. It does so well, explaining that clean=true additionally clears app caches and that no user data is lost, which is meaning the bare schema cannot convey. A 4 rather than 5 because it does not state the default (false) or what other side effects, if any, accompany the flag.

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 names a specific verb-resource (a phone 'bilan'/checkup) and enumerates the exact subsystems inspected: system, security patch, battery, storage, memory, sideloaded apps, wireless debugging, accessibility. That is far more specific than the bare name 'checkup'. It does not, however, explicitly distinguish itself from siblings like 'info', 'settings', or 'phone', so it stops short of a 5.

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?

There is no statement of when to run a checkup versus 'info' or 'settings', nor any prerequisite or exclusion. The only usage-adjacent cue is the conditional behavior of clean=true, which is a parameter note rather than routing guidance. The agent must infer the use case entirely.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and the non-sending title, but the description adds valuable context: it opens the conversation with text pre-filled, permits accents, and describes the exact follow-up sending flow via act with confirmation and visual verification. It does not cover whether drafts persist or are editable, but it goes well beyond the structured safety hints.

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 purpose, then parameter details, then the sending condition, so an agent can parse it efficiently. It is dense but every sentence adds operational value; minor run-on structure prevents a perfect score.

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 simple three-parameter tool with no output schema, the description supplies purpose, parameter semantics, behavioral constraints, and the exact handoff to act for sending. The annotations already cover the safety profile, and nothing essential for correct invocation appears missing.

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?

With 0% schema description coverage, the description compensates substantially by explaining the 'to' parameter's accepted formats (name, phone number, conversation number in brackets, digits alone) and the 'app' enum values (sms/RCS or whatsapp). It also implicitly covers 'text' as the pre-written message body and notes accents are allowed, though it does not elaborate on text formatting or limits.

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: preparing a reply without sending it, opening the conversation with the text already written. It explicitly distinguishes this from the sibling tool 'act', which is reserved for actually sending. An agent can tell exactly what this tool does and does not do.

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 condition for using this tool (prepare without sending) and a clear alternative (use act with confirm) only when the user explicitly says 'envoie' for this draft. It also specifies target formats and app choices, leaving no ambiguity about when to invoke draft versus act.

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

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

The description adds real behavioral context the annotations do not: pull never overwrites, push is refused if the target already exists, and 'Rien n'est jamais effacé'. However, that last cluster directly conflicts with the annotation destructiveHint=true, so the agent receives contradictory signals about whether the tool can destroy data. Flagged as an annotation contradiction.

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 front-loaded paragraph states the resource first, then breaks each action into a labelled clause ('list :', 'pull :', 'push :'), so it scans quickly despite being dense. Every clause carries information (defaults, overwrite policy) rather than filler. Minor density cost only.

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 3-parameter tool with no output schema and 0% schema coverage, the description covers actions, defaults, overwrite/delete policy and path direction, which is most of what an agent needs. It does not describe what list returns (fields, recursion) or error behaviour, a modest remaining gap.

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 0%, so the description must carry the parameters, and it largely does: it defines action's three values, explains that path is the source file (on the phone for pull, on the PC for push), and gives per-action defaults for dest (~\Downloads\Telephone for pull, /sdcard/Download for push/list). It only leaves the exact meaning of path for list slightly implicit.

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 names a specific resource (the phone's shared storage: /sdcard, DCIM/Camera, Download, Documents) and enumerates the three concrete operations (list, pull, push) with their direction of transfer. An agent immediately understands this is a phone-file manager. It stops short of 5 because it never contrasts itself with any sibling tool (e.g. 'phone').

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 given a clear use context: list reads a folder's contents (default /sdcard/Download), pull copies phone→PC, push copies PC→phone, and the defaults per action are stated. This tells the agent which action fits which task. There is no explicit when-not-to-use guidance or named alternative, so it is not a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and 'Lecture seule' merely restates the read-only annotation. The description does add useful content-level context (what each kind returns, e.g. accuracy/age/Maps link, received/outgoing/missed call types), which goes beyond the annotations. No auth, rate-limit, or failure behavior is described, but that bar is lower given the annotation coverage.

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?

A single compact sentence with the read-only qualifier front-loaded, followed by a tight per-kind listing with no filler. Every clause maps to a distinct mode and earns its place, though the enum-legend format is slightly dense.

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?

An output schema exists, so return values need not be explained, and the description adequately covers the dispatcher's modes. The gaps are the undocumented `limit` parameter and the absence of routing guidance against similar siblings, which are minor given the schema and annotations.

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 0%, so the description must carry parameter meaning, and it does for three of four: `kind` (all four enum modes explained), `query` (a name for contact lookup), and `days` (calendar horizon). Only `limit` is left undefined, so it substantially compensates for the coverage gap without being complete.

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 functions as a legend for the `kind` enum, stating exactly what each mode returns (last known position, recent calls, numbers for a name, upcoming calendar). This gives an agent a clear picture of the tool's scope even though the name `info` itself is generic. It does not, however, differentiate from overlapping siblings such as `messages`, `notifications`, or `phone`.

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?

Usage is implied by the per-kind breakdown, so an agent can infer that `kind=contacts` + `query` is for looking up a number, and `kind=calendar` is for an agenda. But there is no explicit when-to-use guidance and no mention of alternatives among the many siblings (messages, notifications, phone), leaving routing ambiguous.

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

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive). The description adds that the app becomes visible/foregrounded ("puis la voir"), which is real behavioral context beyond the annotations, but it says nothing about failure modes when the app name doesn't resolve or whether launching an already-running app is a no-op.

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, front-loaded with the action and immediately followed by accepted input formats. No filler. The trailing "puis la voir" is slightly vague but costs almost nothing.

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 single-parameter, no-output-schema tool with annotations covering the safety profile, the description supplies the two things that matter: what the tool does and how to format the only argument. Nothing essential for correct invocation is missing.

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% — the single `app` parameter has no description in the schema — so the description carries the full burden, and it does: it explains both accepted forms (full package name or a fragment) with concrete examples. This meaningfully compensates for the coverage gap.

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 and resource in plain terms: open an application, and it specifies the accepted identifier forms with concrete examples (com.whatsapp, "whatsapp", "maps"). It does not explicitly contrast itself with siblings like act or look, but the action is 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?

Usage is implied through the argument guidance — you call it with a package name or a partial name to bring an app forward. There is no statement of when to prefer this over act/look/checkup, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's value is the extra behaviour it discloses: the numbered-element return shape, the privacy fallback where the image is withheld when the UI tree is unreadable, and the consent requirement for confirm. That is real context an agent cannot get from the annotations, though the phrasing of the fallback is cryptic.

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?

Purpose is front-loaded in the first clause, then each parameter is dispatched in a short fragment. No filler sentences; density is high without being padded.

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 4-parameter, zero-coverage, read-only tool with no output schema, the description covers return format, every parameter, and the safety fallback. What is missing is routing against the ten siblings and any note that this is the observation step preceding act.

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 carry the load and largely does: show modes with the default, query as a text filter over listed elements, region as a zoom box measured in pixels of the last full image, and confirm tied to user consent. Only confirm's exact effect remains under-specified.

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 concrete verb and resource ('Voir l'écran du téléphone') and describes the payload precisely: numbered elements with role, text, states and centre coordinates, plus an image. It is clearly the observation tool among siblings like act and launch, though it never names a sibling explicitly.

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 only real when-to-use rule is for confirm ('posé seulement avec l'accord de l'utilisateur'), which is genuinely useful. The show/query/region text explains what each option does but not when to prefer look over act or info, and there are no exclusions or prerequisite (e.g. must call before act) guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add operational context — and it does: a 500-message ceiling, the semantics of the `images` count, and the important caveat that videos and files are only signaled rather than returned. It does not discuss pagination or failure behavior, which keeps it short of a 5.

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 two-mode structure is front-loaded: identity of the resource first, then the no-argument behavior, then the filtered behavior. Sentences are dense but each carries distinct information (limits, unread counts, attachment handling) rather than padding.

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?

With no output schema, the description responsibly sketches the return shape (contact, date, unread flag) and the attachment policy. For a 4-parameter tool at 0% schema coverage this is close to complete; missing only default-value explanations and any error/empty-result behavior.

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 0%, so the description carries the full burden and largely succeeds: `limit` is bounded at 500, `images` defaults toward returned photos with 0 meaning none, `contact` is identified as a directory name, and `conversation` takes an integer ID. Only the numeric defaults (15, 4) are left unexplained, which is a minor gap.

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 names a concrete resource ('SMS et RCS du téléphone') and spells out its two operating modes — recent-conversation listing vs. per-conversation message retrieval — so an agent immediately knows what it returns. The verb is only implied rather than stated, and no sibling tool is named, but the sibling set (files, notifications, phone) shows little overlap, so differentiation is not critical.

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 clearly states the conditions that select each mode: no argument yields recent conversations with contact/date/unread, while conversation=N or contact="Alice" yields the last `limit` messages. There are no explicit exclusions or named alternatives, but the branch conditions make usage unambiguous in practice.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: newest-first ordering, security codes being masked, and the Android platform limitation that only the app name survives for removed notifications. It does not cover result size or the limit parameter's effect.

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?

Dense and front-loaded: resource and returned fields come first, then the all=true condition, then the platform caveat. No filler sentences, though the compressed phrasing makes the trailing Android note easy to misread.

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?

With no output schema, the description usefully enumerates the returned fields and ordering, which an agent would otherwise have to guess. The only real gap is the undocumented limit parameter and any indication of how many results come back.

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 0%, so the description must compensate. It explains `all` well (include permanent/ongoing-service notifications), but `limit` is never mentioned — no default of 40, no maximum, no truncation behavior. Half the parameters remain unexplained.

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 (notifications displayed on the phone) and enumerates the returned fields (app, time, title, text), plus ordering (most recent first) and masking behavior. This is enough to separate it from siblings like messages or phone 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?

Usage is implied rather than stated: the agent infers this is the tool for reading phone notifications. The only conditional guidance is 'all=true: also permanent (ongoing service) notifications', which is more parameter semantics than a when-to-use rule. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's contribution is the enumeration of reported fields, which is useful but partially redundant with the output schema. No rate limits, freshness, or failure modes are described.

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?

A single sentence that front-loads the core fact (link state) and then lists the additional reported fields. Nothing is wasted and nothing is buried.

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?

With an output schema present, the description need not explain return values, and annotations cover safety. It supplies the right amount of context for a zero-parameter status reader. The only gap is the absence of any hint about when this probe is the right choice.

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 the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing argument behavior.

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 names a specific resource and enumerates exactly what is reported: link state, connection type (USB or Wi-Fi), model, screen, and foreground application. That is far more informative than the bare name 'phone'. It does not, however, distinguish itself from overlapping siblings such as 'info' or 'checkup', so it falls short of a 5.

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?

There is no statement of when to call this tool versus alternatives, nor any prerequisite or context. An agent must infer from the name alone that this is a status probe, and with siblings like 'info' and 'checkup' present the routing question is left entirely open.

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

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

Annotations say readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds valuable nuance: changes are reversible, and reading happens after change. It also discloses a specific refusal condition for Wi-Fi. That's meaningful behavioral context beyond annotations.

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 structured in a few dense lines: purpose, then a per-setting value legend. It's front-loaded with the read/write behavior. Slightly terse and mixing French/English terms, but every sentence carries information.

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?

With an output schema present, return values needn't be described. The description gives enough for an agent to call correctly: when to read vs write, allowed values per setting, and a key constraint. It could be more complete about error handling for invalid values, but it's solid for a simple 2-param tool.

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 0%, so the description must compensate. It does: it explains the 'name' enum semantics for each setting and gives value formats/ranges (on/off, 1-100%, auto, 0-100%, dnd modes). Only gap: it doesn't explicitly map each format to each enum name, but it's inferable.

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 this tool controls phone settings (read or modify) — a specific verb+resource. It's distinguishable from siblings like info or phone. The dual read/write behavior is explicitly stated ('sans value, lit l'état ; sinon le change puis le relit').

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 explains when to read vs write based on the presence of the 'value' parameter. It also gives a specific constraint: cutting Wi-Fi is refused when the connection goes through it. However, it doesn't mention alternatives or when not to use the tool for other settings not listed.

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