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 valuable behavioral context: irreversibility and status-specific availability, which goes beyond the annotations without any contradiction.

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

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

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

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

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

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

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

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

The description merely lists the required parameters (caseFileId and dossierId) without adding any semantic meaning beyond what the schema provides. With 0% schema description coverage, the description should compensate but fails to do so.

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

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

The description clearly states the action 'Deletes a dossier' and specifies the resource and statuses (DRAFT and CERTIFIED). This effectively distinguishes it from sibling tools that operate on other resources like evidence.

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

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

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

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

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

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

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

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

Two concise sentences with purpose front-loaded, no fluff.

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

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

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

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

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

Schema coverage is 0%, so description must compensate. Only lists parameter names without defining caseFileId or dossierId, adding minimal meaning.

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

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

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

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

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

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

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that the tool only works on DRAFT dossiers, which is useful context beyond annotations. It does not disclose additional behavioral traits like reversibility or permissions.

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

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

The description is concise, consisting of two short sentences. The first sentence states the action and the second adds a condition and parameter list. It is front-loaded but the parameter list is somewhat redundant and slightly inaccurate.

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

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

For a destructive tool with no output schema, the description should provide more context about return behavior or success indicators. The parameter mismatch and lack of permissions or error conditions leave the agent underinformed. The DRAFT condition is helpful but insufficient.

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

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

Schema description coverage is 0% and the description lists parameters with incorrect names (e.g., 'evidenceId' instead of 'dossiEvidenceId') and omits 'dossiEvidenceGroupId'. This mismatch could mislead an agent about required inputs. The description adds minimal meaningful parameter semantics.

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

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

The description clearly states the action 'Removes an evidence item from a dossier', which is specific and distinguishes from sibling tools like evidence_create and dossier_delete. However, the parameter names in the description (evidenceId) do not match the schema (dossiEvidenceId), causing minor confusion.

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

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

The description provides a clear condition: 'Only available while dossier is in DRAFT status'. It does not explicitly discuss when to use this tool versus alternatives, such as evidence_list or dossier_delete, but the condition helps narrow usage. No exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety and idempotency. The description adds minimal extra behavioral context beyond stating it's a retrieval operation. While no contradictions exist, the description does not enrich behavioral understanding beyond annotations.

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

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

The description is brief (one sentence plus list) but inaccurate due to parameter omissions. Conciseness is not sacrificed for correctness; the list should match schema names and include all required parameters. The structure is front-loaded but flawed.

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

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

With 4 required parameters, no output schema, and no parameter descriptions, the description falls short. It does not explain the role of each parameter or describe the return value. Annotations are rich but do not compensate for lack of parameter and output details.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. However, it lists only three parameters ('caseFileId, dossierId, evidenceId') with mismatched names (evidenceId vs dossierEvidenceId) while omitting 'dossierEvidenceGroupId' entirely. This is misleading and incomplete, risking invocation errors.

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

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

The description clearly states the action ('Retrieves details') and the specific resource ('evidence item linked to a dossier'). It distinguishes from sibling tools like 'evidence_get' (general evidence) and 'dossier_evidence_list' (listing evidence), making its purpose unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only states requirements but does not explain contexts where this tool is preferred over 'evidence_get' or 'dossier_evidence_list'. No when-not or exclusionary conditions are mentioned.

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 0%, requiring the description to compensate. It only mentions two of the three required parameters (caseFileId, dossierId) but omits dossierEvidenceGroupId and optional parameters like page, order, and filter. No detailed semantics for the nested objects are provided.

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

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

The description clearly states 'Lists all evidence items linked to a dossier,' specifying the verb (list), resource (evidence items), and scope (linked to a dossier). This distinguishes it from general evidence list tools and other dossier-specific evidence tools among its siblings.

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

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

The description mentions required parameters (caseFileId and dossierId) but does not provide guidance on when to use this tool versus alternatives like dossier_evidence_list_to_link or evidence_list. No context about prerequisites or exclusion criteria is given.

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

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

Annotations already 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?

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

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

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

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

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

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

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

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

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

Schema description coverage is 0%, meaning the description must explain the parameters. However, it only lists 'caseFileId and dossierId' as required, without providing any meaning, format, or role. This adds little value beyond the schema's property names. For a tool with only two parameters, more explanation is expected.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it returns 'template IDs and their translations per language', which provides useful return format context beyond annotations. No mention of edge cases or side effects.

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

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

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

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

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

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

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

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

Schema description coverage is 0%, and the description does not reference the 'page' parameter (pagination). It adds no meaning beyond the schema, failing to compensate for the lack of schema descriptions.

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

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

Clearly states it lists dossier templates, uses specific verb 'Lists' and resource, and distinguishes from sibling 'dossier_create' by instructing to use the returned id as dossierTemplateId in that tool.

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

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

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

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

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

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 declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value by specifying the required IDs from other steps and the return fields (status, hash, tspTimestamp), which goes beyond annotations. No contradictions detected.

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

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

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

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

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

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

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

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

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

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

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

The description clearly states 'Retrieves a specific evidence record', which is a specific verb+resource. It distinguishes from sibling tools like evidence_list (list multiple) and evidence_create (create), making the purpose unambiguous.

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

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

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

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

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

The description adds behavioral details beyond annotations: requiring UUID generation, specific evidenceType values, returning evidenceGroupId, and noting that a group can hold multiple records. Annotations are readOnlyHint=false, consistent with a create operation. No contradictions.

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

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

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

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

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

For a create tool with no output schema and 6 parameters, the description covers core functionality and key parameters. It omits the attestation and description fields but provides enough for basic usage. Missing some detail for optional fields.

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

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

Schema coverage is 0%, so description must compensate. It explains id (generate UUID), evidenceType (enum values), caseFileId (from case_file_create), but omits description and attestation fields. Partial coverage leaves some parameters unexplained for a 6-param tool.

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

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

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

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

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

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

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

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

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds that it lists groups with status, but omits important behaviors like pagination (default page size, offset) and that the result may be paginated rather than 'all' groups. This is adequate but not comprehensive.

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

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

The description is extremely concise, fitting purpose, usage, and requirements into two sentences. Every sentence adds value without redundancy.

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

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

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

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

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

Schema description coverage is 0% and the description only mentions the required caseFileId parameter. It does not explain the page, order, or filter objects, their structure, or how to use them. For a complex nested schema, this is a critical omission.

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

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

The description clearly states the verb 'lists' and resource 'evidence groups in a case file' with their status values. It distinguishes from sibling tools like evidence_list (evidence items) and evidence_group_create (creation), making the purpose unambiguous.

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

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

The description provides explicit use cases: 'find an existing group' and 'check which groups are ready for sealing'. It also notes the required caseFileId. However, it does not mention when to avoid using this tool or name alternative tools for specific scenarios, so a higher score is not warranted.

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

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

Annotations already 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 adds significant behavioral context beyond annotations: it explains idempotency (listing existing certificates first, reusing id), polling behavior, and response conditions (documentUrl when CERTIFIED). This aligns with annotations (idempotentHint true, destructiveHint false) without contradiction.

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

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

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

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

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

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

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

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

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

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

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

The description clearly states the tool creates or retrieves a PDF certificate for a notification receiver, using specific verbs and the resource 'certificate'. It distinguishes from sibling notification tools like notification_request_send and notification_receiver_add.

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

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

The description explicitly lists prerequisites (notification_request_send, notification_receiver_add) and provides polling guidance when the certificate is in CERTIFYING status. It does not explicitly mention when not to use this tool, but the context is clear.

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

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

No behavioral traits are disclosed beyond the annotations. The description adds no information about side effects, required permissions, or other runtime characteristics.

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

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

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

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

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

With 5 required parameters and no output schema, the description fails to provide essential context for correct invocation, such as required parameter formats or return values.

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

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

The input schema has 6 parameters with 0% schema description coverage, and the description provides no explanation of parameter meanings, formats, or relationships.

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

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

The description is tautological: 'Performs the notification_document_add operation.' It merely restates the name without specifying what the operation does, such as adding a document to a notification.

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

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

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

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

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

Annotations indicate readOnlyHint=false, 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?

Description adds behavioral context beyond annotations (destructiveHint=true, readOnlyHint=false) by noting immediate return, async delivery, and the need for polling. No contradictions.

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

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

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

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

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

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

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

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

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

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

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

The description clearly states it triggers delivery of a certified notification to all recipients, using a specific verb and resource. It distinguishes itself from sibling tools like notification_request_create (which creates the request) and notification_request_status (which checks status).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 0%, so the description must compensate. It only names the required parameters ('notificationRequestId, caseFileId') without explaining their purpose or origin. This adds minimal meaning beyond the parameter names in the schema.

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

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

The description clearly states the tool 'Checks the delivery status of a certified notification.' The verb 'checks' and resource 'delivery status' are specific, and it distinguishes from sibling tools like notification_certificate_get by explicitly warning not to call that tool while status is in certain states.

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

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

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

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

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

Annotations already declare readOnlyHint=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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.