Server Quality Checklist

Tool Scores

• check_statusA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description aligns by describing a read operation (get state). Adds behavioral context: it is a polling surface, returns signer timestamps and decline reasons, and provides audit-trail events—details beyond the annotation.

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

  Conciseness5/5

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

  Two sentences, each earning their place: first sentence defines return values, second provides usage context. No filler.

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

  Completeness5/5

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

  Given the simple input (one required parameter) and no output schema, the description fully covers what the tool returns and when to use it. No gaps.

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

  Parameters3/5

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

  Schema coverage is 100%, and the description only mentions the parameter implicitly by referencing 'document_id' from siblings. No additional semantic detail beyond the schema's existing description.

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

  Purpose5/5

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

  The description specifies the verb 'get' and resource 'state of a document', naming detailed return fields (overall status, signer actions with timestamps, audit trail). It distinguishes this tool from siblings by calling it 'the polling surface', contrasting with other tools like remind or download_signed.

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

  Usage Guidelines4/5

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

  Explicitly states when to call it: 'call it when the human asks "did they sign?"'. No explicit when-not-to-use, but the context clearly implies it's for checking status after sending, not for initiating actions.

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

• download_signedA
  4.4/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true, and the description adds behavioural context: short-lived URL (5 min), SHA-256 hash from audit ledger, prerequisite of signed document, and network permission requirement. This goes beyond annotations.

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

  Conciseness5/5

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

  Three concise sentences with front-loaded purpose, then usage guidance. No redundant information; every sentence earns its place.

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

  Completeness4/5

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

  Despite no output schema, the description explains return values (URL and hash) adequately. Addresses environment constraints and prerequisites. Could explicitly mention URL format or instructions, but overall complete for a simple tool with strong annotations.

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

  Parameters3/5

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

  Input schema covers 100% of parameters with descriptions. The description adds minor context (future expansion for artifact), but baseline is 3 due to high schema coverage.

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

  Purpose5/5

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

  The description clearly states 'Get a short-lived (5 min) download URL for the signed PDF, plus the SHA-256 hash'. It specifies the verb (get), resource (download URL and hash), and distinguishes from siblings like check_status and list_documents by its unique output.

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

  Usage Guidelines4/5

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

  The description gives explicit when-to-use and caution: 'Only works once the document status is signed' and 'Only fetch the URL yourself if your environment permits network access... many sandboxes do not'. It does not name alternative tools but provides clear context.

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

• list_templatesA
  4.5/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description adds that templates carry signer roles and pre-placed fields completed by signers (not prefilled by sender), which is valuable behavioral context.

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

  Conciseness5/5

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

  The description is concise, front-loaded with the main action, and every sentence adds value without unnecessary words.

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

  Completeness5/5

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

  Given no output schema and zero parameters, the description sufficiently explains the tool's purpose, the nature of templates, and where to start in the workflow.

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

  Parameters4/5

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

  With zero parameters, the description adds meaning by explaining what the list contains (signer roles and pre-placed fields), guiding the agent on what to expect from the output.

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

  Purpose5/5

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

  The description clearly states 'List the sender's document templates.' with a specific verb and resource, effectively distinguishing it from sibling tools like send_for_signature and list_documents.

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

  Usage Guidelines4/5

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

  The description says 'Start here to find what can be sent.' implying it's the initial step before using send_for_signature. It provides context but doesn't explicitly state when not to use it or name alternatives.

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

• list_documentsA
  4.6/5.0
  Behavior5/5

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

  Adds significant behavioral detail beyond readOnlyHint annotation: explains the 'cancelled' vs 'declined' mapping and the required reporting behavior. No contradiction with annotations.

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

  Conciseness5/5

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

  Three front-loaded sentences with no redundancy. Each sentence adds distinct value: purpose, behavioral nuance, and pagination guidance.

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

  Completeness4/5

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

  Covers main functionality: listing, filtering, pagination, and crucial status interpretation. Could mention return fields but is sufficient given no output schema and simple param list.

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

  Parameters4/5

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

  Adds meaning to limit/offset (pagination) and explains the status filter's virtual 'declined' mapping. Schema has 33% coverage; description compensates for the undocumented params.

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

  Purpose5/5

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

  Clearly states verb 'List', resource 'sender's documents', and ordering 'newest first'. Differentiates from siblings like list_templates and other action-oriented tools.

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

  Usage Guidelines4/5

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

  Provides context on filtering by status and pagination, and an important instruction on reporting cancelled status as declined. Could be more explicit about when to use this vs siblings, but the context signals help.

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

• remindA
  4.6/5.0
  Behavior5/5

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

  Discloses server-side throttling behavior (4-hour skip) and response contents (who was reminded vs skipped), adding significant context beyond annotations which already indicate non-destructive and not fully open.

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

  Conciseness5/5

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

  Two sentences, front-loaded with action and resource, no fluff. Every sentence adds essential detail (scope, throttling, response structure).

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

  Completeness4/5

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

  Covers core behavior, throttling, and response listing. Missing edge cases like no pending signers or invalid document, but for a reminder tool, this is sufficient.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. Description adds value by explaining optional signer_email parameter usage (remind all vs one) and connects parameter behavior to throttling.

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

  Purpose5/5

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

  Description clearly states the action (send a reminder email) and resource (signers who have not signed yet). It specifies the scope (all or one by email), distinguishing it from sibling tools like send_for_signature and check_status.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use (reminding pending signers) and mentions server-side throttling. However, it does not explicitly state when not to use (e.g., document fully signed) or directly reference sibling tool alternatives.

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

• send_for_signatureA
  4.7/5.0
  Behavior5/5

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

  Annotations only provide openWorldHint=false and destructiveHint=false, but the description goes far beyond: warns about email exposure, requires exact email use, explains idempotency with request_id, role assignment via array position, and mentions cancellation via dashboard. No contradictions.

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

  Conciseness5/5

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

  The description is detailed but concise, with no filler. It front-loads the core action, then adds warnings, parameter behavior, and return value in a logical flow. Every sentence serves a purpose.

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

  Completeness4/5

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

  For a tool with 7 parameters and no output schema, the description covers the action, parameter usage, return value (document id for polling), and error handling (dry_run, idempotency). It could mention error conditions more explicitly, but overall it is quite complete.

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

  Parameters5/5

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

  Schema description coverage is 100%, and the description adds crucial context: signers array position assigns template roles, dry_run validates without sending, request_id prevents double-sending, and signing_order_type options are explained. This exceeds the schema's own descriptions.

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

  Purpose5/5

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

  The description starts with a clear verb+resource: 'Create a document from a template and email it to signers for signature.' It distinguishes from sibling tools like check_status and download_signed by focusing on the sending action.

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

  Usage Guidelines4/5

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

  The description explicitly says when to use (sending for signature) and provides critical usage rules: never guess emails, ask if ambiguous, use dry_run for validation, and handle retries with request_id. It could explicitly contrast with siblings, but the context signals list them, and the description implies when not to use (e.g., for status or download).

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