Check the status of a document previously sent for signature: overall state (sent/completed/declined/expired/voided), per-recipient progress (pending/viewed/signed), and the signed PDF download URL once complete. Requires a SignSimple API key.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope_id | Yes | The envelopeId returned by send_for_signature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return data (overall state, per-recipient progress, signed PDF URL) and the API key requirement, making it clear this is a read-only check. It does not mention error handling, but 'Check' implies non-mutating and 'once complete' hints at conditional URL availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then specifics. It is concise and every word earns its place, listing status categories and output details without fluff.
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 status tool with no output schema, the description adequately covers what is returned and the context of use. Minor gaps include behavior for invalid envelope_id and explicit mention of when the download URL is available, but these are not critical given the tool's simplicity.
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% for the single parameter environment_id, with its own description referencing send_for_signature. The tool description adds no additional parameter semantics, so the baseline score 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?
Description uses specific verb 'Check' and identifies resource 'status of a document previously sent for signature'. It details the status categories (sent/completed/declined/expired/voided) and per-recipient progress, clearly differentiating from siblings list_documents, list_templates, and send_for_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?
Implies the tool is used after send_for_signature to track progress. The context 'previously sent' is clear, but it does not explicitly state when not to use it or contrast with list_documents. Provides a prerequisite (API key) but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: listing documents, checking a single document's status, listing templates, and sending for signature. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: get_document_status, list_documents, list_templates, send_for_signature. The conventions are uniform.
Four tools is a well-scoped set for a focused e-signature service, covering the core workflow without unnecessary bulk. This fits the typical 3-15 tool range.
The surface covers the essential lifecycle: send, check status, list documents, and generate from templates. Minor gaps exist, such as no cancel/void or reminder actions, but they are not critical for the basic use case.