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

With no annotations, the description carries the full burden and does well: it discloses the state mutation (back to sent), the 14-day constant, the preserved signatures, the signers-in-order limitation to the current stage, and the cost. Missing are failure conditions (what happens if the document is not expired) and any permission requirements.

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 primary action (new deadline), then the side effects (status reset, resend scope), then the preservation guarantee and cost. 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 single-parameter mutation tool with no annotations and no output schema, the description covers the state transitions, recipient targeting, and data preservation well. It omits the return value and error behavior, 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?

Only one parameter (id) at 0% schema description coverage; the description implies it identifies the expired document but never states that it is the document ID or its type. Minimal but inferable from context.

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 (extend an expired document) plus the concrete mechanics: new deadline 14 days out, status back to sent, fresh link to unsigned signers. This is unmistakably distinct from void_document, remind_document, and send_document.

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 precondition ('expired document') clearly selects this tool over remind_document or send_document, and the 'Free' note signals a cost-motivated choice. It stops short of explicitly naming the alternative to use when the document has not yet expired.

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

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

No annotations are supplied, so the description carries the full burden. It usefully enumerates what the response contains and implies a read-only operation, but says nothing about authentication/account scoping, whether it deducts or costs anything, or any rate limiting; a read-only nature is only implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with no filler, and the most important item (prepaid balance) is listed first. It is a dense list rather than a sentence, which slightly hurts readability but nothing is wasted.

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

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

With no output schema, no annotations, and no parameters, the description's enumeration of return fields is exactly the context an agent needs, and it is reasonably complete for a simple zero-arg read tool. It stops short of stating the units/format or confirming the read-only contract.

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 to document and the baseline is 4. The description correctly avoids inventing parameter detail that does not exist.

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 is a noun-phrase list of returned fields ('Prepaid balance, documents used this month...') rather than a stated verb+resource, so the action ('retrieve your account/billing status') must be inferred from the tool name and title. It does distinguish the tool from document-oriented siblings by making clear this is account-level billing data, but the purpose is never stated outright.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to any sibling tool (e.g., why to check the balance before calling send_document). The agent must guess the trigger condition entirely.

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral constraint — the document must be one 'you sent' — and it pre-describes the returned payload, which is valuable given there is no output schema. It says nothing about permissions, read-only nature, or behavior on an unknown/unauthorized id, so it is only partially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence that front-loads the most useful content (status and signers). It wastes no words, though the sentence fragment lacks a verb, making it read as a return-value list rather than an action statement.

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

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

For a one-parameter read tool with no annotations and no output schema, the description usefully previews the response shape, which covers the biggest gap. It still omits the parameter's meaning and any usage routing, so it is adequate rather than 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?

Schema coverage is 0% and the sole 'id' parameter has no description, so the description should compensate. It implies the id identifies 'one document you sent' but never explicitly ties the parameter to a document identifier or specifies its format/source. Partial compensation only.

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 enumerates exactly what the tool surfaces about a single document (status, signer viewed/signed times, download links, event history), which is specific enough that an agent can tell it apart from list_documents. It never states the action verb (retrieve/get), but the resource and single-document scope are 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?

There is no explicit when-to-use guidance and no mention of alternatives such as list_documents for enumerating documents or get_evidence for audit material. The phrase 'one document you sent' weakly implies the single-document case, but nothing tells the agent when to prefer this over its siblings.

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

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

With no annotations, the description carries the full burden, and it does disclose substantive behavioral content: exactly which artifacts come back (SHA-256 of original and signed PDFs, signer/event records, positions in a public hash-chained log) and that an independent verification recipe is included. It stops short of stating the safety profile (read-only, no side effects) or any auth/rate-limit requirements.

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 enumerates contents in a scannable list; no filler or repetition.

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 usefully doubles as return-value documentation, telling the agent what the evidence package comprises. It leaves minor gaps — the meaning/format of id, error behavior for unknown documents — but is otherwise complete for a simple read getter.

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 (id) at 0% schema description coverage, so the description is the only place meaning can come from. The phrase 'for a document' implies id is the document identifier, which is genuine added context, but the description never documents the parameter explicitly or its accepted form.

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

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

The description names the resource (evidence package for a document) and itemizes its contents — hashes, signers, events, log positions, verification recipe — so an agent knows exactly what it fetches. It lacks an explicit verb ('retrieves') and never names the nearby sibling get_document or verify_signature_code, which would have sharpened differentiation.

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

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

There is no when-to-use guidance, no exclusions, and no reference to the sibling tools an agent might confuse this with (get_document for the document itself, verify_signature_code for a single code). The agent must infer that this is the audit/forensic route rather than the general document route.

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

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

With no annotations at all, the description carries the full burden. It usefully discloses the ownership scope ('your') and the implicit recency ordering, but says nothing about default page size, whether results are capped, or what fields come back. For a read-only list tool this is acceptable but thin.

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 well-formed sentence with the core behavior front-loaded and the parameter detail in a subordinate clause. Nothing is wasted.

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

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

For a simple two-parameter read tool with no output schema, the description covers the status filter adequately but leaves the limit parameter and any result-count or pagination behavior unexplained. An agent can call it, but cannot predict the volume of what it gets back.

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

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

Schema description coverage is 0%, so the description must compensate. It does so well for 'status', spelling out all five accepted values and clarifying the ambiguous 'expired' case. However, the 'limit' parameter (min 1, max 100, default unknown) is entirely undocumented in both the schema and the description.

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

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

The description states a specific verb and resource ('Your most recent documents') with an explicit scope qualifier ('your most recent'), so an agent knows this is an ownership-scoped listing operation. It does not explicitly contrast itself with get_document or the other siblings, so it falls short of a 5.

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

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

The phrase 'optionally filtered by status' implies the intended use case, but the description never says when to reach for this tool over get_document or when a status filter is warranted. Usage is inferable but not guided.

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

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

With no annotations and no output schema, the description carries the full behavioral burden. It usefully discloses domain semantics (a template is a PDF with placed fields and named signer roles, approver_slots holds approving roles), but says nothing about return format, pagination, or scope limits for a list 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?

Two compact sentences, with the resource and return content front-loaded and the routing hint at the end. The parenthetical definition is dense but earns its place by explaining approver_slots; nothing is 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?

Since there is no output schema, the description is the only source of return-value information, and it covers only direct links and the approver_slots concept. Other likely fields (template id, name, signer roles) and any list limits are unaddressed, leaving the picture only partially 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?

The tool takes zero parameters, so there is no parameter semantics to document and no schema gap for the description to compensate for. Baseline 4 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 the resource (saved templates) and what is returned (their direct links), and even defines what a template is via the parenthetical. It reads clearly against list_documents, though the verb itself is only implied by the tool name rather than restated.

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?

"Use send_from_template to send one" explicitly routes the agent to the sibling for the send action, which implies this tool is the discovery step before sending. There is no explicit when-not or prerequisite statement beyond that routing, so it stops 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?

With no annotations, the description carries the full burden and does disclose the key operational traits: it sends an outbound email, it is rate limited to once an hour per document, and it fails on expired documents. It stops short of saying what the response contains (per-recipient success/failure, counts) or what happens if some recipients were already reminded.

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 carrying a distinct fact (action, rate limit, failure path), with the core action front-loaded and 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 one-parameter, no-output-schema, no-annotation tool, the description covers action, scope, throttling, and the failure branch, which is enough to invoke it correctly. The remaining gap is the return value and partial-success behavior, which is minor but not covered anywhere 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 0% for the single parameter, so the description must compensate; it only implies that "id" is the document identifier through phrases like "per document." It does not explicitly state that id refers to the document, nor whether it is the document or template id.

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 ("Re-send the signing link") and scopes it to "everyone who has not signed yet," which distinguishes it from send_document and send_from_template in the sibling list.

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 the selection condition (pending signers only), an explicit exclusion (expired documents cannot be reminded), and names the correct alternative for that case (extend_document). That is a complete routing rule against the sibling tool set.

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

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the appended-certificate fallback when fields are omitted, that signing_urls are private and per-signer, and that the send is billable (one unit plus a reported cost). It omits anything about reversibility or how to cancel/void a send, and does not state delivery mechanics (email/text) even though the schema hints at them.

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?

Four sentences, front-loaded with the action and recipient limits, then input form, then field behavior, then return/billing. Every sentence carries distinct information and none restates the title.

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 mutating send with 9 parameters and no output schema, the description is substantively complete: it describes the return payload (document plus per-signer signing_url and cost) and the billing consequence. What is missing is failure/edge behavior for a write operation with no annotation safety profile — e.g., what happens on invalid recipients or how to undo a mistaken send.

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?

At 67% schema coverage, the description adds real value: it contrasts file_url and file_base64 as mutually substitutable input paths, explains the recipient tier caps (25 signers/approvers, 25 view-only, 25 CC) that contextualize the signers array, and clarifies the fields-optional path. It says nothing about sequential, expires_days, title, or filename, leaving those 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?

The first sentence gives a specific verb and resource (upload a PDF and send it for signature) with concrete recipient caps, so the agent knows exactly what the tool produces. It stops short of naming the closest sibling, send_from_template, which is the obvious alternative when the source is a template rather than an uploaded file.

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 file_url vs file_base64 clause tells the agent how to supply input, and the fields clause explains the consequences of including or omitting field placement. There is no explicit when-to-use-this-vs-alternative guidance against send_from_template or list_templates, nor any noted preconditions beyond the PDF requirement.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that sends count as a billable unit and explains signer-to-role assignment, but it omits permissions, reversibility or void behavior, and failure handling for role or slot mismatches.

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 core action and signer contract. The billing note is short and relevant, 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?

For a six-parameter send mutation with no annotations and no output schema, the description is incomplete. It covers the signer assignment and billable-unit behavior but not expiry, sequential signing, permissions, or what happens after sending.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the central signers array and 0-based slot behavior well, but leaves title, message, sequential, template_id, and expires_days without added meaning.

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: create and send a document from a saved template. This inherently distinguishes it from send_document and list_templates, but it does not explicitly route between this tool and the sibling send 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?

Use is implied by requiring a template_id and by the comparison to send_document, but the description does not state when to choose this over send_document or list_templates. No prerequisites or exclusions are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Look up' implies a non-mutating read and 'any document, not only yours' hints that ownership scoping doesn't apply, but there is no mention of auth/permission requirements, whether the code is single-use or expiring, or any failure behavior for an unrecognized code.

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 the action and its result, and the second sentence delivers the scope constraint without padding. Nothing here is wasted.

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

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

Only one parameter and no output schema, and the description does state the return concept ('the signing record it belongs to'), which partially compensates. Still missing for an unannotated tool: permission model, behavior on invalid codes, and any rate-limit note for what looks like a public verification endpoint.

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 the schema already documents the code parameter with the XXXX-XXXX-XXXX-XXXX format. The description adds no additional meaning about the code (case sensitivity, trimming, whitespace, expiry) beyond what the schema states, 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: look up a verification code and return the signing record it belongs to. It is clearly distinguishable from the sibling set (account, document, evidence, send/void/remind), though it never explicitly contrasts itself with the closest alternatives like get_document or get_evidence.

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 scope note 'Works for any document, not only yours' implies when this tool applies and how it differs from a user-scoped lookup, which is useful guidance. However, it names no alternative tool and states no conditions for choosing it over get_document/get_evidence, so usage is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the effect (nobody can sign) and the billing behavior (refund if voided within 10 minutes of sending), but omits permission requirements, whether the action is reversible, and error behavior for already-signed or closed documents.

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: the core action first, then the billing consequence. Every clause carries information and nothing is 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 mutating tool with no annotations and no output schema, the description covers the outcome and refund rule but is silent on permissions, irreversibility, and the meaning of its two bare parameters. Adequate, but gaps remain an agent would want closed.

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

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

Schema description coverage is 0% and the description adds nothing about the two parameters. It does not clarify the format of `id` or what `reason` is used for, so the description fails to compensate for the undocumented 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?

States a specific verb and effect: withdraw an open document so nobody can sign it. This is unambiguous and easily separated from siblings like send_document, remind_document, or get_document, 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?

"Open document" implies a precondition for use, but the description never states when to void versus alternatives such as remind_document or a re-send, nor what to do for non-open documents. Usage is inferable but not spelled out.

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