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

Description confirms the tool is a creation operation (non-read-only) and that it returns a caseFileId for subsequent calls. Annotations already set readOnlyHint=false, so description adds value by explaining the return behavior and giving specific parameter instructions (UUID generation). 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 4 sentences, each adding distinct value. It is front-loaded with the main purpose, then provides ordering guidance, parameter instructions, and return value. 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?

Given the tool complexity (5 params, no output schema), the description explains the tool's role as a prerequisite for other operations and states the return value (caseFileId). However, it omits details on non-required parameters and does not describe error cases or side effects, which are minor gaps.

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 bears full responsibility for explaining parameters. It covers 'id' (UUID v4 generation) and 'useCaseId' (default value), but does not explain 'name', 'reference', or 'description'. With 5 parameters and 0% schema coverage, this gap leaves the AI agent without necessary semantic information for those parameters.

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 'Creates a new case file' and specifies it as the 'top-level container for all related operations', distinguishing it from siblings by instructing 'Call this first before any other operation'. It provides specific verb and resource identification.

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 call this tool ('first before any other operation') and provides instructions for generating id and default useCaseId. Does not include when-not-to-use scenarios, but 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 and destructiveHint=false, so the description adds value by indicating the verification intent. However, it does not detail what happens if the caseFileId is invalid or specify the return structure, which is a minor gap.

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 unnecessary words. Front-loaded with the core purpose, then usage advice. 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?

With no output schema, the description should hint at what 'details' means. It is adequate for a simple get operation given the annotations, but the lack of any return value description or error states leaves gaps. It covers purpose and usage but not output.

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 schema has 0% description coverage for the only parameter 'caseFileId'. The description only states 'Requires: caseFileId' without adding format, length, or example. Thus it fails to compensate for the 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 the verb 'Retrieves' and resource 'details of a specific case file'. It distinguishes from siblings by mentioning its use for verification before creating evidence groups, dossiers, or notifications, which sets it apart from other retrieval 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 says 'Use to verify a case file exists before creating evidence groups, dossiers, or notifications.' This provides clear context for when to use this tool and implies it is not for listing or other purposes.

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. Description adds that it returns a paginated list with specific fields, which is consistent. 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?

Three concise sentences, no fluff. Front-loaded with the main action and scope. 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 simple purpose, the tool has a complex input schema with nested objects. Description omits details on filtering, ordering, pagination controls. Insufficient for full usage without schema exploration.

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%. Description only explains userId and implies pagination. Does not describe page, order, filter parameters, which are complex nested objects. Incomplete for a tool with many params.

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?

Clear verb 'lists' with specific resource 'case files' and scope 'your GoCertius account'. Differentiates from siblings like case_file_get (single) and case_file_create. Explicitly states returns IDs, names, 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?

States when to use: to list all case files for the account. Provides context for userId (from session_login or session_info). Lacks explicit when-not-to-use or alternatives, but purpose 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 provide minimal info (readOnlyHint=false etc.), but description adds significant behavioral context: asynchronous operation requiring polling, dependencies on prior calls, and constraints like chatMessagesFrom must be after registeredAt. 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?

Description is information-dense and front-loaded but could be better structured (e.g., bullet points). No unnecessary words, but readability could be improved.

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 prerequisites, parameter constraints, and async polling. Missing a brief note about the initial response (e.g., returns a certificate ID to poll), but the polling instruction suffices. No output schema, so description should guide result retrieval, which it does.

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, description compensates by specifying id format (UUID v4), timestamp format (ISO, chatMessagesFrom after registeredAt), and language enum. Provides clear instructions beyond 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 it creates a certificate of a range of messages from a certified chat. It is distinct from sibling tools like chat_certificate_get, which is for polling.

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 (chat_create, caseFileId, chat_get, messages in Telegram channel) and warns when not to use (if registeredAt missing). Also specifies async polling with chat_certificate_get until status CERTIFIED.

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 value by specifying that documentUrl is returned only when status is CERTIFIED, which is behavioral context 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?

Two sentences and an example, front-loaded with purpose. Every sentence provides essential information without redundancy or irrelevant detail.

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 no output schema, the description explains return fields (status, message range, PDF URL) and a conditional behavior (documentUrl only when CERTIFIED). Also includes prerequisites, making the tool's usage 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 100%, so the schema already describes all parameters. The description provides an example call that demonstrates usage, which adds marginal value beyond the 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 uses a specific verb 'retrieves' and clearly identifies the resource as a certified chat certificate, including what it contains (status, message range, PDF URL). It distinguishes from siblings like chat_certificate_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?

Explicitly states the prerequisite that the certificate must have been created with chat_certificate_create, providing clear context for when to use this tool. Does not explicitly mention when not to use, but the context is sufficient for an AI agent.

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 a write operation (readOnlyHint=false) with no destructiveness. The description adds the crucial behavioral detail that the creation is asynchronous: it returns immediately with a 'creating' status and requires polling via chat_get until active. It could also note any idempotency or error states, but overall it's transparent.

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, front-loading the main action, then using an IMPORTANT section for critical details. Every sentence serves a purpose, and the structure allows rapid comprehension without fluff.

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

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

Given the tool's complexity (async creation, specific case file, parameter generation) and lack of output schema, the description covers all essential aspects: how to use, what to expect immediately, and next steps. It is complete enough for an AI agent to successfully invoke the tool without ambiguity.

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

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

With 0% schema description coverage, the description compensates by specifying that 'id' must be a UUID v4, 'service' must be Telegram, and 'caseFileId' must be the personal case file. It covers the required parameters but omits details on optional ones like serviceTitle and serviceDescription, though their names are self-explanatory.

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 certified chat channel for Telegram, using specific verbs and resource identification. It distinguishes itself from sibling tools like chat_get (read) and chat_certificate_create (certificate) by focusing solely on 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 instructs the agent on prerequisites: only use the personal case file found via case_file_list, generate a UUID v4 for id, set service to Telegram, and wait for active status before further calls. It warns against using manually created case files, providing a clear when-not-to-use condition.

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 readOnlyHint, idempotentHint, and non-destructive. The description adds crucial behavioral context: polling until status is active/registered and the significance of registeredAt over createdAt for certificate creation, which goes beyond the 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?

Three sentences, each adding value. No redundant information. Essential details are front-loaded, making it easy to scan.

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 mentions return values (status, participants, registeredAt) and explains the polling workflow. It is sufficiently complete for a retrieval tool, though it could mention if other statuses exist or error handling.

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% (no descriptions in schema). The description explains that caseFileId must be personal and chatId comes from chat_create, adding meaning to the parameters. It does not detail parameter formats but provides contextual 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 clearly states 'Retrieves details of a certified chat,' specifying the action and resource. It distinguishes from sibling tools like chat_create and chat_invitation_url by focusing on retrieval of certified chat details.

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

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

Provides explicit prerequisites: 'Requires: personal caseFileId and chat_create → chatId.' Also gives a usage pattern: 'After chat_create, poll chat_get until status is active/registered and registeredAt is present.' This guides the agent on when and how to use the tool, though it does not mention when not to use it.

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

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

Annotations already indicate read-only, idempotent, and non-destructive. The description adds that tool may fail with 'Chat not found' if called prematurely, and outputs an invitation URL. 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 sentences only: first states purpose and prerequisites, second provides a caution. No redundant phrases; every sentence is essential.

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 tool with two required parameters and no output schema, the description covers purpose, prerequisites, timing constraints, and potential failure mode. Nothing 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?

Schema has 0% description coverage. The description adds meaning by noting chatId comes from chat_create output and caseFileId is personal, but does not elaborate on formats or additional constraints.

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 an invitation URL for a certified chat, specifying the resource (URL) and action (returns). It differentiates from siblings by mentioning prerequisites and timing.

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 says when to use (after chat is registered) and not to use (while status is 'creating'), and mentions prerequisites (chatId, caseFileId). Provides clear guidance on alternatives (wait for chat_get).

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 clearly states that the dossier transitions to CERTIFIED, locks in evidence groups, and generates a tamper-evident PDF. Annotations indicate destructiveHint=true, which the description aligns with via irreversible changes.

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 with clear structure: main action, conditions, alternative, and example. 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 (status change, locking, PDF generation) and no output schema, the description covers prerequisites, state constraints, and alternative, making it fully actionable for an agent.

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

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

Schema coverage is 100% and both parameters are well-described. The description adds a usage example and reiterates the status requirement, providing additional context beyond 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 uses the specific verb 'certifies' and identifies the resource as 'DRAFT dossier'. It distinguishes from the sibling tool 'dossier_group_certify' by explicitly stating the alternative use case.

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 prerequisites (dossier must exist, have evidence groups), required state (DRAFT), and provides an explicit alternative when to use 'dossier_group_certify' 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 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 that the action is irreversible and lists the required parameters, providing context beyond annotations, though it omits details like authentication or error conditions.

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

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

The description is three sentences, each serving a distinct purpose: stating the action, specifying status constraints and irreversibility, and listing required parameters. No extraneous 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?

For a deletion tool with two parameters and no output schema, the description covers the primary behavior and constraints adequately. However, it lacks details on error responses or what happens if the dossier is in an invalid state.

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 lists the required parameter names (caseFileId and dossierId) without explaining their purpose or format, offering minimal added 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 tool deletes a dossier, specifying the applicable statuses (DRAFT and CERTIFIED) and that it is irreversible. This distinguishes it from sibling tools like dossier_create, 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 explicitly states when to use the tool (for draft or certified dossiers) and notes irreversibility, but does not mention alternatives or when not to use it (e.g., for draft dossiers that could be updated 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that the tool returns a download URL and requires certification status, which is useful behavioral context beyond the 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?

One sentence plus a bullet-style requirement list. The core action and prerequisites are front-loaded. Every word 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?

For a simple read tool with 2 required string parameters and no output schema, the description covers what the tool does, prerequisites, and input requirements. No gaps remain.

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 explain the meaning or format of caseFileId or dossierId beyond naming them. For a tool with 2 parameters, this is insufficient semantic help.

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

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

Description explicitly states the tool returns the download URL for the certified dossier PDF, with clear verb and resource. It also lists prerequisites (certation status, required IDs), distinguishing it from siblings like dossier_package_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?

Description provides clear context: the tool should be used after dossier certification. However, it does not explicitly exclude situations where it should not be used or mention alternative tools like dossier_package_url.

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?

The description adds context beyond annotations by specifying the requirement for a DRAFT dossier and the sequential calling pattern. It does not contradict annotations, but could further disclose behavior for non-draft dossiers or duplicate links.

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 plus a concise example front-load the essential information with no extraneous content, achieving high efficiency.

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 workflow linking to dossier_certify and dossier_group_certify, but does not explain the return value or error conditions. Given the tool's simplicity, it is reasonably 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 100%, so baseline is 3. The description adds an example but does not provide additional semantic meaning beyond what the schema already documents for each 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 it links evidence items to a DRAFT dossier, distinguishing it from sibling tools like dossier_group_certify and providing a specific verb-resource combination.

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 instructs to call once per case file, then use dossier_certify to finalize, and advises using dossier_group_certify for single-group dossiers, offering clear when-to-use and when-not-to-use 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it lists items and requires IDs, but fails to mention that it returns paginated results or that filtering is available. No contradictory information, but little added 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?

Description is a single sentence with a separate requirement note; it is reasonably concise but lacks structure. Could front-load key details like pagination or the third required parameter.

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 including nested objects for pagination and filtering, and no output schema, the description is too sparse. It does not explain return values, pagination behavior, or how to use filters. Essential for an AI 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% with no parameter descriptions. Description only mentions two of three required parameters (caseFileId, dossierId) and omits dossierEvidenceGroupId. No information on optional parameters like page, order, filter. This is misleading and 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?

Description clearly states the tool lists evidence items linked to a dossier, with verb 'lists' and resource 'evidence items'. However, it says 'all' while the input schema includes filtering and pagination, implying it may not always return all items. Also mentions only two required parameters, but schema requires three.

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?

Only lists required parameters (caseFileId and dossierId), but omits the third required parameter dossierEvidenceGroupId. No guidance on when to use this tool vs siblings like dossier_evidence_get or evidence_list, nor any exclusions or 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that items are from 'CLOSED groups not yet linked', but does not elaborate on other behavioral traits like pagination, permissions, or error handling. Beyond annotations, it provides minimal additional behavioral context.

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

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

The description is very short (one sentence plus requirement), which is concise, but it omits critical information. Brevity is achieved at the expense of completeness, making it merely adequate.

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 (6 parameters, nested objects, no output schema) and the presence of many sibling tools, the description fails to provide sufficient context. It does not explain pagination, filtering, ordering, or the meaning of caseFileToLinkId, leaving an agent under-informed.

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% with 6 parameters including nested objects. The description only mentions caseFileId and dossierId, ignoring other required and optional parameters like caseFileToLinkId, page, order, and filter. This is insufficient for an agent to understand 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 tool lists evidence items available to be linked to a dossier, specifically from CLOSED groups not yet linked. This is a specific verb+resource combination and distinguishes it from siblings like dossier_evidence_list which lists already linked 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?

The description implicitly defines when to use: when needing to see evidence available for linking. It mentions required parameters (caseFileId, dossierId), offering prerequisites. However, it does not explicitly state when not to use or compare 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: returns 'status, linked evidence, and download URLs' and notes state dependency 'after CERTIFIED'. 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: first states purpose and output, second gives usage guidance and required params. Efficiently front-loaded with essential 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 no output schema, description outlines key return elements (status, linked evidence, download URLs). For a retrieval tool with clear annotations, this is adequate, though structure details are 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?

With 0% schema description coverage, the description must explain parameters. It only names them ('caseFileId and dossierId') without meaning, format, or examples. Insufficient to guide correct invocation.

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?

Clear verb 'Retrieves' and specific resource 'full details of a specific dossier including status, linked evidence, and download URLs'. Distinguishes from sibling tools like dossier_list (list) and evidence_get (get evidence) by specifying 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?

States when to use: 'to check current state or get certificate download URLs after CERTIFIED'. Explicitly lists required parameters. However, lacks direct comparison with alternatives like dossier_preview.

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 discloses key behaviors: returns dossierId immediately with 'CERTIFYING status', requires CLOSED seal, and requires prior steps (caseFileId, evidenceGroupId). Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted; the description adds context beyond what annotations provide.

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 4 sentences, front-loaded with the main action. It is concise and includes critical usage notes. However, parameter descriptions could be structured more clearly (e.g., bulleted list) to improve readability.

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 covers return value ('dossierId immediately with CERTIFYING status') and polling guidance. It explains prerequisites and use case. Missing parameter descriptions and sibling comparisons reduce completeness for a 7-parameter tool, but it covers core behavioral aspects.

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 partially explains 'id' (UUID v4) and mentions caseFileId and evidenceGroupId are from prior steps, but does not describe 'name', 'language', 'modelId', or 'evidenceIds'. This leaves significant gaps for the AI agent.

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 AND certifies a dossier from a single sealed evidence group in one call (express path).' This specific verb+resource combination distinguishes it from siblings like dossier_create or 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 provides explicit usage context: 'Use when you have exactly one sealed evidence group and don't need multi-group aggregation.' It lists prerequisites (e.g., evidence_seal CLOSED status) and suggests polling until CERTIFIED. It does not explicitly name alternative tools for multi-group scenarios, but the guidance 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 provide read-only and idempotent hints. The description adds that it returns a paginated list with specific fields, adding context beyond 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?

Two to three sentences, front-loaded with purpose, no fluff. Every sentence adds value: purpose, use case, requirements, and return 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, the description helpfully lists return fields. However, it lacks explanation of pagination, sorting, and filtering parameters, leaving gaps for a tool with nested objects and many options.

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 mentions caseFileId as required and mentions return fields, but does not explain parameters like page, order, or filter, which are complex and nested.

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 dossiers in a case file with status and metadata, and distinguishes it from siblings like dossier_get (single dossier) by specifying it's for finding dossierId or monitoring progress.

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 says when to use (find dossierId, monitor certification) and requires caseFileId. Does not mention when not to use, but implicit differentiation from dossier_get and other dossier 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 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?

The annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying 'before certification' which is a behavioral constraint not captured in annotations. It does not contradict annotations.

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

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

The description is a single sentence plus a requirements line, both front-loaded and free of unnecessary words. Every word earns its place.

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

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

For a simple read-only preview tool with two required parameters and no output schema, the description covers purpose, requirements, and a key behavioral constraint (before certification). It lacks details on URL format but is otherwise 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 schema has 0% description coverage, and the description only repeats the required parameter names without explaining what caseFileId or dossierId represent. This adds minimal meaning beyond 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 it returns an HTML preview URL of a dossier before certification. The verb 'returns' and specific resource 'HTML preview URL of a dossier' are precise, and the context 'before certification' distinguishes it from siblings like dossier_get, dossier_document_url, and dossier_package_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 specifies the required parameters (caseFileId and dossierId) and the context 'before certification' implies when to use. However, it does not explicitly state when not to use or mention alternatives, so it falls short of a 5.

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 destructiveHint=false, so the tool is safe. The description adds that it returns 'template IDs and their translations per language', providing extra behavioral context 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 extremely concise with only two sentences, each adding valuable information. No unnecessary words or repetition.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the return values and usage. It could mention pagination behavior, but overall it is 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?

The input schema has 0% description coverage, and the description does not explain the 'page' parameter at all. The agent must infer its meaning from the schema structure alone, which is insufficient for proper invocation.

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 available dossier templates' which is a specific verb and resource. It distinguishes from sibling tools like 'dossier_list' which lists dossiers, not templates.

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

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

The description provides clear usage guidance: 'No prerequisites' and tells the agent to use the returned id as 'dossierTemplateId' in 'dossier_create'. It does not explicitly mention when not to use the tool, 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?

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it updates specific metadata and is only available in DRAFT status. However, it doesn't disclose what happens to omitted fields (patch vs. replace), required permissions, or rate limits, leaving some behavioral 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?

Two sentences: first states the action, second gives prerequisites and constraints. Every word is necessary; no fluff. Perfectly concise.

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 11 parameters, a nested object, and no output schema, the description is too brief. It doesn't explain return values, partial update behavior, or error conditions (e.g., if dossier is not in DRAFT). The tool is relatively complex, but the description provides minimal 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?

Schema description coverage is 0%, so the description must compensate. It only names 'name, template fields, expiry' which map to a few of the 11 parameters (e.g., name, filledFields, validityTo). Many parameters like modelId, purpose, language, accessToken, dossierTemplateId are not mentioned, leaving the agent without guidance on their 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?

Description clearly states 'Updates the metadata of an existing dossier' and lists specific fields (name, template fields, expiry). This distinguishes it well from sibling tools like dossier_create (creates new) and dossier_delete (removes).

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?

Prerequisites are given: 'Requires: dossier_create → dossierId, caseFileId' and a status constraint: 'Only available while dossier is in DRAFT status.' This tells the agent when to use the tool, though it doesn't explicitly state when not to use it or mention alternatives like dossier_certify.

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?

Discloses important behavioral traits beyond annotations: the tool returns an uploadFileUrl for INTERNAL custody, describes the manual vs. convenience upload process, warns about potential false errors (EvidenceCreateError), and mandates verification. This adds significant context over the annotations (idempotentHint=true, readOnlyHint=false, destructiveHint=false). 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 long but well-organized, with clear sections for requirements, flows, and warnings. It front-loads the core purpose and prerequisites, then provides detailed flow instructions. While every sentence adds value, it could be slightly more concise by grouping repetitive warnings.

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 (8 parameters, multiple flows, no output schema), the description is remarkably complete. It explains the return value (uploadFileUrl), outlines complete steps for each flow, and addresses edge cases like retry and error handling. Without an output schema, it compensates fully by describing expected behavior and post-call verification.

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%, so the schema already documents each parameter. The description adds value by explaining the purpose of each parameter in the context of different flows (e.g., fileUrl for convenience, custodyType for storage vs. hash-only). It clarifies that id must be a fresh UUID v4 and hash must be computed beforehand, enriching understanding beyond 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 it registers a new evidence record inside an evidence group, distinguishing it from sibling tools like evidence_list, evidence_get, and evidence_seal. It specifies the verb 'Registers' and the resource 'evidence record', 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?

Provides explicit guidelines on when to use each flow (INTERNAL, EXTERNAL, convenience), including prerequisites (evidenceGroupId, caseFileId) and exclusions (do not reuse failed IDs, do not seal before upload). It also mentions verification steps and error handling, offering clear context for agent decision-making.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by specifying that the tool requires IDs from other creation tools, and details the return fields. 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?

The description is two sentences: the first states the purpose, the second covers prerequisites and return information. No wasted words, 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?

With no output schema, the description explains return values (status, hash, tspTimestamp) and the condition 'when certified'. It also explains the required inputs. This is fully adequate for a simple retrieval 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?

The input schema has 3 required parameters with 0% description coverage. The description compensates fully by mapping each parameter to the output of prior tools (evidence_create → evidenceId (id), etc.), clarifying the meaning and origin of each 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 'Retrieves a specific evidence record' which is a specific verb+resource. It distinguishes from sibling tools like evidence_list (list all) and evidence_create (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 tells the agent what IDs are required and where to obtain them (from evidence_create, evidence_group_create, case_file_create). It also describes the return fields, but does not explicitly exclude alternative tools or provide when-not conditions. However, the context of siblings makes usage 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 indicate a mutation (readOnlyHint=false) with no destructive behavior. The description adds behavioral details: it requires a UUID to be generated, returns an evidenceGroupId, and notes that one group can hold multiple evidence records. 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 four sentences long with no unnecessary words. Each sentence adds distinct value: purpose, prerequisite, ID generation, type enumeration, return value, and capacity note. Perfectly concise 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 that this is a creation tool with no output schema, the description adequately explains what is returned (evidenceGroupId) and the group's capacity for multiple records. It is slightly incomplete regarding optional parameters like `attestation`, but overall provides sufficient context for agent invocation.

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 covers `id` (generate UUID), `evidenceType` (list of enums), and `caseFileId` (from previous step). However, it omits details for `name`, `description`, and `attestation` (a nested object). This partial coverage is adequate but not complete.

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 an evidence group inside a case file, using a verb ('Creates') and specific resource ('evidence group'). It distinguishes from sibling tools like evidence_create, which creates individual evidence records rather than groups.

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

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

It specifies a prerequisite (case_file_create → caseFileId) and provides guidance on generating a UUID for `id` and setting `evidenceType` to one of the enumerated values. It does not explicitly mention when not to use this tool or alternatives, 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?

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 indicate readOnly and idempotent behavior. Description adds return content (IDs, titles, status, timestamps) and pagination, 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?

Three concise sentences: purpose, usage guidelines, return info. No wasted words, front-loaded with key 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 the complexity (5 parameters, nested objects, no output schema), the description covers high-level purpose and return fields but omits parameter semantics and pagination details. Adequate but not 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?

Input schema has 0% description coverage and nested objects with many filter fields. Description only mentions required parameters (caseFileId, evidenceGroupId) and paginated list, not explaining page, order, or filter fields. Agent lacks detail to use parameters correctly.

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 evidence records in a group, with explicit use cases: reviewing before sealing or finding a specific evidenceId. Distinguishes from sibling tools like evidence_get 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 two concrete use cases and mentions required parameters. However, it does not explicitly state when not to use or name alternatives like evidence_get for single records.

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?

Description details internal sequence: create INTERNAL evidence, receive presigned URL, PUT file bytes, return uploaded:true. Also mentions file size limits (10 MB base64, 1 GiB local). Annotations set readOnlyHint=false, destructiveHint=false, which are not contradicted. The description adds valuable behavioral context 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 thorough but slightly verbose. It front-loads the main purpose and every sentence adds value. Minor structural improvements could make it more scannable, but it remains effective and not excessively long.

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 6 parameters and no output schema, the description is exceptionally complete. It covers internal workflow, prerequisites, file size limits, failure recovery, and proper usage sequence. No output schema, but description mentions return of 'uploaded:true' and references sibling tools for verification.

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% with parameter descriptions. The description adds critical guidance: 'Provide EXACTLY ONE of filePath or contentBase64', explains filePath is for stdio/local mode, and clarifies the relationship between parameters. This significantly aids correct invocation.

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 uploads a local file as evidence in one step, computing SHA-256, registering the evidence record, and uploading to S3. It distinguishes from sibling tool evidence_create by specifying that evidence_upload is for local files while evidence_create is for manual hashing or public URLs.

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 this tool vs alternatives: 'Use evidence_upload when the file is on the local machine; use evidence_create when you already have the SHA-256 hash, need to inspect/use uploadFileUrl manually, or have a public fileUrl.' Also provides prerequisites (case_file_create and evidence_group_create) and post-success steps.

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 elaborates on idempotency (lists existing certificates and returns existing id), the two statuses (CERTIFIED and CERTIFYING) with corresponding actions, and the inclusion of documentUrl when available. This adds significant context beyond the idempotentHint and destructiveHint 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 yet comprehensive. It starts with the core purpose, then prerequisites, then explains id generation and idempotency, and finally the polling behavior. Every sentence provides necessary information 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 absence of an output schema, the description adequately describes the response behavior (statuses and documentUrl). It covers all essential aspects: prerequisites, parameter usage for 'id', and the idempotent/polling nature. The tool's complexity is well-addressed.

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 adds meaning for the 'id' parameter (generate UUID v4 first time and reuse). For other parameters (caseFileId, notificationRequestId, receiverId, language), the description provides minimal explanation beyond their names. The tool's overall purpose implies their role, but the description could be more explicit.

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 'Creates or retrieves a PDF certificate for a specific notification receiver,' specifying the action (create or retrieve), the output (PDF certificate), and the target (specific notification receiver). It distinguishes this tool from siblings like chat_certificate_get and dossier_certify by focusing on notification certificates.

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 (requires notification_request_send and notification_receiver_add), explains when to use the tool (creating or retrieving a certificate), and provides detailed polling guidance: generate UUID v4 for id first time, reuse on polling, and behavior for CERTIFIED vs CERTIFYING statuses. This covers when to use and how to use 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?

Annotations indicate this is a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no behavioral details beyond what annotations already provide, such as side effects or required permissions. It tells the agent to 'Review the API documentation,' which is unhelpful.

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 (one sentence), but it is under-specified rather than concise. Every sentence should add value; here it adds none. The directive to review API documentation is not helpful for an AI agent.

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 tool (6 parameters, no output schema, many sibling tools), the description is entirely inadequate. It fails to explain the tool's role in the notification workflow or any constraints on parameter 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?

With 0% schema description coverage and no parameter descriptions in the tool description, the agent receives no semantic information about the 6 parameters (including 5 required ones). The description fails to explain what fields like 'hash' or 'caseFileId' represent or how they should be used.

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 only restates the operation name ('Performs the notification_document_add operation'), which is a tautology and provides no actual meaning. The title 'Notification Document Add' adds some context, but the description itself fails to clarify 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?

No guidance is provided on when to use this tool versus sibling tools like notification_request_create or notification_receiver_add. There is no mention of prerequisites, 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?

Annotations indicate readOnlyHint=false, so it's a write operation. Description adds context on id format (UUID v4 or custom string), return value (receiverId), and ordering requirement. However, doesn't mention behavior if adding duplicate receivers 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?

Description is concise with 5 sentences, front-loading the action. Could be more structured but avoids verbosity.

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

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

With 10 parameters, no output schema, and no descriptions in schema, the description partially covers usage (prerequisites, return value, one parameter) but lacks details on optional parameters, validation, and edge cases. Adequate but not 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?

Schema coverage is 0%, but description only adds meaning for 'id' (UUID v4 or custom string) and implies origin of notificationRequestId and caseFileId from other tools. The other 7 parameters (firstName, lastName, email, sendWaUrl, otpRequired, phoneNumber, phonePrefix) are undocumented, leaving large 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 adds a recipient to a notification request, distinguishes from siblings like notification_request_create and notification_request_send by specifying prerequisites and ordering.

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 provides when to use: after notification_request_create and case_file_create, before notification_request_send, and indicates saving returned receiverId for subsequent notification_certificate_get.

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?

Annotations already indicate destructiveHint=true. The description adds the async behavior and the need to poll for status, providing valuable behavioral context beyond what annotations offer. 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?

The description is two sentences, directly to the point, with no unnecessary words. It front-loads the main action and then provides the async behavior details.

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 async trigger tool with no output schema, the description covers the key aspects: what it does, async behavior, and follow-up action. It could mention prerequisites or state constraints, but overall it is reasonably 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% with no parameter descriptions. The description does not explain the parameters caseFileId and notificationRequestId, leaving the agent to infer their meaning from names alone. 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 the action: 'Trigger delivery of a certified notification to all added recipients.' It uses a specific verb and resource, and distinguishes itself from siblings like notification_request_create and notification_request_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?

The description provides explicit context: 'Returns immediately — delivery is async. Poll notification_request_status until status is DELIVERED...' This guides the agent on when to use the tool and what to do after. However, it does not mention prerequisites like the notification request must already be created.

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 readOnly, idempotent, non-destructive. Description adds context: polling behavior, status lifecycle, and cross-tool constraint. 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?

Three sentences covering purpose, requirements, return values, usage pattern, and a constraint. Front-loaded with core action. No redundant information.

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

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

For a simple polling tool with 2 parameters and no output schema, the description fully covers functionality, prerequisites, return values, and correct usage pattern. Nothing critical 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?

Schema has 0% description coverage. The description mentions required parameters by name and states they are required, but adds no additional meaning or format details. Parameter names are self-explanatory, so minimal but adequate.

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 checks delivery status of a certified notification. Specifies required parameters and enumerates possible status values. Distinguishes from sibling notification_certificate_get by providing a usage constraint.

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 parameters (notificationRequestId, caseFileId), describes return values, advises polling pattern until status is SENT or beyond, and warns against calling notification_certificate_get during certain statuses. Provides comprehensive when-to-use and when-not-to-use 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, idempotentHint=true, destructiveHint=false. The description adds value by explaining the auth flow coverage ('works on EVERY auth flow') and the source of identification (session token alone). 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 is several sentences but each sentence adds necessary context: purpose, comparison, field explanations, and auth details. It is front-loaded with the main purpose. Could be slightly more concise but not wasteful.

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 no output schema, the description is complete: it explains the return fields (id as userId, companyId, defaultCaseFileId) and their significance for other operations. This is fully sufficient for an agent to understand the tool's output without additional schema.

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, and schema coverage is 100%. The description explicitly states 'No parameters', which aligns with the schema. Baseline for 0 parameters is 4.

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 authenticated user's own profile. It distinguishes this from session_info by specifying when to use it (to obtain userId) and notes it is the only way on user-key deployments. The purpose is specific and well-differentiated 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?

Explicit guidelines: prefer over session_info when needing userId, only way for user-key deployments, and explains the returned fields (id, companyId, defaultCaseFileId) with their uses. This is comprehensive 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?

Discloses behavioral details beyond annotations: works on both auth flows, resolves via different methods, example output. Aligns with readOnlyHint and idempotentHint.

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?

Front-loaded with core purpose, then provides necessary context. Could be slightly more concise (e.g., streamline auth flow explanation), but still 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?

Complete for a no-parameter, no-output-schema tool: covers return values, usage context, auth flows, prerequisites, and example.

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 schema coverage is 100%. Description adds example call and context but no param-specific details needed. Baseline 4 for zero-param tools.

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

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

Description clearly states it returns session info (userId and type) and explicitly distinguishes from sibling tool profile_get, which is the canonical alternative.

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 (to retrieve userId for user-scoped operations), mentions alternative (profile_get), and specifies prerequisites (valid session).

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 credentials are read from environment variables (MCP_AUTH_USER_KEY or MCP_AUTH_EMAIL+PASSWORD), which is beyond annotations. 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?

Two sentences, well-structured and front-loaded with the purpose. Every sentence 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?

While the description is clear, it does not explicitly mention the return value or outcome (e.g., session token). Given no output schema, adding that 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?

The input schema has no parameters, but the description explains where credentials come from (environment), providing essential semantic context, more than compensating for zero params.

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 identifies the tool as authenticating with GoCertius, specifying the verb 'Authenticate' and the resource. It distinguishes from siblings (e.g., session_info) by focusing on login/re-auth.

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: 'call this only to force a re-login or after a 401.' Also explains that the server manages auth automatically normally, providing clear guidance on alternatives.

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