ProSignature email signatures

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it discloses the exact return payload (html, plain text, edit_url, install steps), the free-plan ceiling (four layouts, six accent colours, no logo/photo), and the injected 'Created with ProSignature' credit line. The deterministic 'same bytes' claim and the explicit no-storage guarantee are genuinely useful behavioral facts.

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 and output are front-loaded in the first two sentences, and each following clause adds a distinct constraint (free-plan limits, credit line, statelessness). It is dense and reads as a long block rather than cleanly separated lines, which costs a point but no sentence is 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?

With no output schema, the description carries the return-value burden and does so completely: payload keys, plan-level limitations, branding injection, and the absence of side effects. An agent has everything needed to call it and interpret the result.

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%, so the schema already documents all eight parameters, including the colour default and enum. The description only echoes a subset of that ('four layouts, six accent colours') without adding format or combination guidance, so 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?

The description states a specific verb and resource ('Builds the email-safe HTML signature'), names the output artifact form (table + inline styles) and scopes it to 'one person'. It implicitly distinguishes itself from siblings like get_install_steps and list_layouts by explaining that install steps are bundled in the return rather than fetched separately.

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 establishes context ('free plan', 'no account', 'Nothing is installed or stored') so an agent knows this is a safe generation call, but it never states when to prefer this tool over siblings such as quote_price or get_install_steps. Usage is implied rather than instructed.

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 read-only/idempotent/non-destructive, and the description adds genuinely new behavior: 'data in the URL fragment, nothing stored', 'Nothing is fetched from logo_url server-side', prices sourced from pricing.json, and that each claim_url opens the app preloaded so the human completes signup. These are exactly the side-effect and privacy facts an agent needs before invoking.

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 opening clause is perfectly front-loaded with the trigger, and there's almost no filler — every clause names a real input or output. However, the single long semicolon-chained paragraph listing outputs is dense and hard to scan; a short structured breakdown of the return payload would read faster.

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 17 parameters, a nested object, and no output schema, the description carries the full burden and meets it: it explains the return payload item by item and discloses the no-storage/no-server-fetch model. An agent can call this correctly and correctly set user expectations without inspecting anything else.

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 100%, so the baseline is 3, but the description adds value by enumerating which user facts feed the design (person, company, brand colour, logo URL, website, socials, department, sector, team size) and noting defaults come from the playbook for the role/sector. It doesn't explain things like how department is guessed or how the logo URL is validated, so it isn't 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?

States a specific verb and resource ('builds 3–4 professional designs' from the user's known details, using 13 templates chosen by a playbook) and names the trigger ('Start here when a user asks for an email signature'). It also enumerates the exact artifacts returned (preview_url, claim_url, paste-ready HTML, install options, present_to_user), so an agent knows precisely what this produces versus the sibling create_signature flow.

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?

'Start here when a user asks for an email signature' plus 'From what you already know about them' gives a clear entry trigger and tells the agent not to interrogate the user first. It implies the downstream path ('the human signs up free and upgrades there'), but never explicitly names create_signature or states when to skip this tool in favour of it.

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 safety profile is covered. The description adds meaningful extra context: a freshness marker ('verified 2026-10-18') and an explicit negative scope ('what the product is NOT: no mail-flow enforcement, no Microsoft 365 sync, no analytics'), which helps prevent hallucinated capabilities.

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 dense sentence enumerates the covered topics with no filler, front-loading the core identity ('What ProSignature is') before the details. It is somewhat list-like but every clause 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?

For a no-param, no-output-schema static facts tool, the description adequately scopes what content is returned, including pricing freshness and known limitations. Only a note on the response shape (docs vs. narrative facts) 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies per the rubric.

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 enumerates the resource: static reference facts about ProSignature (plan pricing, install behavior, negative capabilities, doc locations). It is not a tautology, but it lacks a crisp verb and overlaps with siblings quote_price (prices) and get_install_steps (installs), so it does not fully disambiguate from them.

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 or when-not-to-use guidance. Given that pricing and install topics also appear in quote_price and get_install_steps, a routing hint (e.g., 'use for static fact lookups, not for live quotes') would be valuable but is absent.

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 it read-only, idempotent, non-destructive and closed-world. Beyond that, the description adds genuinely useful process behavior: the sendAs PATCH applies only to new mail, Outlook is copy-paste-only with no directory sync, and the Chrome extension auto-updates and covers replies but requires human signup.

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?

It is a single dense sentence with stacked parentheticals and an odd 'honestly:' opener; every clause carries content but the structure is rambling rather than cleanly front-loaded.

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 low-complexity, single-enum, read-only info tool with no output schema, the description conveys enough about what each client's result will cover. Safety is covered by annotations, so no major 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?

Schema coverage is 100%, so the enum is already documented, but the description adds meaning by distinguishing 'Gmail web' from 'Gmail mobile' and characterizing each client's install path, helping the agent pick the right enum value.

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 resource — install steps for getting a signature into a mail client — and ties it to the sibling create_signature as the source of the signature. It is not a tautology, though the front-loaded intent is somewhat buried under per-client detail rather than stated as a crisp verb+resource.

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: you call this after create_signature to learn how to install the signature into a given client. There is no explicit when-to-use/when-not statement or named alternative, though the client enumeration and the Chrome-extension signup note gesture at context.

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), and the description adds real value on top: it scopes the knowledge base (13 templates, 8 departments, 18 sectors) and explicitly notes it distinguishes what ProSignature handles from what no tool can automate. It does not describe output shape or size, but for a static reference tool this is solid added 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?

One dense sentence that front-loads the content inventory and ends with the call instruction. Efficient, though the em-dash run-on stacks five separate claims and the actionable part is buried at the tail.

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?

There is no output schema and no parameter documentation, so the description must do all the work; it does describe the returned content well but omits the accepted values for sector and department, leaving the agent to guess filter strings for a tool with two untyped string params.

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 schema coverage at 0% and no enums, the description must carry parameter meaning; it only says the two filters are optional and combine ('and/or') to return a single profile. It never indicates which department or sector values are valid, which is the highest-risk gap for a 0%-covered filter pair.

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 concretely enumerates what the tool returns: signature rules, 13 template descriptions, per-department/per-sector recommendations, and mail-client pitfalls. It reads as a content inventory rather than a verb+resource statement, and it never names a sibling such as design_signatures or list_layouts, 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?

The only usage instruction is 'Pass department and/or sector for one profile,' which explains how to narrow the lookup but not when to consult this reference versus design_signatures or create_signature. A reader can infer it is a pre-design knowledge lookup, but no alternative or exclusion is stated.

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, destructiveHint=false and a closed world, so the safety profile is covered. The description adds real value beyond them by disclosing the result cardinality (four layouts, six colours) and the fields of each layout (id, name, what it looks like).

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 wastes no words and states the return content up front, which is exactly the right shape for a parameterless catalogue lookup.

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?

There is no output schema, so the description carries the burden of describing return values, and it does so at a useful level: item counts plus the field set for layouts and the nature of the colours. It does not spell out the colour entries' shape, a minor gap for a trivial read 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly spends no text on inputs and instead describes the payload.

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 both resources the tool surfaces (the four signature layouts with id/name/appearance, and the six accent colours) and does so precisely enough that an agent can tell it apart from siblings like create_signature or quote_price. It stops short of stating a verb, but the resource 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 only implied: enumerating valid layouts and colours signals that this is the discovery step to run before create_signature, but the description never says when to call it or names the tool it complements. No exclusions or prerequisites 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description goes well beyond them: external rule source with a verification date, no platform fee, 5-person minimum, admin counted as a person, free plan at $0 credit line, and the explicit no-side-effect boundary ('not a checkout'). It stops short of describing the returned quote's shape or currency assumption.

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 paragraph that front-loads the core pricing semantics before the source URL and the quote-not-checkout caveat. Every sentence carries information, though the free-plan sentence is marginal and the paragraph is longer than strictly needed for a 3-parameter tool.

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?

There is no output schema, so the description bears some burden for the return value; it implies a listed price and shows the $0 free-plan case, but never states currency or whether the figure is per-person or a total. For a read-only quote with enumerated inputs and 100% schema coverage, the rest of what an agent needs is 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 100%, so the baseline is 3, but the description genuinely adds meaning: 'The admin counts as one of the people' disambiguates the people parameter, and the Teams minimum plus 'no platform fee' qualify the plan enum. It does not add anything for billing beyond what the enum description already says.

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 ('List price for Pro ... or Teams ...'), names both plans, the billing cadences, and the authoritative rules source. An agent can tell this is a pricing-quote tool and not a checkout, a plan-management tool, or a signature tool.

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 bounds when this applies and when it does not: 'This is a quote, not a checkout: the human pays in the app after signing up.' It also gives the qualifying conditions for each plan (per person, 5-person minimum, admin included) and mentions the free plan. It does not, however, point to any sibling tool for adjacent needs (create_signature, get_facts), so routing vs. alternatives is left implicit.

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