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

With no annotations, the description carries the full behavioral burden and does so well: sequential execution with stop-at-first-error, targets judged against the screen re-read immediately before the gesture, non-ASCII text routed through the clipboard, confirm gating requiring an explicit user "yes", and a result legend (✓ verified / ~ sent-unverified / ✗ failed-or-refused). This is substantive disclosure an agent cannot get from the schema.

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?

Front-loaded with purpose in sentence one, then a dense semicolon-delimited catalogue where nearly every clause carries new information, closed by a concrete compound example. It is long but not padded; the compression into one paragraph makes it slightly harder to scan than a bulleted form would 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 tool with 10 gesture types and 10 step fields, no annotations and no output schema, the description covers execution order, error behavior, target resolution, confirmation gating, and the shape of the result. Return-value detail is thin ("l'écran à jour" plus the ✓/~/✗ legend) and preconditions such as device unlocked state are unaddressed, so a small gap remains.

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?

Though the reporting signal puts schema coverage at 0%, the description compensates with real semantics: the "[N]" bracket convention and the rule that a bare number is treated as literal text (not an index), target formats "x,y"/visible text, per-gesture field mapping (direction = content direction, gone for wait, keys incl. ctrl+a), and the confirm requirement for enter/KEYCODE_*. It leaves amount and timeout uncovered, so not a full 5.

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 states a specific verb+resource: it executes gestures on the phone in order, stopping at the first error, then returns the refreshed screen. That is far more precise than a tautology and clearly marks it as the action counterpart to the read-only siblings (e.g. "look"), but no sibling is named, so differentiation is left implicit.

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 gesture vocabulary and per-step field rules (e.g. confirm=true for enter/KEYCODE_*), but there is no explicit when-to-use / when-not-to-use statement and no mention of alternatives such as "look" for observation or "launch" for starting apps. The agent must infer the boundary from the semantics.

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?

With no annotations, the description carries the full burden. It does add real value by disclosing that clean=true also wipes application caches "sans perte de données," which flags a state-changing side effect. It says nothing about permissions required, runtime, whether the scan itself is read-only, or how results are surfaced, which is thin for a mutation-capable tool with zero 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?

Two dense sentences, no filler, with the diagnostic scope stated first and the flag semantics second. The long comma-delimited list of audited areas is efficient rather than 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?

No output schema and no annotations, so the description is the only structured information available. It adequately covers scope and the one parameter, but omits how the report is returned and whether the scan triggers anything beyond cache clearing, leaving an agent slightly under-informed for a device-wide operation.

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 sole parameter has only a title and default), so the description must supply the meaning — and it does: clean=true additionally clears app caches, with the reassurance of no data loss. The implicit clean=false default behavior (diagnose only) is conveyed by the wording, though not spelled out.

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?

"Bilan du téléphone" plus an explicit enumeration of the audited areas (système, correctif de sécurité, batterie, stockage, mémoire, applications hors magasins, débogage sans fil, accessibilité) tells an agent concretely what the tool inspects. It does not, however, distinguish itself from overlapping siblings such as info, phone, or settings, so differentiation is left to inference.

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 — this is the broad diagnostic sweep you run to get an overall device report — but the description never states when to prefer it over info, phone, or settings, nor any prerequisite (permissions, device connected). The only guidance offered is the conditional effect of the clean flag.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool opens a conversation with pre-filled text without sending, allows accents, and requires an explicit user command plus a separate act call with verification to send. Core behavioral profile is clear.

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?

Front-loads purpose, then gives parameter formats and sending flow. The structure is logical but sentences are long and somewhat run-on, with conditional instructions mixed in. It earns its length by covering required semantics, though could be tightened.

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?

No annotations or output schema exist, so the description must supply context. It defines the tool's scope, parameters, and the follow-up act path for sending, which is complete enough for an agent to draft and know how to send. Some edge cases (e.g., missing conversation, contact ambiguity) are omitted.

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 thoroughly defines 'to' formats (contact name, phone number, bracket conversation number) and 'app' enum (sms/RCS or whatsapp), and notes accents are permitted for 'text'. It does not elaborate on 'text' beyond that, but all parameters receive meaningful guidance.

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 (Préparer) and resource (une réponse) with scope (sans l'envoyer) and behavior (ouvre la conversation avec le texte déjà écrit). It distinguishes itself from the act sibling by describing the sending path separately. An agent can identify it among siblings like act or messages.

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?

Explicitly instructs to use act only if the user explicitly says « envoie » for this draft, naming the alternative (act) and the condition. This provides clear when-to-use and when-not-to-send guidance, leaving little to inference.

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?

With no annotations, the description carries the burden and does meaningful work: it states pull never overwrites, push is refused if the destination already exists, and nothing is ever erased — a real safety profile. It omits permission/auth requirements, rate limits, and error behavior, so it falls short of fully transparent.

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?

Front-loaded with the resource location, then three compact action clauses, then a one-line safety guarantee. Dense but well organized; a couple of parenthetical defaults could be tightened, but no sentence is wasted.

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, zero-annotation tool with no output schema, the description covers all actions, per-action defaults, and destructive-behavior guarantees. Remaining gaps are the return shape of list and any permission prerequisites, but the operational 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 largely does: it explains that path is the source file for pull/push and dest changes meaning by action (PC folder for pull, phone folder for push), including defaults for each. It does not explicitly state that path is ignored for list, 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 (shared phone storage at /sdcard) and enumerates the three specific operations (list, pull, push) with concrete path examples. An agent can immediately tell this tool manages files on the device, and no sibling (look, info, settings, phone, messages, etc.) overlaps with file transfer.

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 tied to a use case: list reads folder contents, pull copies phone→PC, push copies PC→phone, each with a stated default directory. It stops short of explicit exclusions or naming an alternative tool, but the action-level routing is clear enough for selection.

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?

No annotations exist, so the description carries the full burden, and it does make one useful behavioral claim ('Lecture seule' = read-only) plus return semantics per branch (accuracy, age, Maps link; received/made/missed calls; calendar over N days). It does not address permissions/consent requirements, rate limits, or what `limit` controls. It adds real but partial behavioral context.

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?

Very compact and front-loaded with the read-only constraint, then a tight per-branch enumeration with no filler. It borders on terse rather than wasteful, which is appropriate for a dispatcher tool. The only friction is that the prose is in French while the tool and sibling names are English.

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-annotation, no-output-schema tool, the description partially substitutes for a return schema by describing each branch's payload. But `limit` behavior, pagination/truncation, and any permission or auth preconditions are absent, leaving the agent unable to predict result volume or access requirements.

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 usefully documents the conditional semantics of `query` (only meaningful for contacts) and `days` (only for calendar), which the schema does not express. However `limit` is never mentioned, and the `kind` enum values are already in the schema, so the coverage of four undocumented parameters is incomplete.

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 never states the tool's overall purpose in one verb+resource clause; instead it enumerates the four `kind` branches (location, calls, contacts, calendar) and what each returns. Those branch explanations are concrete, but the tool's identity as a whole is only implied by the vague name 'info' plus 'Lecture seule'. No differentiation from siblings like `look`, `phone`, or `messages` is offered.

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 when-to-use or when-not-to-use guidance, and no alternatives are named despite many overlapping siblings (`look`, `phone`, `messages`, `notifications`). The branch descriptions imply what each `kind` yields, which hints at selection, but nothing tells an agent which tool to reach for versus `phone` or `messages`.

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?

No annotations are provided, so the description carries the full burden. It does disclose a post-condition ('puis la voir' — the app is brought up and visible), which is useful, but it says nothing about failure behavior when the package/fragment is not found, permissions needed, or what state the device is left in.

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 front-loaded sentence: the action and its parameter formats come first, with the resulting effect trailing. No filler, though the parenthetical examples make it slightly denser than strictly necessary.

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 one-parameter tool with no output schema and no annotations, the description covers what to pass and what happens afterward, which is most of what an agent needs. Missing only error/edge-case behavior, a minor gap at this complexity level.

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' property has only a title and no description — so the description must compensate, and it does: it explains that either a full package name (com.whatsapp) or a loose fragment ('whatsapp', 'maps') is accepted, with concrete examples. It stops short of clarifying matching rules when a fragment is ambiguous.

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 ('Ouvrir') and resource ('une application'), plus the accepted identifier formats, so the action is unmistakable. It does not, however, differentiate itself from siblings like 'look' or 'act', which could plausibly also surface an app's screen.

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 explicit when-to-use, when-not-to-use, or alternative routing guidance. An agent must infer from the tool name alone that this is the entry point before any other interaction, and there is no mention of prerequisites (e.g., app must be installed).

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?

No annotations are provided, so the description carries the full burden. It does disclose the output shape (numbered elements with role/text/states/coordinates and an image), which is genuinely useful behavioral context, but says nothing about permissions, rate limits, or side effects of repeated calls.

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 but front-loaded: the core purpose comes first, then parameter semantics line by line. Every clause carries information and there is no filler, though the compressed telegraphic style slightly hurts readability.

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-optional-parameter observation tool with no output schema and no annotations, the description covers the return format and all parameters adequately. The main gap is the absence of any when-to-use routing relative to its many siblings.

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 largely does: it enumerates each 'show' enum value with its default, explains 'query' as a text filter over elements, and defines 'region' as a zoom expressed in pixels of the last full image. Only minor ambiguity remains (e.g., region not marked as optional).

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+resource ('Voir l'écran du téléphone') and specifies what is returned: numbered elements with role/text/state/center coordinates plus an image. This distinguishes it from action-oriented siblings like 'act' or 'launch', though it never names an alternative 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?

Usage is implied (observe the screen), and the parameter explanations hint at intent (query to filter, region to zoom), but there is no explicit guidance on when to use 'look' versus 'act' or 'phone', nor any stated prerequisites or when-not-to-use condition.

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?

With no annotations, the description carries the full burden and does well: it discloses the return content (contact, date, unread counts; messages; attached photos), the 500-message cap, and that videos/files are only flagged rather than returned. It omits any statement about read-only nature, permission requirements, or error behavior, which keeps it from 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?

Front-loaded with the resource (SMS et RCS du téléphone) and then branches cleanly into the two modes. Dense but every clause carries information; only the backtick notation is slightly noisy.

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 tool with no output schema, no annotations, and 0% schema coverage, the description covers both invocation modes, all parameters, output fields, and result caps. Remaining gaps (permissions, side-effect profile, error cases) are minor for an obviously read-oriented 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, and it largely does: limit (last N messages, max 500), images (count of most recent photos, 0 for none), contact (directory name), and conversation (numeric id) are all given meaning. Defaults and types are left to the schema, so not quite 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?

States a specific verb and resource: retrieving SMS/RCS messages from the phone, with two distinct operating modes spelled out. It does not explicitly differentiate itself from siblings like phone, notifications, or look, 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?

Gives clear conditional guidance: no argument yields recent conversations, while conversation=N or contact="Alice" yields the last messages. This tells the agent exactly how to choose between invocation modes, though it offers no comparison against sibling tools that might also surface phone data.

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?

With no annotations, the description carries the full burden and delivers real behavioral context: newest-first ordering, masking of security codes, the all=true scope expansion, and the Android quirk that removed notifications retain only the app name. It does not state auth or rate-limit behavior, but it discloses more than the structured fields do.

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?

Front-loaded with what the tool returns, followed by ordering, masking and the parameter hint in three tight sentences. The final sentence on Android's retention behavior is slightly tangential but earns its place as a non-obvious constraint.

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 two-parameter read tool with no output schema and no annotations, the description covers the returned content, ordering, redaction, scope expansion and a platform caveat. The unexplained limit parameter is the one notable gap, but the rest is sufficient for correct invocation.

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. It explains all=true clearly (include permanent notifications), but says nothing about limit — its meaning, bounds or pagination behavior — leaving half the parameters undocumented in both schema and description.

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 the concrete resource and what it returns (notifications on the phone, with app, time, title and text fields) plus ordering (most recent first). It is specific enough to invoke, but it never distinguishes itself from siblings like messages or look, which an agent may confuse with notification retrieval.

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 only implied through the scope hint that all=true also returns permanent/ongoing-service notifications. There is no explicit statement of when to prefer this tool over messages or look, 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?

With no annotations, the description carries the full burden, and it does disclose the returned facets (link type, model, screen, foreground app), which implies a non-mutating read. It says nothing about permissions, whether a paired device is required, or what happens when no phone is connected.

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 most important fact (connection state) front-loaded. It is efficient, though it reads as a noun-phrase fragment rather than a complete statement of purpose.

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 and no parameters, the description sensibly enumerates the data it returns, which is the main thing an agent needs. It falls short only on the missing preconditions for the query (device pairing, availability).

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; the description correctly adds no parameter discussion, and there is nothing for it to clarify.

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 the resource (phone link) and enumerates exactly what it reports: connection state over USB or Wi-Fi, model, screen, and foreground app. That is clear enough to distinguish it from generic siblings like info or checkup, but it never states an explicit verb and makes no direct sibling comparison.

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 when-to-use guidance, no prerequisites (e.g. that a phone must be paired), and no named alternative among the ten siblings. The agent must infer from the word 'État' that this is a status query rather than an action.

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?

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.