Le Confidant

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond that: no account or upload is needed, all numbers are fictional and fixed, there is no relationship diagnosis, and output is text plus structured recap without image export.

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 and dense with useful constraints: fictional-only scope, no private data, fixed numbers, and return format. It is slightly title-like at the start, but every remaining clause carries decision-relevant 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?

For a simple, read-only, one-parameter demo tool with an output schema, the description covers safety, scope, and return shape well. The only notable omission is locale behavior, which matters because the parameter exists and its effect on the recap language is unstated.

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 schema has only one optional locale parameter, but the description never mentions locale or explains that it controls the language of the fictional recap. With 0% schema description coverage, the description should compensate here but does not.

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 (Show a synthetic WhatsApp recap) and clearly scopes it as fictional demo content. It distinguishes itself from the real-conversation sibling tools by ruling out account access, uploads, and private conversation data.

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 an explicit use case (demo or example only) and an explicit prohibition (never to answer questions about the user's real conversation). This is enough routing guidance for an agent to know when not to call the real-data siblings instead.

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 substantial context beyond the annotations: it states the revocation is permanent, the credential cannot be restored, re-consent creates a new grant while the original session remains eligible, and existing results are not deleted. These consequences are critical for a destructive operation and are not covered by the annotations alone.

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 key usage constraint is front-loaded, but the description is somewhat dense and includes a tangential final sentence ('does not retrieve statistics or answer period comparisons') that seems out of place and adds little value. Some redundancy exists with the annotations' destructive hint.

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 destructive tool with no output schema, the description covers when to use it, what it changes, what it does not delete, and re-consent behavior. The only notable gap is the unexplained locale parameter, but otherwise an agent has enough context to invoke it correctly.

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?

There is one parameter (locale) with 0% schema description coverage, and the description never mentions it or explains what locale controls. The schema provides the enum values and default, but the description does not compensate for the missing semantic 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?

The description states a specific verb (disconnect/revoke) and resource (OAuth grant for this connection), and clarifies what the tool does not do (retrieve statistics or answer period comparisons). It is easily distinguishable from the sibling tools, which all perform formatting, link generation, snapshot retrieval, or normalization.

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 explicitly says to use this only when the user asks to disconnect or revoke the connection, and it notes that other connections can be revoked on the website. This gives clear when-to-use guidance and an alternative location for related actions.

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, and the description adds substantive context beyond them: inputs are processed server-side but not stored or logged, no account access, no message sending, unsupported blocks remain literal, URLs and code are preserved. It also states the exact transformation semantics with a concrete input/output example, which is the kind of behavior an agent cannot get from 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?

Front-loaded with the purpose, then pre-call rules, example, post-call rule, capabilities, then limits — a sensible order. It is somewhat verbose and the **Meeting tomorrow** example duplicates the schema description almost verbatim, costing a little density.

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?

Even though an output schema exists, the description goes further and tells the agent how to present the result (verbatim in a plain-text fence), plus input invariants and explicit non-capabilities. For a two-parameter transform tool, an agent has everything needed to call it correctly.

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 50% — `text` is documented in the schema, `locale` is not. The description compensates heavily for `text` by restating the unchanged-copy rule and repeating the escaped-punctuation example, but it never mentions `locale` or what language selection affects, leaving that half of the gap unaddressed.

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 first sentence gives a specific verb and resource: convert the user's Markdown source into WhatsApp-ready text. It further delimits scope by stating it does not render HTML, summarize, translate, or send messages. It never names the closest sibling (style_whatsapp_text) as an alternative, so the differentiation is inferred rather than stated.

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 explicit pre-call guidance ('copy the supplied source unchanged… do not Markdown-escape or pre-convert') and post-call guidance ('display structuredContent.formattedText verbatim in a plain-text fenced code block'). What is missing is a when-to-use-this-vs-sibling statement, e.g. versus style_whatsapp_text or generate_whatsapp_link.

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/closed-world, so the bar is lower, and the description still adds real value: no storage or logging of phone numbers or text, no account access, and no message sending. It omits error/failure 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?

Three short sentences, front-loaded with what is produced, followed by constraints and privacy notes. Each sentence earns its place; minor redundancy in listing both 'does not store' and 'does not log'.

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 link builder with an output schema (so return values need no explanation) and full safety annotations, the description covers purpose, precondition, and privacy. The only shortfall is silent handling of locale/defaultCountry.

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 only 25%, so the description needs to compensate. It covers the phone precondition and the optional message, but leaves 'locale' and 'defaultCountry' completely unexplained in both schema and description — a meaningful gap for a 4-parameter tool.

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 artifact ('Create a wa.me URL') plus the optional prefilled message, which is specific enough that an agent can distinguish it from siblings like format_whatsapp_text or normalize_whatsapp_numbers. It stops short of naming any sibling explicitly, so it falls just below 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?

'for copying or sharing' implies the use case, and 'Requires a valid phone number; does not verify WhatsApp registration' sets a precondition. There is no explicit when-not guidance and no routing to alternative tools, leaving usage partly inferred.

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 readOnly, idempotent, non-destructive and closed-world, so the description focuses on what annotations can't express: the data comes from an OAuth-selected session with expiry, and it returns no raw messages, names, excerpts, paid insights, or newly computed analysis. That negative-boundary disclosure is genuinely valuable, though it partially restates the output payload that the output schema already defines.

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 positive scope, then exclusions, then a concrete example, then return contents. Dense and purposeful, but the example block and the repeated 'cannot answer / explain unavailability' phrasing cover overlapping ground and 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?

For a single-parameter read tool with full annotations and an output schema, the description covers authorization source, scope limits, unsupported request handling, and the negative data boundaries. Nothing an agent needs to decide whether and how to call it 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% for the single locale parameter, so the description must compensate; it does so with 'Set locale to the user's supported language,' which clarifies the parameter governs response language and implies constraint to the supported set (the enum lists six locales). It stops short of naming defaults or fallback behavior, but the enum carries that.

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 ('retrieve or explain WHOLE-SESSION numerical statistics') and immediately bounds the scope to stored whole-session totals from an authorized export analysis. The agent can distinguish this from period-comparison style tools 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?

Explicitly names when not to call ('DO NOT call for date-window, month-to-month, trend or period-comparison requests, even to check available data') and prescribes the alternative behavior: explain the capability is unavailable. A concrete worked example ('Compare September and November...') removes all 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?

Goes well beyond the annotations by disclosing data-handling behavior: inputs are processed server-side to return the result, no storage or logging of phone numbers or text, no account access, no messages sent, no WhatsApp registration lookup. That privacy and side-effect profile is exactly the extra context annotations can't express.

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 capability and return values, then constraints, then exclusions — a sensible ordering. A few clauses are redundant ("Inputs are processed by this server to return the result" restates that it's a computation), but nearly 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?

An output schema exists so return values needn't be detailed, yet the description still summarizes status and duplicate reporting usefully. The only real hole is the undocumented `locale` parameter; otherwise an agent has enough to call this correctly and knows the tool is a safe, side-effect-free batch normalizer.

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 only 33%. The description compensates for `numbers` (up to 100) and reinforces `defaultCountry`'s role for national numbers, but `locale` (enum with default "en") is never mentioned in either the schema or the description, leaving one of three parameters opaque.

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 — validate up to 100 phone numbers and return E.164 numbers plus wa.me links — with the output shape (per-row status, duplicate positions) spelled out. The batch/normalization framing is distinguishable from format_whatsapp_text and style_whatsapp_text, though it never explicitly contrasts itself with generate_whatsapp_link even though it also emits wa.me links.

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 concrete precondition ("National numbers require defaultCountry") and an explicit negative rule ("Never guess a country from language"), plus scope exclusions (no registration check, no contacting people). It stops short of naming when an agent should pick a sibling instead, so it's clear context without routing.

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?

Beyond the annotations (readOnly, idempotent, closed-world), it discloses real behavioral traits: lookalike characters rather than real fonts, digits/accented letters staying plain, degraded screen-reader output, no storage or logging of phone numbers/text, and no account access or message sending. It also prescribes how to render the result, which is exactly the context an agent needs.

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 front-loads the core action and the style list, then layers caveats and the display instruction. It is dense but each sentence carries information; the privacy sentence is slightly boilerplate but still relevant to user trust.

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 and the description still tells the agent to render structuredContent.styledText verbatim in a fenced code block, closing the loop on return-value handling. The only meaningful omission is any explanation of the locale parameter.

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 67%; text and style are documented in the schema, but locale has no description in either the schema or the description, so its purpose is left unspecified. The style list is repeated from the enum rather than adding new meaning, so the description adds little beyond the schema.

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 ('Rewrite the user's text in one decorative Unicode style') and enumerates the eight styles, so the agent knows exactly what the tool produces. It does not, however, distinguish itself from the sibling format_whatsapp_text, which sounds closely related.

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?

'Call it once the user has picked a style from this list' gives a clear triggering condition and sequencing rule. It still leaves the agent guessing when to choose this over format_whatsapp_text, so it falls short of explicit alternative routing.

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