Server Quality Checklist

Tool Scores

• document_completed_pdfC
  2.8/5.0
  Behavior1/5

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

  Annotations indicate readOnlyHint=false (may modify state) and destructiveHint=false. The description uses 'Fetch', implying a read-only operation, contradicting the annotation. No additional behavioral traits are disclosed.

  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 concise sentences: one states the purpose, the other explains usage. No extraneous content. Suitable for quick comprehension.

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

  Completeness2/5

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

  Despite having 5 parameters and no output schema, the description only covers mode. It omits critical details like document_id requirement, file_format options, save_to_path, include_audit_page, and return value format.

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

  Parameters2/5

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

  With 0% schema description coverage, the description only explains the 'mode' parameter. Other parameters (document_id, file_format, save_to_path, include_audit_page) are not mentioned, leaving the agent uninformed about their purpose.

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

  Purpose4/5

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

  The description clearly states 'Fetch the completed PDF', identifying the verb and resource. It distinguishes this tool from siblings like document_get by specifying that it retrieves the completed PDF, but it does not explicitly differentiate from document_get or other PDF-related tools.

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

  Usage Guidelines3/5

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

  The description provides usage guidance for modes: base64 for displaying in artifact/chat and url for shareable link. However, it does not offer context on when to avoid using this tool or mention alternatives.

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

• document_send_draftC
  2.8/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the behavioral trait 'requires confirm_send', but fails to disclose side effects, irreversibility, or what happens to the draft after sending.

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

  Conciseness3/5

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

  The description is very short (one sentence) and to the point, but lacks detail. It earns no waste, but also fails to provide sufficient information for a safe and correct invocation.

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

  Completeness2/5

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

  No output schema and low schema coverage. The description does not explain return values, error conditions, or state transitions (e.g., draft becomes sent). Incomplete for a mutation tool with 3 parameters.

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

  Parameters2/5

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

  Schema description coverage is 0%. The description only mentions document_id and confirm_send implicitly, leaving the 'message' parameter completely unexplained. Little value added beyond the schema's property names.

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

  Purpose4/5

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

  The description clearly states the action ('send') and resource ('previously created draft document'), differentiating it from sibling tools like document_send_reminder which deals with reminders. However, it does not explicitly contrast with alternatives.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives (e.g., document_send_reminder). The requirement for confirm_send is stated but lacks context on prerequisites or typical scenarios.

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

• template_deleteC
  2.9/5.0
  Behavior2/5

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

  The description merely repeats 'Delete', which is essentially a tautology. The destructiveHint annotation already signals the tool's destructive nature, and the description adds no extra behavioral information such as irreversibility, required permissions, or side effects.

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

  Conciseness3/5

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

  The description is extremely concise (one sentence), but this conciseness comes at the cost of missing critical information. It could easily include a brief note on the parameter without losing efficiency.

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

  Completeness2/5

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

  Given the tool's simplicity (one parameter, no output schema), the description is incomplete. It omits the purpose of the required parameter and any mention of expected outcomes or errors, making it barely adequate for an AI agent.

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

  Parameters1/5

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

  The description provides no explanation for the template_id parameter. With 0% schema coverage on parameters, the description must compensate but fails entirely, leaving the agent to infer the parameter's meaning from context.

  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 (Delete) and the resource (a SignWell template). This effectively distinguishes it from sibling tools like template_create, template_get, and template_update.

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

  Usage Guidelines3/5

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

  No explicit guidance on when to use this tool versus alternatives or any prerequisites. While the purpose is obvious, the lack of context or exclusions limits its helpfulness for an AI agent deciding between tools.

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

• document_send_reminderB
  3/5.0
  Behavior3/5

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

  Annotations already indicate the tool is not read-only nor destructive. The description adds that it sends an email, which is a non-trivial side effect, but does not disclose details like whether duplicate reminders are allowed or frequency limits.

  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 a single sentence with no redundant information. It is front-loaded and efficiently communicates the tool's core function.

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

  Completeness2/5

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

  Given no output schema and minimal annotations, the description lacks details on return values, potential errors, prerequisites, or behavioral nuances like idempotency. It is insufficient for an agent to fully understand the tool's impact.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must explain parameters. It mentions recipient_email as optional but does not explain 'message' or that document_id is required. The description adds minimal value beyond parameter names.

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

  Purpose4/5

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

  The description clearly states the tool sends a reminder email for a document, with an optional specific recipient. It uses a specific verb-resource combination and distinguishes from sibling tools like document_send_draft by specifying 'reminder'.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the document must be signed or active, or when to prefer document_send_draft over this.

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

• document_getB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description is consistent. However, it adds no extra behavioral context such as authentication needs or response format.

  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 a single, clear sentence with no unnecessary words or repetition.

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

  Completeness2/5

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

  With no output schema, the description fails to explain what the response contains (e.g., fields of the status) or how the status is defined, making it incomplete for a simple tool.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain the 'document_id' parameter or any other parameter semantics, leaving the agent without sufficient information.

  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 uses a specific verb ('Fetch') and resource ('status for a SignWell document'), clearly distinguishing it from sibling tools like 'document_create' or 'document_list'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus its siblings, nor does it mention any prerequisites or exclusions.

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

• document_listB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true. The description adds that the tool lists documents with filters, but does not disclose pagination behavior, rate limits, or empty results handling. It does not contradict annotations.

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

  Conciseness4/5

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

  The description is a single concise sentence with no wasted words. However, it could be front-loaded with more structured details like output format.

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

  Completeness2/5

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

  Given 7 parameters, no output schema, and 14 siblings, the description is too minimal. It lacks pagination details, date filter explanation, and output expectations, making it incomplete for an agent to use effectively.

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

  Parameters2/5

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

  With 0% schema description coverage, the description should compensate. It only clarifies three parameters (status, archived, search) out of seven, omitting page, per_page, and date filters. This provides partial meaning but is insufficient.

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

  Purpose4/5

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

  The description clearly states 'List SignWell documents' with optional filtering, indicating the verb and resource. While it differentiates from single-document tools like document_get, it does not explicitly contrast with sibling tools.

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

  Usage Guidelines3/5

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

  The description mentions optional filtering, implying use cases for filtered lists, but provides no explicit guidance on when to use this tool versus alternatives like document_get, search, etc.

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

• template_listB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds 'pagination' context but lacks details on rate limits, default ordering, or behavior when reaching the end of results. Does not contradict annotations.

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

  Conciseness4/5

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

  Extremely concise with no wasted words. However, it is slightly under-specified; a bit more detail on parameters would not have reduced conciseness significantly.

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

  Completeness3/5

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

  Given the tool is a simple list with no output schema, the description is adequate but minimal. It does not specify default ordering or how to handle pagination across multiple requests, which an agent might need for full usage.

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

  Parameters2/5

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

  With 0% schema description coverage, the description should explain the parameters. It only hints at pagination without explicitly mapping 'page' and 'per_page' to the pagination mechanism, leaving the agent to infer their roles.

  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 the verb 'List' and resource 'SignWell templates', and includes 'with pagination' to indicate the core feature. It effectively differentiates from sibling tools like template_get (single template) and template_create.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives like document_list or how to handle pagination across multiple calls. No mention of filtering, ordering, or limitations.

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

• template_updateA
  4/5.0
  Behavior4/5

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

  Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds the behavioral trait of partial/merge update, which is valuable 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?

  A single, front-loaded sentence that effectively conveys the core purpose and key usage constraint. No unnecessary words.

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

  Completeness2/5

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

  Given the tool's complexity (23 parameters, nested objects, no output schema), the description is too minimal. It lacks information about return value (expected response), prerequisites (need template_id), and error conditions. More context is needed for reliable usage.

  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?

  The description adds no detail about individual parameters beyond the schema. The schema itself has rich descriptions for most parameters, so high coverage keeps baseline at 3. The partial update hint adds some value but not parameter-specific.

  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 the action (update), the resource (existing SignWell template), and the constraint (only provide fields to change). It distinguishes from sibling tools like template_create and template_delete.

  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 says when to use (update existing template) and implies partial update ('only provide fields you want to change'). No explicit mention of when not to use or alternatives, but context from sibling tools makes it clear.

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

• template_create_documentA
  4.2/5.0
  Behavior4/5

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

  The description discloses that the tool sends the document for signing by default, which is a key behavioral trait. It also explains the draft flag behavior. Annotations show readOnlyHint=false and destructiveHint=false, and the description does not contradict these. It adds value beyond annotations by detailing the default send action.

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

  Conciseness4/5

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

  The description is well-structured with sections, bold emphasis, bullet list for required fields, and a JSON example. It is front-loaded with the main purpose and contains no fluff, though it could be slightly more compact by removing redundant phrasing.

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

  Completeness3/5

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

  Given the tool has 18 parameters (2 required), nested objects, and no output schema, the description provides a good overview for the primary use case but lacks details on many optional parameters. An agent might need additional context for full usage, but the example and required field descriptions help.

  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 description coverage is low (17%), and the description compensates by explaining the required parameters (template_id, recipients) with a detailed example and structure for recipients. However, it does not cover many optional parameters like name, message, subject, etc., leaving gaps for an agent.

  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 'Create and send a document from a template' and distinguishes this from creating non-template documents or templates themselves. The IMPORTANT note clarifies the default sending behavior vs. draft, which helps differentiate it from sibling tools like document_create or document_send_draft.

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

  Usage Guidelines5/5

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

  Explicitly provides when to use this tool (when user asks to send a template) and when to use draft: true (only if user explicitly asks for a draft or review before sending). This gives clear guidance and prevents misuse.

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

• template_getA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description adds no extra behavioral context. It does not contradict annotations, but lacks additional disclosure such as permissions or rate limits.

  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 a single sentence that is front-loaded and contains no unnecessary words. Every word 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?

  For a simple read tool with clear annotations and a single parameter, the description is sufficient. It could mention that the output is the full template object, but given no output schema, the current level is adequate.

  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 0%, but with only one required parameter (template_id), the description 'by ID' clarifies its role. Baseline for 0 params is 4, and the description adds meaning beyond the schema.

  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 the action (Fetch) and specific resource (an individual SignWell template by ID). It distinguishes itself from sibling tools like template_list (which fetches all templates) and template_create (which creates).

  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 implies usage when a specific template ID is known, which is clear context. However, no explicit exclusions or alternatives are mentioned, though the purpose sufficiently guides selection.

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

• template_createA
  4.5/5.0
  Behavior5/5

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

  Annotations indicate a non-destructive write operation. The description adds substantial behavioral context: text tag requirements, multi-signer examples, common errors, and critical notes about selectable text. This goes well beyond the annotation hints.

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

  Conciseness3/5

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

  The description is very long and includes multiple examples that could be condensed. While the structure (sections like RECOMMENDED WORKFLOW) is good, the verbosity exceeds what is necessary for a concise tool description.

  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 complex tool with 22 parameters and no output schema, the description covers workflow, parameter usage, error handling, and edge cases (e.g., text tags vs manual fields). It is highly complete for the agent to use effectively.

  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 100% schema description coverage, baseline is 3. The description adds meaning beyond the schema by explaining parameter relationships (e.g., text_tags and placeholder id mapping), providing example calls, and clarifying content source preferences.

  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 'Create a SignWell template for reusable signature documents,' a clear verb+resource statement. It distinguishes from sibling tools like template_create_document by focusing on template creation.

  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 provides a detailed recommended workflow (file_store → file_validate_text_tags → template_create) and step-by-step examples. However, it does not explicitly state when not to use this tool or list alternatives.

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

• file_validate_text_tagsA
  4.7/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true, and the description aligns perfectly by stating 'Validate' (no mutation) and listing detailed return values (extractability, valid tags, malformed tags, etc.). It adds context on what happens to the PDF (extract text, check tags) without contradicting 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?

  The description is concise yet comprehensive. It is front-loaded with the main purpose, followed by a recommended workflow, input methods, and output details. Every sentence adds value, and the structure enables quick scanning.

  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?

  Despite no output schema, the description lists all return items (extractability, valid/malformed tags, signer numbers, recommendations), making the tool's behavior fully predictable. Input options are fully covered. The workflow context and sibling tools complete the situational understanding.

  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% with parameter descriptions, but the description adds semantic context: it explains that the tool accepts multiple input methods (file_token, file_base64, file_url, resource_uri) and clarifies the role of use_picker as a fallback to native file picker. This goes beyond the schema by grouping parameters by purpose.

  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 the action ('Validate text tags in a PDF') and the resource/noun ('text tags in a PDF'), with immediate context ('before creating a template or document'). It distinguishes from sibling tools by specifying validation as a preparatory step, not a creation or retrieval operation.

  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 provides a recommended workflow ('file_store → file_validate_text_tags → template_create/document_create'), clearly indicating when to use the tool. However, it does not explicitly state when not to use it or name specific alternatives beyond the workflow sequence.

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

• document_createA
  4.9/5.0
  Behavior5/5

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

  Discloses beyond annotations: documents always created as draft, supported file types, auto-conversion of content_text, sandbox inaccessibility, file_store native picker, and text_tags behavior. No annotation contradiction.

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

  Conciseness4/5

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

  Well-structured with sections, front-loaded with purpose, but somewhat verbose. Could tighten some repeated warnings, but overall efficient and easy to scan.

  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?

  Covers essential behavior, parameter options, workflows, and common pitfalls (sandbox accessibility, file_store usage). Adequately complete for an agent to use effectively with no output schema.

  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?

  Adds significant meaning beyond schema: order of preference for content sources, examples, explanation of text_tags recipient ID mapping, and details on reminders and embedded signing. Compensates for any missing schema 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 clearly states 'Create a SignWell document (always created as a draft)' and provides specific verb+resource. It distinguishes from siblings like document_send_draft and file_store.

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

  Usage Guidelines5/5

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

  Includes explicit CRITICAL RULES, workflows for user files vs Claude-generated files, and guidance on when to use file_store vs content_text vs file_base64. States when not to use certain methods.

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

• file_storeA
  4.9/5.0
  Behavior5/5

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

  Discloses that the tool does not read/parse/convert the file, opens a native OS file picker when called with no arguments, and returns a file_token. 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.

  Conciseness4/5

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

  Well-structured with sections, bold headers, and bullet points. Slightly verbose but all content is valuable; could tighten a bit without losing clarity.

  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?

  Covers all aspects: purpose, argument usage, behavioral notes, edge cases (chat attachments, generated files), and integration with other tools. Comprehensive given no output schema.

  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?

  Despite 0% schema coverage, the description explains each parameter's purpose and usage in detail, including when to use file_url vs file_path vs no arguments, and warns against resource_uri.

  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 'Store a user's existing file for upcoming SignWell requests' with a specific verb and resource. Distinguishes from siblings by noting it returns a file_token for document/template tools.

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

  Usage Guidelines5/5

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

  Provides explicit guidance on argument preference order, warns against using resource_uri for chat attachments, and instructs to pass file_base64 directly to document_create for Claude-generated files.

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