Signatoro

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

Annotations already declare write/non-destructive/non-idempotent/open-world, so the bar is lower. The description still adds real context: an invitation email is sent, the invitee receives their signature, the action consumes the plan's people limit, and it requires owner permissions. It doesn't clarify whether the invitation expires or what happens on duplicate email, but the added side-effect and auth detail is substantial.

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 the action and its effect, then prerequisites and alternatives. No filler; every clause carries either behavior, constraint, or routing 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?

No output schema exists, so the description must carry the load, and it does: side effects, permission requirement, plan-limit impact, and sibling routing are all present. An agent has everything needed to call this correctly or route elsewhere.

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 3 is the baseline. The description goes slightly beyond the terse schema labels by explaining that name, title and phone feed 'their signature', giving the fields a purpose rather than restating them, and it clarifies email is the invitation channel.

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 (invite/add a person to the company) plus the scope of data supplied. It explicitly names the siblings it is NOT, letting an agent separate it from update_member_field and resend_invite without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-not/alternative routing: 'For someone already in the company, use update_member_field; to send an invitation again, use resend_invite.' It also states the prerequisite 'Company owners only', so both selection and eligibility are covered.

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/idempotent/non-destructive, and the description reinforces rather than contradicts them ('Nothing is saved and no account is needed'), consistent with the 'Preview' title. Beyond that it discloses the return payload (HTML plus plain text plus claimUrl) and the persistence semantics of claimUrl as the only way to keep the result, which the annotations alone 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?

It is front-loaded with the purpose, then routing, then the mandated claimUrl sentence, so the most important content lands first. It is somewhat dense for three sentences and the quoted instruction sentence is long, but each part carries distinct 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 9-parameter, single-required-parameter tool with no output schema, the description still covers the return shape (HTML, plain text, claimUrl), the persistence guarantee, account requirements, and the sibling alternatives. Nothing an agent needs to call and follow up 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?

Schema description coverage is 100%, so every parameter is already documented with type, constraints, and examples (hex pattern, layout enum, list_templates hint). The description only restates the field list at a high level and adds no syntax or format detail beyond the schema, so the baseline of 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 opens with a specific verb and resource ('Make a free email signature from a name and optional title, company, phone...') and enumerates the inputs it accepts. It explicitly differentiates itself from siblings by name: update_my_signature for saving, get_signature for a saved one, and list_templates for layout choice. An agent can place this tool precisely without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use and when-not-to-use routing ('To save a signature to the signed-in person's Signatoro account ... use update_my_signature instead; for the signature they already saved, use get_signature'). It also states the operative precondition ('no account is needed') and even prescribes the follow-up behavior (always surface claimUrl with the given sentence), which is unusually actionable.

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 behavior, so the safety profile is covered. The description adds real behavioral context beyond that: a link to the full guide is returned, and an unrecognized client yields a catalog of available guides instead of an error.

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 the purpose in the first sentence, then adds invocation and fallback detail. The client-value enumeration is long but earns its place as the de facto enum for a schema that defines none.

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 by naming the steps and the guide link. Combined with the annotations and the fully documented single parameter, an agent has what it needs to call this 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 100%, so the baseline is 3, but the description goes further by enumerating concrete valid client values (gmail, outlook-new, outlook-classic, apple-mail, ios-mail, zoho-mail, thunderbird) that the schema only sketches with two examples. That materially improves correct value selection.

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 (get install steps for adding an email signature) and scopes the source (Signatoro's install guides) plus the return value (steps with a link to the full guide). No sibling tool overlaps this purpose, so it is trivially distinguishable.

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?

Explains how to invoke it ('pass the app as client') and what happens for an invalid input ('an unknown client answers with the list of guides there are'), which covers the practical when/how. It does not name explicit alternatives, but no sibling tool provides install steps, so the routing job is done.

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 only cover the safety profile (readOnly, non-destructive); the description adds the substantive behavior an agent needs: the return anatomy (html/text plus sender and companyControlled/howToChange), the field-provenance rule, and the fallback rule for missing values. It also effectively documents output structure, which matters since there is no output 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 the return value, then the operational guidance, and every sentence carries a rule (provenance, no-guessing, company-controlled parts). The middle stretch is dense and slightly run-on, which costs a point but not comprehension.

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 two optional parameters, the description supplies everything an agent needs: the returned fields, how to use them, the mode and signature selectors, the missing-field policy, and where to go to modify the signature. Nothing material is left out.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond it: it spells out what mode "short" actually yields (name, role line and one link) and constrains signature to "me" or an AI assistant/company AI agent sourced from list_signatures. It does not, however, explain how an agent id vs name is resolved.

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 the signed-in person's saved email signature) plus the payload shape (html and text, sender fields), immediately distinguishing it from siblings like list_signatures and update_my_signature. An agent can tell what it gets and why 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?

Explicit when-to-use (append after the body in place of a sign-off), how to source sender details, what to do when a field is missing (leave it out and say so, never guess), when to ask (if it's unclear which signature), and the alternative for changing it (update_my_signature). No inference required.

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, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond them: the auth constraint ('Company owners only'), the composition of results (members plus pending invites), and the status values returned.

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 that front-loads the resource and then the scope and access constraint. Efficient with no filler, though packing the return fields into the same sentence makes it slightly heavy.

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 exists, so the description carries the return-value burden, and it does so by enumerating the returned fields and statuses. With one optional parameter fully documented in the schema and the access constraint stated, nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents the slug/id format, so baseline is 3. The description adds semantics the schema lacks: that omitting the parameter widens the result to every company the caller owns, which is meaningful optional-parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the people in the signed-in owner's company') plus scope (joined members and pending invitations). It is clearly distinguishable from sibling mutations like add_member, remove_member, and resend_invite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage condition: 'Company owners only' as a prerequisite, and 'Omit company to list every company you own' as the default behavior. It does not explicitly name an alternative tool for a different view, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the exact fields returned (id, name, signing mode, AI disclosure preset, preview), the default ('me'), and the non-obvious scoping caveat that 'A connection bound to one agent lists only that agent.'

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 sentences, front-loaded with the purpose and the returned fields before the handoff instruction; nothing is filler. The parenthetical qualification about company agents ('agents of a company they own or that acts for them') is dense but load-bearing, keeping it just short of maximal conciseness.

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 correctly compensates by summarizing the return payload and the default and scoping rules. Combined with annotations that cover the read-only/idempotent profile, an agent has what it needs to call this correctly and chain into get_signature; only explicit exclusion guidance against sibling list tools is absent.

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 and the baseline of 4 applies. The description uses the space instead to explain what the returned signature identifiers feed into (get_signature), which is the relevant 'parameter' concept 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?

States a specific verb and resource ('Lists the signatures'), defines the scope precisely ('the signed-in person can send email with'), and enumerates the three signature classes (own, AI assistants', company AI agents'). It also names the sibling it hands off to (get_signature), so the agent can distinguish it from get_signature and create_signature without reading any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the follow-up step: 'Pass a choice as signature to get_signature,' and adds the escalation rule 'If it is unclear which one the person wants for an email, ask them before sending.' That is clear when-to-use guidance and names the alternative, though it never states when not to use this tool instead of, say, list_members or list_templates.

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, and non-destructive behavior, so the safety profile is covered. The description adds real value by disclosing the shape of each result (a layout plus a short description of what it shows and when it fits best), which partially compensates for the absence of an output 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?

Two short sentences, front-loaded with what the tool returns and followed immediately by the actionable next step. Nothing is redundant or padded.

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

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

For a parameterless, read-only lister with no output schema, the description conveys the substance of the return payload and how to use it. It does not state the container format (e.g., array vs. object) or the id format, a minor gap given the low complexity.

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 clarify; baseline 4 applies. The mention of a 'layout id' correctly refers to an output value used by a sibling tool, not an input 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?

States a specific verb and resource ('List the signature layouts') and characterizes the content of each returned item. No sibling tool lists layouts, so it is unambiguously distinct from list_members or get_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?

Names the downstream action explicitly: the returned layout id is meant to be passed to create_signature, which tells the agent when this tool is the right starting point. It stops short of stating when not to call it, but the workflow context is clear.

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 destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: irreversibility, the exact two-step confirmation protocol, token expiry, the authorization requirement (owners only), and the guard rails against self-removal and primary-owner removal. It also discloses what the confirmation-less call actually returns, which no annotation conveys. No contradiction with 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?

Front-loads the danger ('DESTRUCTIVE and cannot be undone') ahead of the procedure, then flows from effect, to protocol, to permissions. Dense but every sentence carries a distinct, load-bearing fact with 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?

With no output schema, the description compensates by describing what the first call returns (who would be removed plus a confirmation) and how that value is reused. Authorization, irreversibility, expiry and edge cases are all covered, leaving nothing an agent needs 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%, so the baseline is 3, but the description adds real semantics for the confirmation parameter that the schema only gestures at: it is omitted on the first call and is the exact string returned by that call, valid for 10 minutes. It also frames email as identifying the target person's membership/invitation state.

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 destructive verb and resource ('removes a person from the company') and immediately differentiates outcomes the sibling list does not cover: a joined member loses access to the company and its signature, while a pending invitation is withdrawn. An agent can distinguish it from add_member, list_members and update_member_field without reading either 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 defines the when: call first without confirmation to obtain a preview, show it to the person, then call again only after they approve. It also states prerequisites and exclusions up front — company owners only, nobody can remove themselves or the primary owner — and gives the 10-minute expiry as a usage constraint.

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 is a non-read-only, non-idempotent, non-destructive call; the description adds genuinely useful context beyond that: the owner-only authorization requirement and the 7-day renewal behavior on expiry. It does not mention rate limiting or delivery-failure behavior for an email-sending operation.

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 sentence with zero waste: action, target population, side effect, and permission gate are all front-loaded before any secondary detail.

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 mutation with no output schema, the description covers the action, eligibility, expiry renewal, and authorization. It stops short of describing the result (e.g., what a failed resend returns), but nothing essential to calling 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?

With 100% schema description coverage, the schema already documents both 'email' and 'company' including the slug-or-id format. The description adds no parameter-level syntax or format detail, 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?

Specific verb (send again) + resource (invitation email) + precise scope: only people already invited to the company who have not yet joined. Distinguishable from siblings like add_member and remove_member 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?

States the eligibility condition (person invited but not joined) and the permission prerequisite ('Company owners only'), which tells the agent when the call is valid. It does not name alternatives such as add_member when no invite exists, so it falls short of a 5.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds real behavioral context beyond that: the change triggers an email to joined members, re-sends the invitation for pending members, and is restricted to company owners. It does not say whether the previous value is recoverable beyond the destructive hint.

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, each earning its place: the mutation scope is front-loaded, then the two side-effect paths, then the permission constraint. 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 4-parameter mutation with full schema coverage, no output schema and rich annotations, the description covers scope, auth and downstream effects adequately. Only minor gaps remain, such as confirming that unmentioned fields are left untouched.

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 enum already restricts field to name/title/phone while the schema notes 'Empty clears it' for value. The description's field list and clearing behavior merely restate structured data, 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 ('Change one field ... of a person's signature in the company') and enumerates the scope (name, title or phone), which cleanly separates it from the sibling update_my_signature and the broader add_member/create_signature tools.

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?

Names the prerequisite clearly ('Company owners only') and describes the resulting side effects, which tells the agent this is the right tool when a signature detail must be changed. It stops short of naming alternatives it supersedes (e.g., remove_member + add_member, or resend_invite), so no explicit when-not guidance.

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

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

Annotations declare a destructive, idempotent, open-world write, and the description adds real substance on top: partial-update merge semantics, empty-string clearing, company-controlled fields returned in 'ignored' with who changes them, Zoho Mail sync, quota consumption like get_signature, and hold-back behavior when the monthly allowance is exhausted. It also notes the no-op case writes and counts nothing.

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 core action and then layered with constraints; nearly every clause carries information (quota, ignored fields, mailbox sync). It is dense and somewhat run-on, with several clauses joined in single sentences, but there is little filler to 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 21-parameter mutation tool with no output schema, the description covers what an agent needs: merge/clear semantics, protected company fields, side effects on a connected mailbox, quota cost, and the return shape (HTML and text with sender, fields, and request counts). Nothing material is left 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?

Schema coverage is 100%, so the baseline is 3, but the description contributes cross-cutting semantics the schema cannot express: omitted fields retain saved values and "" removes a field. Those rules govern all 21 parameters and are not derivable from the per-property descriptions.

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 plus the exact scope: the signed-in person's own signature, with the field list enumerated. It also distinguishes itself from create_signature by noting 'with nothing saved yet, this creates the signature,' so an agent knows which of the two siblings applies.

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 operational context: send only the fields to change, use "" to clear, and company brand items are off-limits because the company owner controls them on signatoro.com. It does not name a sibling alternative explicitly (e.g. 'use create_signature when...'), so it stops short of full routing guidance.

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