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 are neutral (readOnlyHint=false, destructiveHint=false) and the description adds useful behavioral context: it's a creation step requiring closed evidence groups and returns dossierId. It does not contradict annotations, and the added workflow details enhance transparency 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?

The description is three sentences, around 80 words, front-loaded with purpose followed by prerequisites and action steps. Every sentence adds value with no redundancy or fluff.

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

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

For a tool with 11 parameters, no output schema, and nested objects, the description provides a clear workflow but lacks documentation for most parameters. It integrates well with sibling tools and explains prerequisites and subsequent steps, but parameter semantics are insufficient for complete 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?

With 0% schema description coverage, the description only adds meaning for two out of 11 parameters: 'Generate a UUID v4 string for `id`' and implicit mention of caseFileId. Other parameters like name, language, validityFrom, validityTo, modelId, purpose, accessToken, filledFields, and dossierTemplateId are left undocumented. This insufficiently compensates 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?

The description clearly states that the tool creates a dossier to aggregate certified evidence groups into a tamper-evident PDF. This specific verb and resource, along with the purpose, effectively distinguishes it from sibling tools like dossier_preview, dossier_update, 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 explicit prerequisites (case_file_create → caseFileId, evidence groups must be in CLOSED status), instructions for generating a UUID for `id`, and subsequent steps (link with dossier_evidence_link, then certify with dossier_certify). This clearly guides when and how to use the 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 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 that the tool only works on DRAFT dossiers, which is useful context beyond annotations. It does not disclose additional behavioral traits like reversibility or permissions.

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, consisting of two short sentences. The first sentence states the action and the second adds a condition and parameter list. It is front-loaded but the parameter list is somewhat redundant and slightly inaccurate.

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 destructive tool with no output schema, the description should provide more context about return behavior or success indicators. The parameter mismatch and lack of permissions or error conditions leave the agent underinformed. The DRAFT condition is helpful but insufficient.

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 lists parameters with incorrect names (e.g., 'evidenceId' instead of 'dossiEvidenceId') and omits 'dossiEvidenceGroupId'. This mismatch could mislead an agent about required inputs. The description adds minimal meaningful parameter semantics.

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 'Removes an evidence item from a dossier', which is specific and distinguishes from sibling tools like evidence_create and dossier_delete. However, the parameter names in the description (evidenceId) do not match the schema (dossiEvidenceId), causing minor 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 provides a clear condition: 'Only available while dossier is in DRAFT status'. It does not explicitly discuss when to use this tool versus alternatives, such as evidence_list or dossier_delete, but the condition helps narrow usage. No exclusions are 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety and idempotency. The description adds minimal extra behavioral context beyond stating it's a retrieval operation. While no contradictions exist, the description does not enrich behavioral understanding 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 brief (one sentence plus list) but inaccurate due to parameter omissions. Conciseness is not sacrificed for correctness; the list should match schema names and include all required parameters. The structure is front-loaded but flawed.

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 4 required parameters, no output schema, and no parameter descriptions, the description falls short. It does not explain the role of each parameter or describe the return value. Annotations are rich but do not compensate for lack of parameter and output 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 fully explain parameters. However, it lists only three parameters ('caseFileId, dossierId, evidenceId') with mismatched names (evidenceId vs dossierEvidenceId) while omitting 'dossierEvidenceGroupId' entirely. This is misleading and incomplete, risking invocation errors.

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 ('Retrieves details') and the specific resource ('evidence item linked to a dossier'). It distinguishes from sibling tools like 'evidence_get' (general evidence) and 'dossier_evidence_list' (listing evidence), making its 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 provides no explicit guidance on when to use this tool versus alternatives. It only states requirements but does not explain contexts where this tool is preferred over 'evidence_get' or 'dossier_evidence_list'. No when-not or exclusionary conditions are mentioned.

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 and idempotentHint. The description adds that the tool requires certification status and returns a URL, offering behavioral context beyond annotations. 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?

The description consists of two efficient sentences, front-loaded with the main action, and wastes no 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?

For a simple read tool with good annotations, the description covers the core: what it returns, prerequisite, and required params. No output schema needed. Minor omission of error cases but acceptable.

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 must compensate. It mentions required parameters (caseFileId, dossierId) but gives no details on format or meaning. For two simple parameters, this is adequate but not rich.

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 returns the download URL for the full dossier package including PDF and evidence files. It specifies the verb 'returns', the resource 'download URL for the full dossier package', and distinguishes from siblings like dossier_document_url.

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, providing clear context. It does not explicitly state when not to use or name alternatives, but the context from sibling tools implies differentiation.

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 (readOnlyHint=false) are consistent with the update operation. The description adds the precondition of certification but does not disclose other behavioral details like reversibility 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?

The description is extremely concise: one sentence with just enough information to convey the action and essential prerequisites. 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 the basic action, precondition, and required parameters. However, it lacks explanation of the enum values, expected return value, or any post-conditions, leaving gaps for an AI 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?

The description mentions caseFileId and dossierId but does not explain the enum values for visibility (ACCESSIBLE, PENDING_RECALL, RECALLED) or provide any additional meaning beyond the schema. With 0% schema coverage, this is insufficient.

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 ('Updates the visibility') and the resource ('of a certified dossier'), and the requirement for certification distinguishes it from sibling tools like dossier_update 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 provides clear context (requires certified dossier) and lists required parameters, but does not explicitly mention when not to use or offer 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 convey read-only, idempotent, and non-destructive behavior. The description adds that it lists groups with status, but omits important behaviors like pagination (default page size, offset) and that the result may be paginated rather than 'all' groups. This is adequate but not comprehensive.

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, fitting purpose, usage, and requirements into two sentences. 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?

Given the complexity of the input schema (nested objects for pagination, filtering, ordering) and lack of output schema, the description fails to cover essential details like pagination behavior, filtering options, or response format. It incorrectly implies 'all' groups are returned, ignoring pagination.

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 the required caseFileId parameter. It does not explain the page, order, or filter objects, their structure, or how to use them. For a complex nested schema, this is a critical omission.

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 resource 'evidence groups in a case file' with their status values. It distinguishes from sibling tools like evidence_list (evidence items) and evidence_group_create (creation), 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 provides explicit use cases: 'find an existing group' and 'check which groups are ready for sealing'. It also notes the required caseFileId. However, it does not mention when to avoid using this tool or name alternative tools for specific scenarios, so a higher score is not warranted.

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?

The description adds significant behavioral context beyond annotations: explains async behavior ('triggers async timestamping'), state transitions ('OPEN → CLOSING → CLOSED'), and immediate return. Annotations indicate destructiveHint=true and readOnlyHint=false, which aligns with 'closes the group.' No 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?

Three sentences cover purpose, effect, and post-usage instruction. Every sentence adds value, no waste. Front-loaded with the primary action.

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 high complexity (13 parameters, nested objects, no output schema), the description fails to explain parameter semantics, which is essential. The agent cannot determine what 'id', 'caseFileId', 'evidencesCount', and other fields represent. Purpose and process are clear, but parameter understanding is deficient.

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 provides no explanation of any parameters. For a tool with 13 parameters (3 required), this is a critical omission. The agent receives no guidance on what each parameter means or how to use them.

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 specific verbs 'seal and certify' with a clear resource 'evidence group'. It distinguishes from sibling tools like evidence_group_create (create) and evidence_group_list (list) by focusing on the closing and certification action.

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 workflow context: 'Poll evidence_group_list until status is CLOSED before linking to a dossier.' It implies when to use (to seal) and when not (if evidence still needs to be added). However, it lacks explicit exclusions compared to 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?

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?

Annotations provide minimal behavioral info (readOnlyHint false, destructiveHint false). The description adds critical details: content must be valid HTML with a restricted tag set, subject must avoid special characters, and returns notificationRequestId. It does not cover error cases or rate limits, but is sufficient for a creation tool.

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

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

Description is concise (5 sentences) with no redundancy. Key information is front-loaded: purpose first, then requirements and constraints. The important HTML and character rules are highlighted clearly.

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 and no output schema, the description covers creation workflow, prerequisites, post-conditions, and content/subject restrictions. It mentions the returned notificationRequestId. Lacks explanation of optional parameters and no output schema, but overall guides an agent effectively.

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 caseFileId, id, language, content, and subject in detail, including formatting rules and allowed values. However, it does not describe optional parameters (type, otpByDefault, sendWaUrlByDefault), leaving gaps. Coverage ~62.5%, adding value 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 it creates a certified notification request and specifies required fields (caseFileId, UUID id, language). It distinguishes from sibling tools like notification_receiver_add by noting that receivers must be added separately.

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 (case_file_create → caseFileId), post-conditions (use notification_receiver_add before sending), and constraints on language, content format, and subject characters. This helps the agent understand when and how to use the tool correctly.

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.