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

The description states 'IRREVERSIBLE' and 'ASYNC', but the annotations set destructiveHint=false. This is a contradiction because irreversible state changes are typically considered destructive. Per the scoring rules, a contradiction with annotations yields a score of 1.

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?

The description is lengthy but well-structured with important sections clearly separated. It is front-loaded with the main action. While every sentence earns its place, some redundancy could be trimmed for even tighter conciseness.

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?

Given the complexity (preconditions, async behavior, two delivery methods, irreversibility), the description covers most critical aspects. It explains polling steps and what not to do. However, it lacks information on output/response and potential errors, which would make it fully 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 input schema has two required parameters (requestId, caseFileId) with 0% schema description coverage. The tool description does not explain what these parameters represent or how they are used. No value is added beyond the parameter names.

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 clearly states the action: 'Activates a signature request, transitioning from DRAFT to ACTIVE and sending signing invitations to all signatories.' This provides a specific verb, resource, and effect, differentiating it from sibling tools like create or cancel.

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 description explicitly states when not to call ('Do NOT call this immediately after uploading files'), lists detailed preconditions (DRAFT status, signatory exists, documents uploaded, etc.), and provides guidance on delivery methods (INTERPOSITION vs ADVANCED). This is exemplary usage guidance.

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?

Annotations provide no behavioral hints (readOnlyHint=false, destructiveHint=false). The description adds the important detail that 'the validator must approve before the signatory can sign,' which clarifies the approval flow. However, it does not disclose whether calling the tool again replaces or appends validators, leaving ambiguity.

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?

The description is two sentences: one for the action and one for prerequisites. It is concise, front-loaded, and every sentence adds value without redundancy.

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?

The tool has 4 required parameters, no output schema, and moderate complexity. The description explains the purpose and prerequisites but omits expected return values or confirmation behavior, which would help the agent understand the result of the operation.

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 lists the required IDs and their origin tools (e.g., 'validatorId in validatorIds array'), which provides context beyond the bare property names. But it does not explain parameter formats or constraints beyond what the schema already specifies via patterns.

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 clearly states the action: 'Assigns one or more validators to a specific signatory in a signature request.' It uses a specific verb and resource, and distinguishes from siblings like signature_participant_create by focusing on assignment rather than creation.

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 description explicitly lists prerequisites (creation of validator, signatory, request, case file) and maps them to parameter IDs, guiding the agent on when to use this tool (after those creations) and not before.

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?

Annotations indicate readOnlyHint=false, aligning with the create operation described. The description adds value by instructing the agent to generate a UUID v4 for 'id' and stating the return value (caseFileId), which goes beyond the schema's validation pattern.

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 concise sentences with no superfluous content. The first sentence defines purpose, second provides usage order, and third gives key parameter instruction and return value.

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?

Given 5 parameters and no output schema, the description adequately covers the tool's role and sequencing but omits error scenarios, auth requirements, and detailed return format, leaving gaps for a complete understanding.

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 clarify parameters. It only explains the 'id' parameter (generate UUID v4) and does not cover 'name', 'reference', 'useCaseId', or 'description', leaving their semantics unclear.

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 clearly states the tool creates a case file and identifies it as the top-level container for all related operations, distinguishing it from sibling tools like case_file_list and case_file_get.

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 description explicitly instructs to call this tool first before any other operation and mentions the returned caseFileId is needed for subsequent calls, providing clear sequence guidance. It lacks explicit when-not-to-use instructions but effectively communicates its role.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the requirement of caseFileId and the verification use case but no additional behavioral details like return format or error handling.

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, no waste. The purpose is front-loaded, and the usage guidance follows immediately. Every sentence adds value.

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 retrieval tool with one parameter and no output schema, the description covers purpose, requirement, and use case. However, it omits any hint about the return format or behavior (e.g., what is returned if the file exists vs. not). Minor gap.

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?

With schema description coverage at 0%, the description must compensate. It mentions 'Requires: caseFileId' but adds no further meaning (e.g., format, example, or what the identifier represents) beyond what the schema already provides.

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 'Retrieves details of a specific case file' clearly states the verb (retrieves) and resource (case file details). It distinguishes from sibling tools like case_file_create and case_file_list by specifying retrieval of a single 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?

The description provides explicit context: 'Use to verify a case file exists before creating evidence groups, dossiers, or signature requests.' This tells the agent when to use the tool, though it does not list when not to use it or alternatives.

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?

Annotations already indicate read-only and idempotent. The description adds that it returns a paginated list with specific fields, which supplements the annotations without contradiction.

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?

The description is two concise sentences, front-loading the purpose and efficiently covering key usage details without waste.

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?

The description covers the basic purpose and return format but omits details about pagination metadata and filtering options, leaving the tool only partially explained for its complexity.

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 userId is described in the description; the page, order, and filter parameters are entirely undocumented despite 0% schema coverage. The description adds meaning only for the required parameter.

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 clearly states the tool lists all case files, scoped to the user's account via userId. This distinguishes it from siblings like case_file_get or dossier_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?

Provides context on when to use (listing case files) and where to get userId (session_login/info). Does not explicitly exclude alternatives, but the context is clear.

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?

The description adds significant context beyond annotations: it discloses async state transitions (DRAFT → CERTIFYING → CERTIFIED) and the locking of evidence. Annotations only indicate non-read-only and non-destructive, so the description enriches the behavioral profile.

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, each with clear purpose: action/outcome, prerequisites, async behavior. Front-loaded and no wasted words.

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?

The description covers prerequisites, async behavior, and outcome, but does not specify what the tool returns immediately (e.g., a job ID). Given the complexity, more detail about the return value would improve completeness.

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?

While the input schema has no parameter descriptions (0% coverage), the description clarifies that dossierId and caseFileId come from prior steps (dossier_create and case_file_create). This adds meaning beyond the schema fields.

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 clearly states the tool certifies a dossier, generating a tamper-evident PDF and locking linked evidence. This specific verb+resource+outcome distinguishes it from sibling tools like dossier_create or dossier_group_certify.

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 description lists required prior steps (dossier_create, dossier_evidence_link, case_file_create) and explains async behavior with polling instructions. This provides excellent when-to-use and post-invocation guidance.

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?

Annotations indicate readOnlyHint=false (creation) and destructiveHint=false. The description adds behavioral details: generate UUID v4 for id, returns dossierId, and mentions post-creation steps. There is no contradiction with annotations, and disclosures are helpful beyond structured fields.

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 purpose, no wasted words. Each sentence adds distinct value: what it does, prerequisites, parameter guidance, return value, and follow-up actions.

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?

Given the complexity of 11 parameters and a multi-step workflow, the description covers the essential narrative (prerequisites, creation, subsequent linking and certification). It mentions the return value dossierId. Could detail more parameters, but provides enough for an agent to understand the tool's role in the process.

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 has 11 parameters with 0% description coverage. The description adds specific meaning for 'id' (UUID v4 format) and 'caseFileId' (from case_file_create), but does not explain other required parameters like name, language, validityFrom, validityTo. Partial compensation but incomplete.

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 clearly states the tool creates a dossier to aggregate certified evidence groups into a tamper-evident PDF. It uses specific verbs and resource, and distinguishes from siblings by outlining a sequential workflow involving case_file_create, dossier_evidence_link, and dossier_certify.

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 description provides clear context for use: requires a prior case_file_create to obtain caseFileId, and evidence groups must be CLOSED before linking. It does not explicitly state when not to use, but the workflow guidance effectively differentiates from alternatives like dossier_update or dossier_delete.

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?

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context: irreversibility and status-specific availability, which goes beyond the annotations without any contradiction.

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?

The description is two concise sentences, front-loaded with the action and resource, and contains no extraneous information.

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?

Given the tool's simplicity (delete operation with two parameters) and lack of output schema, the description covers all necessary aspects: purpose, usage conditions, behavioral implications, and required inputs.

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 description merely lists the required parameters (caseFileId and dossierId) without adding any semantic meaning beyond what the schema provides. With 0% schema description coverage, the description should compensate but fails to do so.

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 clearly states the action 'Deletes a dossier' and specifies the resource and statuses (DRAFT and CERTIFIED). This effectively distinguishes it from sibling tools that operate on other resources like 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?

Provides explicit conditions for use (available in DRAFT or CERTIFIED status) and notes irreversibility. While it does not explicitly mention when not to use or name alternatives, the context is clear enough.

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?

Description adds value beyond annotations by specifying return type (download URL) and precondition (CERTIFIED status). Consistent with readOnlyHint and destructiveHint.

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 concise sentences with purpose front-loaded, no 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?

Covers key aspects: purpose, return type, precondition, required params. Lacks detail on URL properties (e.g., expiration, format), but adequate for a simple read tool.

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%, so description must compensate. Only lists parameter names without defining caseFileId or dossierId, adding minimal 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?

States verb 'Returns', resource 'download URL', and scope 'certified dossier PDF'. Differentiates from sibling dossier_package_url by specifying 'certified'.

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?

Explicitly requires dossier_certify (CERTIFIED status), caseFileId, dossierId. Provides clear precondition but doesn't name alternatives or when not to use.

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?

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the DRAFT status requirement, which is useful context beyond the annotations. It does not describe other behavioral traits like irreversibility or error scenarios, but the annotations cover the core safety profile.

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?

The description is two sentences (20 words), front-loading the primary action and then providing the condition and required parameters. No unnecessary words. Every sentence 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?

Given the tool's complexity (4 required parameters, destructive but idempotent, no output schema), the description covers the action, precondition, and lists required params (though inaccurately). It does not explain return value or error states. Adequate for a simple deletion tool but lacks completeness on parameter details.

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 add meaning. It lists required parameters as 'caseFileId, dossierId, evidenceId,' but the schema includes 'dossierEvidenceGroupId' and 'dossierEvidenceId' (not 'evidenceId'). This discrepancy is misleading and does not clarify parameter semantics. The description adds little value and potentially causes confusion.

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 name 'dossier_evidence_delete' and description 'Removes an evidence item from a dossier' clearly state the verb and resource. The status constraint (DRAFT) adds specificity. It does not explicitly distinguish from sibling tools like dossier_evidence_link or dossier_evidence_list, but the core action is clear.

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 description explicitly states the precondition: 'Only available while dossier is in DRAFT status.' It also lists required parameters, providing guidance on invocation. However, it does not mention when not to use it or suggest alternative tools for similar tasks.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which align with the description's 'retrieves'. The description adds no additional behavioral context beyond what annotations provide, but it does not contradict 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?

The description is two sentences, but the second sentence contains inaccuracies (parameter names). It could be more concise and should accurately reflect the schema. Front-loading is acceptable.

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 retrieval tool, the description is somewhat complete in stating the action, but the parameter confusion and lack of explanation about response or edge cases leave gaps. No output schema exists, so the description should compensate, but it does not.

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 only mentions 'caseFileId, dossierId, evidenceId', which are not the exact parameter names from the schema. It fails to explain the meaning of 'dossierEvidenceGroupId' or 'dossierEvidenceId', providing virtually no added semantic value.

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 clearly states the verb 'retrieves' and the resource 'details of a specific evidence item linked to a dossier', making the tool's purpose clear. However, it does not distinguish from sibling tools like 'evidence_get' or 'dossier_evidence_list', which could cause confusion.

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?

No guidance on when to use this tool vs alternatives. The listed required parameters ('caseFileId, dossierId, evidenceId') do not match the actual schema parameters, which are 'dossierEvidenceGroupId', 'dossierId', 'caseFileId', 'dossierEvidenceId'. This is misleading.

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?

Annotations already indicate the tool is not read-only, not destructive, and not idempotent. The description adds that it can be called multiple times for different case files, which aligns with non-idempotency. However, it does not disclose what happens on duplicate calls with the same IDs or any side effects beyond linking.

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?

The description is concise with three sentences, but it misses the required parameter 'caseFileToLinkId', which is a notable omission. It is front-loaded with purpose and prerequisites, but the incomplete parameter coverage detracts from structure.

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?

Given no output schema and moderate complexity (4 required params, no enums), the description should explain return behavior and the relationship between caseFileId and caseFileToLinkId. It lacks any mention of what the tool returns or the state change after linking, making it incomplete for an agent to fully understand the tool's behavior.

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 'ids' as an array of evidence UUIDs, but fails to mention 'caseFileToLinkId', a required parameter. This omission leaves ambiguity about the parameter's role, and no other parameters are explained beyond their names in prerequisites.

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 clearly states the action (linking evidence items to a dossier) and context (from a sealed group). It distinguishes the tool from siblings like dossier_evidence_list or dossier_evidence_delete by mentioning prerequisites and the linking operation. However, it does not explicitly contrast with similar tools.

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 description explicitly lists prerequisites (dossierId from dossier_create, sealed evidence, caseFileId from case_file_create) and notes that the tool can be called multiple times for evidence from different case files, providing clear context on when to use it. It does not specify when not to use it or alternatives, but the prerequisites effectively guide usage.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds that it lists evidence, which is consistent. However, it does not disclose pagination behavior or what happens with empty results. 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.

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

The description is concise with two short sentences, front-loading the purpose and requirements. While it could be more informative without being verbose, it has no redundant content.

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?

Given the tool has 6 parameters, nested objects, and no output schema, the description is insufficient. It does not cover pagination, filtering, sorting, or return value structure. Annotations help with safety but not completeness.

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%, requiring the description to compensate. It only mentions two of the three required parameters (caseFileId, dossierId) but omits dossierEvidenceGroupId and optional parameters like page, order, and filter. No detailed semantics for the nested objects are provided.

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 clearly states 'Lists all evidence items linked to a dossier,' specifying the verb (list), resource (evidence items), and scope (linked to a dossier). This distinguishes it from general evidence list tools and other dossier-specific evidence tools among its siblings.

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 description mentions required parameters (caseFileId and dossierId) but does not provide guidance on when to use this tool versus alternatives like dossier_evidence_list_to_link or evidence_list. No context about prerequisites or exclusion criteria is given.

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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it only returns closed groups not yet linked, which is useful context. 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.

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

The description is a single sentence with a brief 'Requires' note, which is concise but lacks structure. It omits critical information about a required parameter and does not leverage bullet points or sections for clarity.

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?

Given the complexity (6 parameters with nested objects, no output schema), the description is highly incomplete. It does not explain return values, pagination behavior, filtering capabilities, or sorting options, leaving significant gaps for an agent to correctly invoke the tool.

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 only mentions two out of six parameters (caseFileId and dossierId), failing to describe caseFileToLinkId, page, order, filter, or any of their sub-properties. No guidance on how to use pagination, sorting, or filters.

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 clearly states it lists evidence items available to be linked to a dossier, specifically from closed groups not yet linked. This distinguishes it from sibling tools like dossier_evidence_list (likely lists already linked evidence) and dossier_evidence_link. However, it omits the required parameter caseFileToLinkId.

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 description mentions required parameters caseFileId and dossierId but misses caseFileToLinkId. It implies when to use (for closed, unlinked groups) but does not explicitly state when not to use or mention alternative tools.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context about the return content (status, linked evidence, download URLs), which is beyond just the operation. However, it does not disclose any edge cases or potential failures.

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?

The description is exceptionally concise, consisting of two clear sentences. The first sentence front-loads the core purpose and output details, while the second sentence lists required parameters. No wasted words or redundant information.

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?

Given the tool's simplicity (two required string parameters, no output schema, read-only operation), the description is largely complete. It states what is returned and what is required. However, it does not mention any error conditions or that the IDs must exist, which could be inferred but not explicit.

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 input schema has 0% description coverage for parameters, so the description must compensate. It mentions the required parameters (caseFileId and dossierId) but does not explain their meaning, format, or valid values. The parameter names are somewhat self-explanatory, but for an AI agent, more detail would be beneficial.

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 clearly states it retrieves full details of a specific dossier, listing key information (status, linked evidence, download URLs). It distinguishes from sibling tools like dossier_list (list all) and dossier_evidence_list (list evidence). The verb 'Retrieves' and resource 'specific dossier' are specific and 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?

The description explicitly states when to use the tool: when you need full details of a specific dossier, and it requires caseFileId and dossierId. However, it does not explicitly state when not to use it or mention alternatives, though for a simple get operation, the usage is clear enough.

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?

Annotations are sparse (readOnlyHint, destructiveHint false). The description adds value by revealing the combined create+certify behavior, the required prior states, and the polling requirement. It does not disclose potential side effects (e.g., whether the evidence group is modified) or authorization needs. Given the lack of detailed annotations, the description partially compensates but leaves gaps.

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?

The description is extremely concise (three sentences). The first sentence states the core action, the second lists prerequisites, and the third provides an instruction and return behavior. Every sentence earns its place without fluff, and the most important information is front-loaded.

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?

Given the tool complexity (7 params, prerequisites, polling return), the description covers the basic workflow: how to call it and what to expect. However, it lacks details on error conditions (e.g., what if the evidence group is not sealed?), alternative outcomes, and handling of optional parameters. It is minimally adequate but not thorough.

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%. The description only instructs on the `id` parameter ('Generate a UUID v4 string for `id`') and implies caseFileId and evidenceGroupId from prerequisites. The remaining 4 parameters (name, language, modelId, evidenceIds) are not described. This fails to fully compensate for the lack of schema documentation, providing only marginal additional 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 explicitly states 'Creates AND certifies a dossier from a single sealed evidence group in one call (express path).' It clearly identifies the verb (creates and certifies), the resource (dossier), and the specific source (sealed evidence group). This differentiates it from sibling tools like dossier_create and dossier_certify, which are separate steps.

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 description lists prerequisites: evidence_seal (CLOSED), case_file_create → caseFileId, evidence_group_create → evidenceGroupId. It also instructs to generate a UUID v4 for `id` and to poll until CERTIFIED. However, it does not explicitly state when _not_ to use this tool (e.g., when needing to add evidence later or when certification should be deferred). The guidance is strong but lacks exclusions.

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?

Description adds value beyond annotations by noting the tool returns a paginated list and suggesting polling for status changes. Annotations already indicate readOnly, idempotent, non-destructive, which aligns with the list operation. Description provides additional behavioral context (pagination, polling) without contradiction.

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: first states purpose and key inputs/outputs, second gives usage. No fluff or repetition. Efficient and well-structured.

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?

Given the complexity (nested parameters, multiple filters, no output schema), the description is too minimal. It lacks details on pagination structure, sorting, and filtering capabilities, which are core to using the tool effectively. Agent may not know how to leverage optional parameters.

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 input schema has many parameters (page, order, filter with nested fields) but the description only mentions caseFileId as required. With 0% schema description coverage, the description should provide meaning for parameters, but it does not explain filter, order, or pagination options, leaving the agent without needed guidance.

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 clearly states it lists all dossiers in a case file, specifies the required parameter caseFileId, and lists return fields (IDs, names, status, dates). This distinctively differentiates it from sibling tools like dossier_get (single dossier) or dossier_create.

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 description gives a specific use case: 'Use to monitor certification progress — poll until status: CERTIFIED.' This implies when to use (monitoring) and the polling pattern. It does not explicitly exclude other uses or mention alternatives for filtering, but the guidance is clear and practical.

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?

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds that the tool returns a URL and requires certification, but does not disclose potential expiration or error cases.

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 concise sentences front-loading the main purpose, with no redundant information.

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 URL-retrieval tool, the description covers the result and prerequisites. It lacks mention of potential side effects or expiration but is adequate for its complexity.

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 only lists parameter names without explaining their semantics. While the names are suggestive, no extra meaning is provided beyond what the schema conveys.

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 clearly states that the tool returns a download URL for the full dossier package and specifies the content (PDF + evidence files). This distinguishes it from siblings like dossier_document_url or dossier_get.

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 description explicitly requires dossier_certify (CERTIFIED status) as a prerequisite, guiding when to use. However, it does not exclude alternatives or mention when not to use.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe, non-destructive operation. The description adds that it returns an HTML preview URL, which is a key behavioral detail. There is no contradiction, and the description complements the annotations well.

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?

The description is two sentences long, front-loading the main purpose ('Returns an HTML preview URL of a dossier before certification'), and then specifying required inputs. Every sentence is necessary and concise with no wasted words.

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?

The tool is simple, with only two parameters and no output schema or nested objects. The description covers the main behavior but lacks details about the return format (e.g., is it a full URL? How to use it?). Given the absence of an output schema, more specificity about the preview URL would improve completeness.

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%, meaning the description must explain the parameters. However, it only lists 'caseFileId and dossierId' as required, without providing any meaning, format, or role. This adds little value beyond the schema's property names. For a tool with only two parameters, more explanation is expected.

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 explicitly states what the tool does: returns an HTML preview URL of a dossier. It includes the specific precondition 'before certification,' which clearly distinguishes it from sibling tools like dossier_get (which returns dossier data) or dossier_document_url (likely for document URLs). The verb 'Returns' and resource 'HTML preview URL' are specific and 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?

The description provides clear context for when to use the tool: 'before certification.' It also lists the required parameters. However, it does not explicitly mention when not to use it or provide alternatives among siblings. Still, the usage context is well indicated.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it returns 'template IDs and their translations per language', which provides useful return format context beyond annotations. No mention of edge cases 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.

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

Two sentences, zero wasted words, front-loaded with the main purpose, and structured logically. Every sentence adds value.

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?

Partially complete: explains return format (template IDs and translations) and links to dossier_create. However, ignores the 'page' parameter and does not mention that it returns a list, leaving gaps. No output schema to compensate.

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 does not reference the 'page' parameter (pagination). It adds no meaning beyond the schema, failing to compensate for the lack of schema descriptions.

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?

Clearly states it lists dossier templates, uses specific verb 'Lists' and resource, and distinguishes from sibling 'dossier_create' by instructing to use the returned id as dossierTemplateId in that 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?

Explicitly states 'No prerequisites' and provides a direct use case ('Use the returned id as dossierTemplateId in dossier_create'), giving clear context. Does not explicitly mention when not to use, but the context is sufficient.

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?

The description adds useful behavioral context beyond annotations: it is a mutation operation (update) with a prerequisite chain and a status constraint. Annotations only provide readOnlyHint=false, so the description carries the burden. It does not detail side effects, authorization needs, or rollback behavior, but the status constraint is a clear behavioral boundary.

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?

The description is two sentences with no filler. It front-loads the core purpose and immediately follows with critical constraints. Every word earns its place, making it highly efficient.

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?

Despite providing prerequisites and status conditions, the description omits essential information: return value (no output schema defined), error scenarios, parameter specifics, and optionality. For a tool with 11 parameters, this leaves significant gaps in the agent's understanding of how to invoke it correctly.

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?

With 11 parameters and 0% schema description coverage, the description fails to explain any parameter's meaning or role. It uses the generic term 'metadata' without mapping to specific fields (name, modelId, purpose, etc.). This forces the agent to infer parameter semantics from names alone, which is inadequate for such a complex input 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 description clearly states the verb 'updates' and the resource 'metadata of an existing dossier', distinguishing it from sibling tools like dossier_create, dossier_certify, and dossier_delete. It also specifies prerequisites (dossier_create → dossierId, caseFileId) and a status condition (DRAFT status), leaving no ambiguity about what the tool does.

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 description explicitly states when the tool can be used ('only while dossier is in DRAFT status') and lists required prerequisites. However, it does not mention when not to use it or provide direct alternatives, though the context of prerequisites and status guide usage sufficiently.

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?

Annotations indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description confirms mutation ('Updates'). No additional behavioral context is provided, such as side effects, permission requirements beyond prerequisites, or error conditions.

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?

The description is extremely concise with two sentences. The first sentence clearly states the purpose, and the second adds essential prerequisites. No unnecessary words 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?

The tool has no output schema, so the description should cover return values or success indicators. It does not. For a mutation tool, critical context like whether it returns updated entity or just confirmation is missing. Given the simplicity (3 params), more completeness is expected.

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%, so the description should explain parameters. It only mentions caseFileId and dossierId as prerequisites but does not explain their role or the visibility parameter values. The enum values are left entirely to the schema, requiring the agent to infer semantics without additional guidance.

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 clearly states the tool updates visibility of a certified dossier, with verb 'updates' and resource 'visibility'. It distinguishes from siblings by being specific to visibility changes. However, it oversimplifies the possible values (public/private vs. the actual enum: ACCESSIBLE, PENDING_RECALL, RECALLED), which could cause slight confusion.

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 description lists prerequisites ('dossier_certify status, caseFileId, dossierId'), giving some context on when to use. However, it does not explicitly differentiate from other update tools like dossier_update, nor does it provide 'when not to use' or alternative tools.

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?

Annotations indicate idempotentHint=true and non-destructive. The description adds critical behavioral context: idempotency via UUID, hash computation requirement, internal flow returning uploadFileUrl, auto-upload convenience, false error behavior, and retry guidance. No contradictions 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.

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

Description is slightly long but well-organized with clear sections for normal, convenience, external flows and warnings. Each sentence adds value; could be trimmed slightly but remains efficient.

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 does not explicitly state the full response structure (e.g., includes uploadFileUrl on success). While it mentions uploadFileUrl in context, the lack of a formal return value description leaves a minor gap for complete understanding.

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%, but description adds significant meaning: explains id as UUID v4 idempotency key, hash as SHA-256 hex, fileUrl as optional trigger for auto-upload, and custodyType implications. Clarifies relationships between parameters and flows.

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 clearly states the tool registers a new evidence record inside an evidence group. It distinguishes from siblings by detailing the normal, convenience, and external flows, and explicitly references sibling tools like evidence_get, evidence_list, and evidence_seal.

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?

Provides explicit prerequisites (evidence_group_create, case_file_create), alternative flows (INTERNAL vs EXTERNAL), and post-call steps (verify with evidence_get/list before sealing). Warns against reusing IDs after failed INTERNAL creation and advises verification due to potential false error responses.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value by specifying the required IDs from other steps and the return fields (status, hash, tspTimestamp), which goes beyond annotations. No contradictions detected.

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?

The description is two sentences long, front-loaded with the purpose, then prerequisites and return fields. Every sentence adds necessary information with no redundancy or wasted words.

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?

Given the three required parameters with no schema descriptions and no output schema, the description covers prerequisites and return fields. However, it lacks details on error conditions (e.g., non-existent record) and does not explain the status values (COMPLETED, IN_PROCESS, ERROR) beyond listing them.

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 input schema has no descriptions (0% coverage), but the description maps each parameter to the output of other creation tools (e.g., id comes from evidence_create). This adds meaning beyond schema names, but it does not explain the parameter types or accepted values fully.

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 clearly states 'Retrieves a specific evidence record', which is a specific verb+resource. It distinguishes from sibling tools like evidence_list (list multiple) and evidence_create (create), making the purpose 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?

The description explicitly lists required prior creations (evidence_create, evidence_group_create, case_file_create) and return status fields, providing clear context on when to use this tool. However, it does not explicitly mention when not to use it or suggest alternatives, which would improve clarity.

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?

The description adds behavioral details beyond annotations: requiring UUID generation, specific evidenceType values, returning evidenceGroupId, and noting that a group can hold multiple records. Annotations are readOnlyHint=false, consistent with a create operation. 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.

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

Four concise sentences, each adding value: purpose, prerequisite, specific instructions, and behavior. No unnecessary words, well-structured.

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 create tool with no output schema and 6 parameters, the description covers core functionality and key parameters. It omits the attestation and description fields but provides enough for basic usage. Missing some detail for optional fields.

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%, so description must compensate. It explains id (generate UUID), evidenceType (enum values), caseFileId (from case_file_create), but omits description and attestation fields. Partial coverage leaves some parameters unexplained for a 6-param tool.

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 explicitly states the action ('Creates an evidence group') and the resource ('inside a case file'), with specific requirements and return value. It clearly distinguishes from sibling tools like evidence_create by explaining that this creates a group for multiple evidence records.

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 description provides a prerequisite ('Requires: case_file_create → caseFileId') and explains the tool's role as a container for multiple evidence records. It does not explicitly mention when not to use or list alternatives, but the context is clear.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe read operation. The description adds that it returns statuses and requires caseFileId, but does not disclose pagination behavior or that filtering is available, which is a gap given the schema has page, order, and filter parameters.

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?

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It is concise without verbosity.

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?

Given the tool has nested parameters and no output schema, the description is incomplete. It does not mention pagination, filtering, or ordering capabilities, so the agent may not use these features correctly. The lack of output schema also means the agent has no information about the response structure.

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 only adds meaning for the required 'caseFileId' parameter. It does not explain the optional nested parameters (page, order, filter) or their formats, leaving the agent without guidance on how to use pagination, sorting, or filtering effectively.

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 clearly states the tool lists all evidence groups in a case file with their status (OPEN, CLOSING, CLOSED). It distinguishes from siblings like evidence_list (which lists evidence items) and evidence_group_create (which creates groups), ensuring the agent selects the correct tool for listing groups.

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 description specifies when to use the tool: 'to find an existing group or check which groups are ready for sealing.' It also mentions the required parameter 'caseFileId.' However, it does not explicitly state when not to use it or mention alternatives like evidence_group_get (which doesn't exist in 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no new behavioral context beyond stating it lists records. No mention of pagination behavior, error handling, 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.

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

Two sentences covering purpose, requirements, and return format with no fluff. Could be slightly more structured but is efficient and front-loaded.

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?

Given the tool's complexity (5 parameters with nested objects, no output schema), the description misses pagination and filtering guidance. Required params are covered, but optional behavior is not explained, leaving the agent underinformed.

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%, so description must compensate. It explains required params (caseFileId, evidenceGroupId) and return fields, but ignores optional params (page, order, filter) with nested sub-params, leaving them 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?

The description clearly states it lists all evidence records in a specific evidence group, with required parameters and return fields. This distinguishes it from sibling tools like evidence_get (single record) and evidence_create.

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 specifies required parameters (caseFileId, evidenceGroupId) but does not explicitly state when to use this tool vs alternatives. The agent can infer usage from 'lists all evidence records' but lacks explicit guidance on when not to use 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?

Annotations indicate destructiveHint true and readOnlyHint false; description adds async behavior details (returns immediately, state transitions OPEN→CLOSING→CLOSED). No contradiction with annotations. Could mention data loss or locking, but sufficient for context.

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 purpose, then behavior, then guidance. No wasted words. Information-dense and well-structured.

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?

Given 13 undocumented parameters and no output schema, the description is incomplete. It lacks details on required inputs, return format, error cases, and the exact meaning of parameters. The polling instruction is helpful but insufficient to fully understand correct usage.

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 has 13 parameters with 0% description coverage. The description does not explain any parameter meanings, required fields (caseFileId, id, evidencesCount), or the purpose of nested attestation object. This is a critical gap.

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 clearly states the tool seals and certifies an evidence group, closes it to new additions, and triggers async timestamping. It distinguishes from sibling tools like evidence_group_create by describing the state transitions and the need to poll before linking to a dossier.

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?

Explicit guidance to poll evidence_group_list until status is CLOSED before linking to a dossier. However, it does not explicitly state when not to use this tool or mention alternatives like manually certifying.

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?

Discloses internal EAD sequence and that it computes hash, registers, and uploads. Adds context beyond annotations (which only show readOnlyHint=false, destructiveHint=false) but could be more explicit about state mutation.

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?

Long but well-structured with front-loaded action, then internal steps, prerequisites, differentiation, and post-usage advice. Each sentence is purposeful; slight verbosity but justified by complexity.

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?

No output schema but description explains the return (uploaded:true). Covers prerequisites, alternatives, failure handling, size limits, and integration with other tools, making it fully actionable.

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% (baseline 3). Description adds mutual exclusivity of filePath and contentBase64, size limits (10 MB for base64, 1 GiB for local files), and explains the tool handles the PUT, providing added value.

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 clearly states it uploads a local file as evidence in one step, computing SHA-256, registering evidence, and uploading to S3. It distinguishes from evidence_create by specifying when to use each.

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?

Explicitly lists required prerequisites (case_file_create, evidence_group_create), differentiates from evidence_create, provides post-usage steps (verify with evidence_get/evidence_list then evidence_seal), and advises on failure handling.

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?

Discloses that it returns immediately and evidence transitions asynchronously to COMPLETED. Annotations already indicate write (readOnlyHint false) and not destructive (destructiveHint false), so description adds the async behavior nuance.

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, no redundancy. Action verb and resource front-loaded. Every sentence adds value (purpose and async behavior).

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?

Adequately covers the async nature and next step (sealing). Lacks mention of prerequisite steps (initiate and upload parts), but as a completion step, the context is reasonably complete. No output schema, but description doesn't need to cover return values.

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 description does not explain parameters. It mentions caseFileId, evidenceGroupId, id in context but does not clarify their roles (e.g., id as upload identifier). Fails to compensate for missing schema descriptions.

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 clearly states it finalizes a multipart evidence upload and registers evidence. It distinguishes from sibling tools like evidence_upload (upload part) and evidence_list (polling). Verb 'finalize' and noun 'multipart evidence upload' are specific.

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?

Provides explicit instruction to poll evidence_list until COMPLETED before sealing. Implies it is used after initiating and uploading parts. Does not explicitly state when not to use, but the sequence is inferred from sibling names.

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?

The description adds no behavioral context beyond the annotations. It does not disclose side effects, permission requirements, or any operational constraints. It defers entirely to external documentation.

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?

The description is a single sentence, but its brevity is due to under-specification rather than efficient communication. It lacks essential details and does not earn 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?

Given the tool's complexity (8 required params, no output schema, no param descriptions), the description is completely inadequate. It provides no context on return values, expected behavior, or how this fits into the upload workflow.

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?

With 0% schema coverage on 8 required parameters, the description must explain parameter meaning. It does not—it simply says 'review API documentation.' No parameter names are elaborated.

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 merely restates the tool name ('Performs the large_evidence_upload_initiate operation') without explaining what initiating a large evidence upload actually accomplishes. It fails to specify the core action or resource involved.

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?

No guidance is given on when to use this tool versus siblings like 'large_evidence_upload_complete' or 'evidence_upload'. The description does not mention prerequisites, workflow context, or alternatives.

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?

The description adds significant behavioral context beyond annotations: it explains idempotency (listing existing certificates first, reusing id), polling behavior, and response conditions (documentUrl when CERTIFIED). This aligns with annotations (idempotentHint true, destructiveHint false) without contradiction.

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?

The description is concise with four focused sentences: primary action, prerequisites, idempotent behavior, and polling instructions. No fluff, each sentence adds value.

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?

Without an output schema, the description partially addresses return values (documentUrl when CERTIFIED) but does not fully describe the output structure. Parameter semantics are incomplete, but behavioral and usage context are well covered.

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 input schema has 0% description coverage, so the description must compensate. It only explains the 'id' parameter (generate UUID v4, reuse on poll). The other four parameters (caseFileId, receiverId, notificationRequestId, language) receive no explanation, leaving significant gaps.

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 clearly states the tool creates or retrieves a PDF certificate for a notification receiver, using specific verbs and the resource 'certificate'. It distinguishes from sibling notification tools like notification_request_send and notification_receiver_add.

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 description explicitly lists prerequisites (notification_request_send, notification_receiver_add) and provides polling guidance when the certificate is in CERTIFYING status. It does not explicitly mention when not to use this tool, but the context is clear.

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 behavioral traits are disclosed beyond the annotations. The description adds no information about side effects, required permissions, or other runtime characteristics.

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?

The description is extremely short but fails to convey any useful information; it is under-specified rather than concise. The structure does not front-load actionable content.

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 5 required parameters and no output schema, the description fails to provide essential context for correct invocation, such as required parameter formats or return values.

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 input schema has 6 parameters with 0% schema description coverage, and the description provides no explanation of parameter meanings, formats, or relationships.

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 tautological: 'Performs the notification_document_add operation.' It merely restates the name without specifying what the operation does, such as adding a document to a notification.

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?

No guidance on when to use this tool versus alternatives like notification_receiver_add or dossier_evidence_link. The description provides no context for appropriate invocation.

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?

Annotations indicate readOnlyHint: false and destructiveHint: false, and the description confirms it is a non-destructive mutation. It adds behavioral detail: the `id` can be a UUID v4 or custom string, and it returns a receiverId to be saved for notification_certificate_get, which is helpful 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.

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

The description is three sentences: action, prerequisites, and additional info on id and return value. It is front-loaded and efficient, with no redundant or irrelevant content.

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?

Given 10 parameters (6 required), no output schema, and 0% schema coverage, the description is incomplete. It explains prerequisites and workflow hints (save receiverId for next tool), but does not cover most parameters or side effects. It provides a basic skeleton but lacks full context for a complex tool.

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% (10 parameters, none described). The description only explains the `id` parameter (UUID or custom string) and mentions prerequisites, but does not clarify other required parameters like firstName, lastName, email, or optional ones like phoneNumber. With such low coverage, the description should provide more parameter guidance.

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 clearly states 'Adds a recipient to a notification request,' identifying the verb and resource. It distinguishes from sibling tools like notification_request_create and notification_document_add by focusing on adding a recipient, though it does not explicitly contrast with them.

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 description provides explicit prerequisites: 'Requires: notification_request_create → notificationRequestId, case_file_create → caseFileId.' This tells the agent when to use this tool (after creating a notification request and case file), but does not give when-not-to-use or alternative tool names.

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?

The description goes well beyond the annotations, detailing requirements (UUID, language en_GB/es_ES), return value (notificationRequestId), and critical constraints: HTML content formatting with allowed tags, and ASCII-only for subject. 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.

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

Every sentence adds value, from the core action to the detailed HTML rules. It is front-loaded with the purpose and prerequisites, and uses clear imperative statements. No unnecessary words.

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?

Given 8 parameters, no output schema, and no nested objects, the description covers the creation workflow, prerequisites, and critical formatting rules. It could mention the optional parameters (type, otpByDefault, sendWaUrlByDefault) but overall is sufficiently complete for an agent.

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?

With 0% schema description coverage, the description compensates by explaining the purpose of key parameters (caseFileId, id, language, content) and their constraints. It does not cover type, otpByDefault, or sendWaUrlByDefault, but the essential ones are well-described.

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 explicitly states 'Creates a certified notification request,' using a specific verb and resource. It clearly distinguishes from sibling tools like notification_request_send, notification_receiver_add, and notification_request_status, which handle different aspects.

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 description provides clear usage context: it requires a caseFileId from case_file_create, and mandates adding at least one receiver before sending. It does not explicitly state when not to use this tool or list alternatives, but the ordering is implicit.

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?

Description adds behavioral context beyond annotations (destructiveHint=true, readOnlyHint=false) by noting immediate return, async delivery, and the need for polling. 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.

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

Two concise sentences that are well-structured and front-loaded. Every word adds value with no redundancy.

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?

Explains async behavior but omits parameter details and does not specify what the return value is (e.g., a request ID or status). Given no output schema, more detail on the immediate response would help completeness.

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?

No parameter descriptions despite 0% schema coverage. The two required parameters (caseFileId, notificationRequestId) are not explained, leaving the agent to infer their purpose from context. This is a significant gap.

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 clearly states it triggers delivery of a certified notification to all recipients, using a specific verb and resource. It distinguishes itself from sibling tools like notification_request_create (which creates the request) and notification_request_status (which checks status).

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?

Explicitly mentions async delivery and advises polling notification_request_status until DELIVERED before retrieving certificates. While it doesn't list when not to use it, the guidance is clear and actionable.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it lists possible status values, advises polling until SENT, and specifies an interdependency with another tool. No contradictions 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.

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

The description is concise (3 sentences), front-loaded with purpose and required parameters. Every sentence adds distinct value: purpose, requirements, return values, polling, and a warning about a sibling tool.

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?

Given no output schema, the description explains return statuses and provides polling and dependency guidance. It is sufficient for correct usage. Slightly more detail on the meaning of each status or the output structure could improve completeness.

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 only names the required parameters ('notificationRequestId, caseFileId') without explaining their purpose or origin. This adds minimal meaning beyond the parameter names in 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 description clearly states the tool 'Checks the delivery status of a certified notification.' The verb 'checks' and resource 'delivery status' are specific, and it distinguishes from sibling tools like notification_certificate_get by explicitly warning not to call that tool while status is in certain states.

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 description explicitly lists required parameters ('Requires: notificationRequestId, caseFileId'), provides polling guidance ('Poll until status is SENT or beyond'), and warns against using an alternative tool ('Do not call notification_certificate_get while status is CREATING, DRAFT, or IN_PROCESS'). This gives clear when-to-use and when-not-to-use context.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds detailed behavioral context: it identifies the caller from the session token, works without email, returns companyId and defaultCaseFileId, and that the id field is the userId UUID. 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.

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

The description is a well-structured paragraph that front-loads the main purpose, then expands on auth flows, field significance, comparison with sibling, and parameter count. Every sentence adds meaningful information without 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?

For a tool with no parameters and no output schema, the description is complete. It explains return fields (id, companyId, defaultCaseFileId), auth flows, usage recommendations, and confirms no parameters. No critical information is missing.

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 are no parameters, and schema coverage is 100%. The description explicitly states 'No parameters' and adds value by explaining what the tool returns without requiring any input, which is helpful for understanding its usage.

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 'Returns the authenticated user's own profile' with a specific verb and resource. It distinguishes itself from sibling tools like session_info by explicitly recommending its use when needing the userId, and it explains that it's the only way to get userId in user-key deployments.

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 description provides clear guidance on when to use this tool: prefer it over session_info for userId, and it's the only way to get userId in user-key deployments. It also mentions that it works on every auth flow, covering use cases.

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?

Adds significant context beyond readOnlyHint and destructiveHint annotations: explains behavior per auth flow, internal API calls (profile_get vs /session-info), and provides a concrete example output.

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?

Single paragraph with efficient sentences covering purpose, usage, alternatives, prerequisites, and example. No wasted words.

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?

Complete for a parameterless tool with good annotations: describes return values, variants, prerequisite, and sibling relationship. No missing information given complexity.

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?

No parameters exist, so description naturally cannot add parameter info. Baseline of 4 applies as schema coverage is 100% and no further elaboration needed.

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?

Clearly states the tool returns session info (userId, type) with specific verbs and resources. Distinguishes from sibling profile_get by highlighting different return scope.

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?

Explicitly tells when to use (to get userId for user-scoped operations) and when not to (if more profile data needed, use profile_get). Also mentions prerequisite of valid session and alternative auth flows.

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?

The description adds behavioral context beyond annotations by detailing credential source and token exchange. Annotations are minimal (e.g., destructiveHint: false), and the description does not contradict them. It could mention session invalidation more explicitly, but 'force a re-login' implies this.

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, no wasted words. Front-loaded with the core purpose, followed by important details. Every sentence adds value.

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?

Completely describes purpose, authentication method, and usage guidance. No output schema needed; tool is self-contained. With minimal annotations, the description adequately covers all necessary context.

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?

Input schema has zero parameters, so schema coverage is 100% and baseline is 4. The description adds no parameter info, which is appropriate since there are none.

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 clearly states 'Authenticate with EAD Enterprise Suite', explaining the authentication mechanism and specific scenarios for use. It distinctively identifies the tool's action and resource, setting it apart from sibling tools.

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?

Explicitly states 'call this only to force a re-login or after a 401', providing clear conditions for use. It also explains that the server manages authentication automatically, reducing ambiguity about when the tool should be invoked.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the critical detail that the tool is asynchronous and requires polling until documentUrl is available, which is not captured in annotations.

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?

The description is three sentences with no wasted words. It front-loads the primary purpose, then lists prerequisites concisely, and ends with return value and async note. Every sentence 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?

Given the three required parameters and no output schema, the description covers purpose, parameter origins, return value, and async behavior. It could mention the format of the certificate or any potential errors, but for a retrieval tool with annotations, this is sufficiently 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 input schema has no parameter descriptions (0% coverage). The description compensates by explaining that each parameter (caseFileId, requestId, documentId) comes from specific previous steps (case_file_create, signature_request_create, signature_request_add_document), providing semantic context missing from 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 description clearly states 'Retrieves the signed document certificate PDF' with a specific verb and resource. It distinguishes itself from siblings like signature_request_get and notification_certificate_get by focusing on the certificate PDF.

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 description lists explicit prerequisites referencing previous steps (activate_signature_request, signature_request_add_document, etc.) and indicates the tool should be used only when the document is fully signed. It also notes async behavior. While it doesn't explicitly state when not to use, the prerequisites serve as usage conditions.

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?

The description correctly indicates a mutation operation (setting coordinates) with no destructive hint contradiction. It adds behavioral context like the coordinate format (page, x, y) and that it applies to PDFs. It does not discuss whether the operation is idempotent or any side effects, but annotations already provide basic hints.

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?

The description is verbose but all sentences contribute essential information: main action, prerequisites, signature types, coordinate format, and timing. It could be slightly trimmed, but it is well-organized and front-loaded.

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?

The description covers inputs and prerequisites well, but lacks information about the return value or error behavior. Since there is no output schema, the description should ideally mention what the tool returns (e.g., success confirmation). This gap reduces completeness for a mutation tool.

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%, but the description adds significant meaning: it explains that coordinates are an array of objects with page (1-based), x (points from left), y (points from bottom), and that the IDs come from prior steps. This compensates for the lack of schema descriptions, though individual parameters are not detailed separately.

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 explicitly states the tool sets the visual position of a signature field on a PDF. It distinguishes the tool by specifying required document type (PDF), signature types (INTERPOSITION and ADVANCED), and the sequential context (before activation). This clearly differentiates from sibling tools like signature_participant_create or activate_signature_request.

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 description clearly defines when to use the tool: after document upload and before activate_signature_request, and as a required step for PDF signatures. It lists the prerequisite IDs and steps. However, it does not explicitly mention when not to use it or provide alternatives, though the context is clear enough.

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?

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds critical behavioral context: returns participant signing status vs. document processing status, and required IDs context.

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?

Concise and front-loaded: states main purpose first, then important caveats and alternatives. Every sentence adds value without redundancy.

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?

No output schema, but description gives high-level output (lists documents with signing status). Covers key use cases and required IDs. Could include pagination behavior or output structure, but core usage is well covered.

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%, but description explains the meaning of required IDs (requestId, caseFileId, documentId) and that documentId returns participant status. However, pagination parameters (page object) are not explained, leaving some gaps.

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 clearly states the tool lists documents with signing status per document, uses specific verbs and resources, and distinguishes from sibling tools like signature_request_get.

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?

Provides explicit when-to-use and when-not-to-use guidance, including alternatives for checking READY_TO_SIGN and post-activation polling for SIGNED status.

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?

Beyond annotations (readOnlyHint=false), the description reveals critical behavior: automatic pre-creation of groups, necessity of using linkToAllDocuments for DocumentSignatory groups, and a specific failure mode (signature_coordinate_set failing). No contradictions 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.

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

The description is dense with important information but somewhat lengthy and mixes general purpose with critical warnings. It is front-loaded with the main action, and each sentence adds value, though structure could be improved with clearer separation of concepts.

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?

Given the tool's complexity (5 parameters, no output schema), the description covers the workflow, type-specific behavior, integration with other tools, and common pitfalls. It provides sufficient context for an AI agent to use the tool correctly.

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?

With 0% schema description coverage, the description partially compensates by explaining type values and documentId requirement for DocumentSignatory. However, it does not clearly explain caseFileId, requestId, or the purpose of the 'id' parameter (whether user-supplied or system-generated), leaving ambiguity.

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 clearly states the tool creates a signing order group for configurable signature requests, and explains the three types (Document, Signatory, DocumentSignatory) with specific use cases. This distinguishes it from related tools like signature_group_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?

Explicitly warns against creating empty groups, explains that the API pre-creates index:1 groups, advises to reuse those for first documents/signatories, and specifies when to call this tool (only for additional groups). References sibling tool signature_group_list and provides workflow guidance.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it returns specific fields and explains the pre-created groups. No contradictions, and the timing note adds value 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.

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

The description consists of two efficient sentences, front-loading the purpose and then providing usage guidance. No redundant information, earning 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?

Despite lacking parameter explanations, the description covers return fields and usage timing. However, it omits mention of pagination or filtering capabilities, which are important for a list tool with nested filter/order objects. Adequate but not fully comprehensive.

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?

With 0% schema description coverage, the description should explain parameters but does not mention any of the 5 parameters (caseFileId, requestId, page, order, filter). The agent must infer from names alone, which is insufficient for complex nested objects like filter.

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 clearly states the verb 'Lists' and the resource 'signing order groups of a CONFIGURABLE signature request'. It also lists specific return fields (id, type, index, documentId), distinguishing it from sibling tools like signature_participant_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?

The description provides explicit timing guidance: 'Call immediately after signature_request_create to retrieve the pre-created index:1 group IDs before adding documents or participants'. This tells the agent when to use the tool and what prerequisite steps are needed, though it does not mention when not to use it or contrast with alternative tools like signature_group_create.

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?

Disclosures beyond annotations: state requirement (DRAFT), role-specific mandatory conditions, WhatsApp limitations, return value (signatoryId), and constraints for VALIDATOR role. 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.

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

Description is a single paragraph with about 10 sentences, efficiently conveying complex rules. Could be improved with bullet points for readability, but every sentence adds necessary context and no redundant information.

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?

Given the tool's complexity (11 parameters, no output schema), the description covers prerequisites, role-specific rules, WhatsApp delivery, return value, and links to sibling tools. No output schema is provided, but the description clarifies the return, making it 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%, but the description adds meaning for key parameters: role enum values, phonePrefix/phoneNumber context for signature types, and restrictions on groupId/linkToAllDocuments for VALIDATOR. Other parameters (email, firstName, etc.) are standard and self-explanatory. Partial compensation for low schema coverage.

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 clearly states the tool 'Adds a participant (signatory, observer, or validator) to a DRAFT signature request,' identifying the specific verb and resource. It distinguishes from siblings like signature_participant_list and assign_validator_to_signatory by focusing on creation and linking to related tools.

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?

Explicitly states when to use (DRAFT requests only), lists required prior steps (signature_request_add_document, etc.), explains role-specific requirements (ADVANCED mandatory phone, INTERPOSITION optional phone, WhatsApp delivery details), and provides clear exclusion (do not include groupId/linkToAllDocuments for VALIDATOR role, use assign_validator_to_signatory instead).

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?

Annotations already indicate read-only and idempotent behavior. The description adds return fields and prerequisites, but omits pagination behavior despite page parameter in schema. Minor omission, but overall good.

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 concise sentences: first states purpose, second provides prerequisites and return info. No fluff, front-loaded.

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?

Returns info is described (roles, contact details, signing status), and required inputs are explained. Missing pagination behavior and documentId purpose, but for a list tool with schema showing these, it's fairly 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 description coverage is 0%. The description explains requestId and caseFileId as IDs from previous steps, but does not describe page (nested object) or documentId. Partially compensates for the schema gap.

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 clearly states it lists participants of a signature request, using specific verb and resource. It distinguishes from sibling tools like signature_participant_create (create) and signature_request_get (get request), and lists return fields.

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 explicitly mentions required inputs (requestId and caseFileId) and their origin from previous creation steps, giving clear context. Does not mention when not to use or alternatives, but is adequate for a list tool.

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?

Description goes well beyond annotations by detailing the two modes (auto-upload vs manual PUT), required hash computation, groupId type restrictions, and error condition. No contradiction with annotations (readOnlyHint=false, idempotentHint=true).

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?

Description is moderately long but well-structured. It starts with core purpose, lists prerequisites, explains two workflows, and provides caution about groupId. Every sentence adds value, though slightly verbose in places.

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?

Given 10 parameters, no output schema, and many siblings, the description covers prerequisites, workflows, error cases, and timing constraints. It addresses the return value for the manual PUT case but lacks a general return description. Still fairly 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?

With 100% schema coverage, baseline is 3. The description adds value by explaining the purpose of 'id' (becomes documentId), hash requirement, fileUrl automation, and groupId constraint. Some repetition of schema descriptions for 'id' but overall additive.

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 clearly states the tool adds a document to a DRAFT signature request, using specific verbs and resource nouns. It distinguishes from siblings like signature_request_create and signature_document_list by focusing on adding documents to an existing draft.

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 description explicitly states prerequisites (signature_request_create, case_file_create) and when not to use (after activate_signature_request). It explains alternative workflows (fileUrl vs manual PUT). Slight lack of explicit comparison to sibling tools beyond 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?

Beyond annotations (readOnlyHint false, destructiveHint false), the description adds that the request transitions to CANCELLED and cannot be undone. This is useful behavioral context not implied by annotations alone.

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 concise sentences with no fluff. Essential information is front-loaded.

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?

Covers purpose, prerequisite, transition, and irreversibility. Lacks details on error cases or response format, but acceptable for a simple cancellation.

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 only lists requestId and caseFileId without explaining their purpose or how to obtain them. It adds minimal value over 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 description clearly states the action ('cancels') and the resource ('active signature request'). This distinguishes it from sibling tools like signature_request_create or signature_request_get.

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?

Provides explicit prerequisite: the signature request must be in ACTIVE status (via activate_signature_request). However, it does not explicitly exclude cases like already-cancelled requests, which is implied but not stated.

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?

Annotations indicate write operation (readOnlyHint=false) but no further details. Description adds that it creates in DRAFT status, requires UUID v4 id, deadline max 30 days, and returns requestId, going 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.

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

Four sentences, each serving a purpose: main action, prerequisites, parameter details, and post-creation instructions. No redundancy, efficient for agent parsing.

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?

Covers creation workflow, prerequisites, and follow-up actions. Missing detailed explanations of optional parameters and return format beyond 'requestId', but sufficient for context given sibling tools and annotations.

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%, so description compensates for some parameters: 'id' (UUID v4), 'deadline' (ISO 8601 max 30 days), 'caseFileId' (from case_file_create). However, it does not explain 'name', 'language', 'sequence', 'objectiveId', 'dashboardUrl', 'signatureType', or 'closeCondition', leaving gaps.

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 clearly states it creates a signature request in DRAFT status, specifying verb 'creates' and resource 'signature request'. It distinguishes from sibling tools like 'signature_request_cancel' and 'signature_request_add_document' by defining the creation entry point.

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?

Provides explicit prerequisites ('requires case_file_create → caseFileId') and subsequent steps ('add documents...before activating'), guiding the agent on the correct workflow. However, it does not explicitly state when not to use this tool.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the returned data (status, documents, participants, deadline, history) and prerequisites, but does not contradict annotations. It provides context beyond the structured fields.

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?

The description is highly concise with three short sentences, no fluff, and front-loaded with the core action. Every sentence adds value: first sentence states purpose, second lists prerequisites, third summarizes returns.

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?

Given the tool's simplicity (2 params, no output schema), and strong annotations (readOnlyHint), the description provides adequate context: purpose, prerequisites, and return fields. However, it could optionally mention the response structure or format, but overall is sufficient for straightforward retrieval.

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 input schema has zero description coverage for its two required parameters. The description compensates by explaining that requestId comes from signature_request_create and caseFileId from case_file_create, adding essential context that the schema alone lacks.

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 uses a specific verb 'Retrieves' and resource 'full details of a signature request', clearly stating the tool's functionality. It distinguishes itself by listing returned elements (status, documents, participants, etc.) and implying its use for checking process state, which differentiates it from sibling tools like signature_request_cancel or signature_request_create.

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