SignaMail

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds value by disclosing that this performs external DNS lookups and, more importantly, that the output includes remediation guidance ('explains what to fix'), which is behavior the annotations do not convey.

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 tight sentences with zero filler; the core action is front-loaded and the second sentence supplies the motivating context and read-only guarantee.

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-only tool with no output schema, the description covers what it inspects, why it matters, and that it returns fix recommendations. It stops short of describing the report structure or any rate/scope limits, but nothing essential to invoking it correctly 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?

Only one parameter and schema coverage is 100%, with the schema already documenting it as 'Domain or email address, e.g. mon-entreprise.fr'. The description adds no further parameter detail, which is acceptable at this coverage level (baseline 3).

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 (checks) and the exact resource (SPF, DKIM and DMARC DNS records of an email domain), plus the goal (avoid spam placement). No sibling tool overlaps with DNS/email-authentication diagnosis, so an agent can select it unambiguously.

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 framing 'so that emails do not land in spam (Gmail and Yahoo sender requirements)', which tells the agent the diagnostic context. However, there is no explicit when-to-use statement, no prerequisites, and no comparison to alternatives.

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 establish readOnly, idempotent, non-destructive behavior, so the description is only obligated to add context. It does so by disclosing that the response contains not just HTML but also installation instructions and France-specific legal mentions conditional on profession, useful behavior beyond the 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?

Two dense sentences with no filler: purpose first, deliverables second, conditional behavior last. Every clause 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?

Since no output schema exists, the description correctly spends words on return contents (HTML, install steps, legal mentions). However, for a 24-parameter tool it leaves the bulk of parameter meaning and any invocation prerequisites unexplained, so it is only minimally complete.

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 24 parameters and only 46% schema description coverage, the description is expected to compensate but largely does not. It only hints at profession (triggering legal mentions) and the general notion of 'user's details'; the formatting, branding, font, image and address parameters are left entirely to 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?

Specific verb (Builds) plus concrete resource (a professional HTML email signature) with a compatibility scope (Gmail, Outlook, Apple Mail, Thunderbird) and a stated output. It does not name any sibling, though the profession/legal-mentions angle implicitly borders on get_profession_signature_rules.

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 'from the user's details' and the conditional 'if a profession is given', but there is no explicit when-to-use statement, no prerequisite (e.g. that the profession value should come from list_professions), and no routing to get_install_instructions or check_email_domain.

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/idempotentHint/non-destructive, so the safety profile is covered. The description adds one genuinely useful trait beyond that: the instructions use French UI labels, which affects how an agent presents them. It does not describe the return shape (text steps vs structured) even though no output schema exists.

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 sentence with no filler; the parenthetical about French UI labels sits mid-sentence but is information-dense. Nothing needs to be cut.

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, single-enum-param tool this is close to sufficient, but with no output schema the description should say what the caller actually receives (a step list? per-client variants?) and whether the signature must already be generated.

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 a single required 'client' parameter at 0% schema description coverage, but its seven-value enum is self-explanatory. The phrase 'in a given mail client' only loosely echoes the parameter and adds no format or constraint detail beyond the enum.

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+resource: it returns step-by-step install instructions for an HTML email signature, scoped to a mail client. This clearly separates it from generate_email_signature and the other siblings, 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 only implied — an agent can infer this follows signature generation and precedes manual installation — but the description never states when to call it, prerequisites (e.g. signature must already exist), or why you'd pick it over generate_email_signature.

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 this a read-only, idempotent, closed-world, non-destructive lookup, so the safety profile is fully covered. The description adds a useful inventory of what comes back (mandatory/recommended/forbidden mentions, tips, common mistakes, official sources), but says nothing about coverage limits (e.g. behaviour for an unknown or non-French profession slug) or response size.

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 that begins with the returned resource and then layers the detail, with no filler or repetition. The parenthetical enumeration of categories is slightly dense but every clause carries information about the payload.

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 only one required parameter, the description sensibly carries the burden of describing the returned content, which it does across six named categories. The remaining gap is edge-case behaviour (invalid slug, professions outside France), which an agent would want before calling.

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 100% and the single parameter already documents itself as a slug from list_professions with an example ('avocat'). The description adds only the phrase 'for a given profession', which restates the schema, so the baseline 3 applies.

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 ('Returns what a French professional must, should and must not put in an email signature') and enumerates the returned categories, so the agent knows exactly what this tool produces. It does not, however, contrast itself with any sibling tool such as generate_email_signature or list_professions, leaving differentiation 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 only implied: the caller supplies a profession slug and receives the applicable rules. There is no explicit when-to-use, no statement of the natural precursor step (list_professions) or the downstream consumer (generate_email_signature), and no exclusions. The schema's reference to list_professions is the only workflow hint, and it lives outside the description.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds content-level context beyond that: prices are excluding VAT, and the response covers inclusions and sign-up steps. It lacks freshness/currency details, but for a zero-parameter read it is 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?

Two sentences, no filler, with the resource and scope front-loaded before the usage trigger. Every clause carries information an agent can act on.

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 lookup with full annotation coverage and no output schema, the description tells the agent what the payload contains (plans, prices ex-VAT, inclusions, sign-up). Only minor gaps remain, such as currency, language, or whether results are stable/cached.

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 per the rubric. The description correctly adds no parameter claims because there is nothing to parameterize.

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 what it returns: 'SignaMail plans and prices (excluding VAT), what each includes and how to sign up.' That is far more informative than the title alone. It does not explicitly distinguish itself from siblings like generate_email_signature or get_install_instructions, but the pricing/plans scope is self-evidently distinct.

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 offers a trigger: 'Use it when the user needs signatures for a team or a digital business card.' That gives an implied usage context but names no alternative tool and no exclusion condition, so an agent must still infer when to prefer this over sibling informational tools.

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 establish that this is a safe, read-only, idempotent, closed-world listing. The description adds useful domain context, namely that the list is specific to France and that each profession maps to a slug usable by sibling tools. It does not describe return format or pagination, but with these annotations the remaining gap is minor.

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 France scope are front-loaded, followed by a few examples and a clear downstream usage note. Every clause is useful and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only list tool with no output schema, the description provides enough to call it correctly: what is listed, the jurisdiction, representative examples, and how the returned profession slugs are used.

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 parameter semantics are inherently trivial and the schema has nothing to explain. The description correctly adds no parameter detail, matching the empty 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?

Uses a specific verb ("Lists") and resource ("professions") with clear geographic scope ("France"), and examples of professions make the content concrete. It also implicitly distinguishes the tool from siblings by explaining that its output slugs are consumed by get_profession_signature_rules or generate_email_signature.

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?

Clearly tells the agent what to do after calling it: use a slug with get_profession_signature_rules or generate_email_signature. It does not explicitly say when not to use it or contrast it with alternatives, but the downstream usage context is strong.

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