Signathing

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. It implies a read operation and richly describes the returned evidence contents, but says nothing about authentication requirements, whether the package is generated on demand or cached, or any side effects. It is informative about output but thin on operational behavior.

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 with no filler, and the resource being fetched is front-loaded before the list of contents. It is slightly long, but every clause describes a distinct element of the package.

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, but the description effectively enumerates the return payload (hashes, signers/events, log positions, verification recipe), which compensates well. Combined with only one simple parameter, the main residual gap is the lack of usage routing against sibling tools.

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 'id' integer parameter. The phrase 'for a document' is the only clue tying the id to a document identifier, which is a minimal but real addition beyond the bare schema. It does not clarify accepted formats or failure behavior for unknown ids.

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 gives a specific verb and resource ('The court-ready evidence package for a document') and enumerates the concrete contents (SHA-256 hashes, signers/events, log positions, verification recipe), so the agent knows exactly what it fetches. It does not explicitly distinguish itself from the closest sibling, get_document, which is the one remaining ambiguity.

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 statement of when to use this tool versus get_document or verify_signature_code, and no prerequisites or exclusions. The 'court-ready' framing implies a legal/audit context but the agent must infer that usage 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?

No annotations are provided, so the description carries the full burden. It does add real value by disclosing ordering/scope ('most recent', 'your') and by enumerating the status values that aren't in the schema. However, it says nothing about result limits, pagination, or the default number of documents 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 front-loaded sentence with no filler; the scope and the filter come first. 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?

With no annotations, no output schema, and 0% schema coverage, the description should close more gaps. It omits the meaning and default of `limit`, pagination behavior, and what a returned document contains, so an agent still has to guess on several fronts.

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% with two parameters. The description fully compensates for `status` by enumerating the five valid values, which the schema leaves as an unconstrained string. It says nothing about `limit`, leaving half the parameters undocumented.

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 documents') plus the scope ('your most recent documents'), which distinguishes it from the single-resource get_document sibling. It does not explicitly name siblings, but the plural/list framing makes the boundary obvious.

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?

'optionally filtered by status' implies when the filter applies, but there is no guidance on when to reach for this versus get_document or other siblings, no note about default behavior when no status is supplied, and no prerequisites.

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, and it does disclose a real constraint: at most once an hour per document (a rate limit). It omits permissions/auth requirements and what happens when there are no pending signers or the document is already complete, leaving notable gaps for a mutation tool.

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 with no filler; the action is front-loaded and the rate limit follows as a qualifier. Nothing could be cut without losing meaning.

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 tool with no output schema, the description covers the action and the key rate constraint. It falls slightly short by not identifying the id as a document id or describing behavior when no signers are pending.

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 single 'id' parameter has no schema description, so the description must compensate. Saying 'per document' hints that id is a document identifier, but it never states this directly or notes the type/format.

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: re-send the signing link to unsigned recipients, which is clearly a reminder action distinct from send_document's initial send. It never names the sibling send_document explicitly, so the differentiation is inferred rather than stated.

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

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

The phrase 'everyone who has not signed yet' implies the trigger condition (only for pending signers), which is useful context. However, it gives no explicit when-not guidance, no mention of send_document as the alternative for first-time sends, and no prerequisites for calling 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?

With no annotations, the description carries the full burden and does well: it discloses recipient limits, the certificate-page fallback when fields are omitted, the return payload (per-signer signing_url plus cost), and billing ('Counts as one billable unit'). It omits whether the send is irreversible, expiration behavior, and any permission requirements, keeping it short of a 5.

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

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

Four dense sentences, each earning its place: send scope, file input, field-vs-certificate behavior, then return and billing. Front-loaded with the core action and free of 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 9-parameter mutation tool with no annotations and no output schema, the description covers the essentials an agent needs: inputs, the fields/certificate trade-off, recipient limits, and return values. It leaves expiration and sequential delivery unexplained, but those are documented in the schema.

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

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

Schema coverage is 67%, so the schema already documents most parameters. The description adds the meaningful distinction between file_url and file_base64 ('if you have the file in hand') and reconciles the 25+25 cap with the schema's maxItems of 50, but says nothing about expires_days, sequential, message, or signerIndex.

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+scope: upload a PDF and send it for signature, with explicit caps (25 signers, 25 view-only). This is unmistakably distinct from sibling tools like void_document, remind_document, and get_document, which operate on already-sent documents.

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 rather than stated: the description explains the internal branch (with fields vs. certificate-page fallback) and the file-input alternatives, but never says when to choose this tool over remind_document or void_document, nor states prerequisites such as required auth. Adequate but with clear gaps.

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.