ErzyCall

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

Annotations already declare destructiveHint=true and readOnlyHint=false, covering the destructive nature. The description adds behavioral context by requiring explicit user confirmation, a critical safeguard. It does not detail post-cancel consequences, but the output schema and annotations fill 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?

A single sentence with no filler. The action and its prerequisite are front-loaded, making it easy to scan and understand.

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 cancellation tool with a destructive annotation, an output schema, and schema-level descriptions for two of three parameters, the description captures the essential safety requirement. The missing idempotencyKey details are covered in the schema, so nothing critical is absent.

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 67%; callId has no description, while confirmed and idempotencyKey do. The tool description adds meaning to confirmed by tying it to explicit user confirmation, but provides no additional clarity for callId or idempotencyKey beyond schema. This partially compensates for the coverage 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 states a specific verb 'Cancel' and resource 'call', with a clear precondition ('after the user explicitly confirms the exact call'). It distinguishes this tool from all siblings, as none other performs cancellation; the action is 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 gives an explicit usage precondition: only use after user confirmation of the exact call. It does not mention alternatives, but no sibling offers cancellation, so the guidance is contextually sufficient. It clearly communicates when not to use (without confirmation).

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, destructiveHint=true) indicate this is a write operation with side effects. The description adds useful behavioral context beyond these: the mandatory user confirmation step and the nuance that omitting assistantConfigId selects platform defaults, not the organization's isDefault assistant. This provides meaningful safety and behavior details not present in annotations.

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

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

The description is compact—two sentences—with the primary purpose front-loaded and the critical assistant-config caveat placed second. Every sentence adds meaningful information without redundancy, making it easy for an agent to parse quickly.

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 (10 parameters, nested objects, output schema), the description is thin. It doesn't explain how scheduling works (e.g., when scheduledAt is provided) or the role of idempotencyKey beyond the schema's own note. While the output schema covers return values, the description leaves flow details under-specified for a write operation with destructive annotations.

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

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

Schema coverage is 50%, meaning five parameters (caseId, scheduledAt, firstMessage, variableValues) lack descriptive schema text. The description partially compensates by mentioning 'assistant/case, message, and schedule' but doesn't elaborate on formats or semantics of those parameters. It repeats the assistantConfigId guidance already in the schema, adding limited new value.

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

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

The description clearly states the tool's purpose: 'Create or schedule a call' with explicit resource and action. It also lists the key components (destination, caller number, assistant/case, message, schedule) and distinguishes it from sibling tools like cancel_call by focusing on creation/scheduling.

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

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

The description specifies a key usage condition: 'after explicit user confirmation' of all details. It also warns about the assistant selection behavior when assistantConfigId is omitted. While it doesn't explicitly name alternatives, the context makes it clear when to use this tool (for creating/scheduling calls) and implies that cancel_call is for the opposite action.

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 meaningful behavior beyond the annotations: it tells the agent to require explicit confirmation and to show the user exactly what will be saved. It also discloses a limitation—'Tools cannot be attached here — the user does that in the dashboard.' The read/write hints already indicate a mutation, so the description builds on them with a process-level constraint.

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 succinct sentences with no redundancy: purpose, confirmation workflow, and a key limitation. Each sentence earns its place and the main goal is front-loaded. The description is as short as it can be while still dealing with the needed behavioral 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?

For a 9-parameter tool with a detailed schema and an output schema available, the description covers the spine: purpose, confirmation requirement, and dashboard attachment limitation. Yet the schema has only 22% parameter coverage, so fields like variables, tags, and keyterms aren't explained by either source. An agent could still be uncertain about what to supply for those optional parameters, so the description does not fully close the gap.

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

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

Schema description coverage is low (22%), so the description needs to compensate, and it does help with title, firstMessage, prompt, and confirmed. However, it leaves variables, tags, keyterms, description, and idempotencyKey unsupported by semantic guidance beyond the schema's stripped descriptions. It gives a cartoon of the important parameters but not the full picture.

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 opens with a specific verb+resource ('Create a call case (reusable script)'), so the tool's core purpose is immediately clear. It doesn't explicitly name sibling alternatives, but the parenthetical definition helps distinguish it from create_call, create_contact, and other create-* tools. The statement 'after explicit confirmation' folds behavior into purpose without obscuring it.

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 gives a clear when-to-use workflow: only after showing the user the title, first message, and prompt and getting approval. However, it never compares this tool to create_call or update_case nor explains when not to use it, stopping short of explicit exclusion. It implies the usage context mostly through the confirmation flow.

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=false, so the mutation is known. The description adds the confirmation requirement, which is a behavioral constraint not in the annotations. However, it omits details like idempotency semantics (covered by schema) and any side effects beyond creation.

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

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

The description is a single concise sentence, front-loaded with the action. It is not verbose, but it is so brief that it offers no structural breakdown or detail. While conciseness is a virtue, this borders on under-specification rather than efficient communication.

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, nested objects, an output schema, and a confirmation flow, this description is grossly insufficient. It does not explain the confirmation requirement's mechanics, the idempotency key's role, or any preconditions. An agent would have to rely entirely on the schema, which is incomplete. The description fails to provide the context needed for correct invocation.

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

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

Schema description coverage is only 40%, and the tool description provides zero parameter explanations. It does not compensate for the low coverage; the schema's own descriptions (e.g., for phone, confirmed, idempotencyKey) carry the load, but many parameters like tags, groupIds, customFields remain unexplained. The description adds no semantic value for any parameter.

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

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

The description clearly states the action 'Create a contact' with a specific resource. It adds a meaningful qualifier ('after explicit confirmation') that conveys a prerequisite. However, it does not differentiate this from sibling create tools like create_call or create_case, which also create entities.

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 the requirement of explicit confirmation, implying it should be used only after user consent. But it gives no guidance on when to use this tool versus alternatives (e.g., update_contact for edits, delete_contact for removal) and no context on typical use cases.

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

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

Annotations indicate a write operation (readOnlyHint false) and not destructive. The description adds the behavioral requirement of explicit user confirmation and the need to present details before creation. This goes beyond annotations and is consistent with them; no contradiction found.

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 (two sentences) and front-loads the primary action and the critical confirmation step. It avoids redundancy, though given the tool's complexity, it could benefit from slightly more structure or bullets, but it is appropriately sized for a short description.

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?

This is a complex creation tool with 13 parameters, nested objects, and an output schema. The description is too sparse: it does not mention what the tool returns, any side effects, prerequisites (e.g., phone number existence), idempotency behavior (though idempotencyKey has a schema description), or relationships to other tools. Given the complexity, the description is incomplete for an agent to call it correctly without additional investigation.

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 only 15% (2 of 13 parameters have descriptions). The description only mentions name, voice, model, and transcriber, providing minimal guidance. It does not compensate for the low coverage by explaining the purpose or constraints of the other nine parameters (e.g., isDefault, description, firstMessage, systemPrompt, flags). The only helpful hint is about omitting transcriber.

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 ('Create an outbound assistant') and the resource, and distinguishes it from update/delete/list by the action verb. It also adds a critical workflow requirement (explicit confirmation). However, it does not explicitly differentiate from creating an inbound assistant, though the name makes that clear.

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

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

The description gives some usage guidance: it mandates showing the user the name, voice, and model for approval, and mentions that omitting transcriber accepts the platform standard. It does not, however, state when to use this tool versus update_outbound_assistant or other alternatives, nor any exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable context beyond that: it stresses 'permanently' deletes, requires explicit user confirmation, and reveals that the operation is refused with a CONFLICT error if queued calls or recurring schedules still reference the case. This goes beyond the annotations and helps the agent anticipate side effects and failure modes.

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

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

Two concise sentences with no wasted words. The core purpose and confirmation requirement are front-loaded, and the conflict-error condition is presented as a second, relevant sentence. Every part earns its place.

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

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

For a destructive tool with three required parameters and an output schema, the description covers the essential behavioral aspects: permanent deletion, user confirmation, and a specific error condition. It does not describe the success response (likely covered by the output schema) or mention idempotencyKey explicitly, but the schema covers that. Given the tool's destructive nature and the presence of annotations, this 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?

The schema covers two of three parameters with descriptions (confirmed and idempotencyKey), leaving caseId undocumented. The description reinforces the confirmation requirement (mapping to confirmed) but does not add syntax or format details for any parameter. With 67% coverage, the description partially compensates but does not fully explain caseId or the idempotencyKey's role 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 opens with 'Permanently delete a case after explicit confirmation,' which uses a specific verb and resource, and clearly distinguishes it from sibling delete tools (delete_contact, delete_outbound_assistant) by naming the resource type. It also adds permanent-deletion semantics that set it apart from update_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 explicitly states a prerequisite ('after explicit confirmation') and instructs the agent to 'Name the case to the user and get their approval first,' which is a clear when-to-use condition. It also discloses a failure scenario (CONFLICT error) that guides decision-making. It does not explicitly mention when not to use or name alternatives, but the confirmation requirement and error condition provide strong practical 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?

The description adds the confirmation requirement, which is not in the annotations. Annotations already declare destructiveHint: true, so the destructive nature is covered. However, it does not mention permanence, side effects, or any additional behavioral details beyond the confirmation.

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?

A single sentence with no wasted words. The action and the critical condition 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?

The description covers the core action and confirmation, but lacks mention of irreversibility, return values, or error behavior. The output schema and annotations partially compensate, but for a destructive operation, stating that deletion is permanent would be valuable.

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 does not explain any parameters. The schema already provides descriptions for confirmed and idempotencyKey, and contactId is a common identifier with no description. With 67% schema coverage, the baseline is 3, and the description adds no extra parameter meaning.

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

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

The description clearly states the verb 'Delete' and the resource 'contact', and adds the condition 'after explicit confirmation' which distinguishes it from other delete tools like delete_case. It is 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?

No guidance on when to use this tool versus alternatives such as update_contact or other delete operations. It does not mention prerequisites, exclusions, or scenarios where this should be avoided.

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

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

The description goes beyond the annotations by specifying the confirmation workflow and the CONFLICT error scenario. It aligns with destructiveHint and adds actionable context that the agent must obtain user approval before invocation, which is not conveyed by annotations alone.

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

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

The description is two sentences with no filler. The primary action and condition are front-loaded, and the error condition is stated clearly in the second sentence. Every word contributes to the agent's understanding.

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 presence of an output schema and annotations, the description covers the essential behavioral aspects: deletion, confirmation, and dependency conflicts. It does not describe success responses, but those are likely in the output schema. The dependencies (queued calls, recurring schedules, AutoFollow campaigns) are explicitly listed, making it 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?

With 67% schema coverage, the description adds value by elaborating on the 'confirmed' parameter through the instruction to name the assistant and get approval. It does not add detail for 'assistantId' or 'idempotencyKey' beyond the schema, but the schema already covers idempotencyKey well, and assistantId is 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 a specific verb ('delete'), resource ('outbound assistant'), and a critical qualifier ('permanently'). It distinguishes the operation from sibling update/create/list tools by focusing on the deletion action and the requirement for explicit confirmation.

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 provides clear prerequisites: the assistant must be named to the user and approved before calling. It also describes a failure condition (CONFLICT when dependencies exist). Though it does not explicitly mention alternatives, there is no other delete tool for outbound assistants, so the usage context is sufficiently 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 cover only read-only and non-destructive hints. The description adds substantial behavioral detail: the required permission (whatsapp_recordings:read), the need to reauthorize to refresh, the retention cap, the presence of urlExpiresAt for expiration, and the exclusion of Maya calls. These go well beyond the structured fields.

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

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

Four short sentences, each carrying unique information: primary action, permission, refresh/expiration behavior, and scope exclusion. The main purpose is front-loaded, and there is no redundant or filler text.

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 a single-parameter, read-only tool with an output schema, the description adequately covers purpose, permissions, retention, expiration, and scope. The only notable gap is the lack of explicit guidance on how to obtain or interpret callId, which is not explained despite the 0% schema coverage.

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 for the undocumented callId parameter. It does not explain what callId refers to, where to obtain it, or how it relates to the recording. The description merely implies the parameter through the tool's purpose, leaving the agent to infer its meaning.

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

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

The description states a specific verb ('Request') and resource ('private WhatsApp recording playback/download URL'), clearly distinguishing it from sibling tools like get_whatsapp_call_transcript or download_whatsapp_document. The explicit 'Does not grant access to Maya calls' further narrows its scope against another call system.

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 provides clear context: the tool returns a private URL, requires specific permission, has retention/expiration behavior, and is explicitly not for Maya calls. However, it does not name alternative sibling tools (e.g., use get_whatsapp_call for metadata), so it stops short of full alternative guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the link expires after 60 seconds and a new one must be requested. This is beyond what annotations provide. It does not mention authentication requirements or rate limits, but for a read-only operation with these annotations, the disclosure is adequate.

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

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

The description is two sentences with no redundancy. The primary purpose is front-loaded, and the expiry note is concise and actionable. Every word earns its place, making it highly efficient for an agent to parse.

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 a single parameter, an output schema present, and read-only annotations, the description covers the essential behavior (link retrieval and expiry) and usage context (source of message). Nothing critical is missing for an agent to invoke it correctly. The output schema likely describes the return format, so no need to duplicate that here.

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. The description implies that messageId is the ID of the WhatsApp document message returned by get_whatsapp_conversation, but it does not explicitly define the parameter or explain its format. While the connection is inferable, the description does not directly elaborate on messageId, leaving some ambiguity. This is a moderate gap given 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 the action (get a secure download link), the resource (WhatsApp document message), and the source (returned by get_whatsapp_conversation). This unambiguously differentiates it from other tools like send_whatsapp_message or get_whatsapp_conversation itself. The verb-resource pairing is 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 specifies that this tool is for document messages returned by get_whatsapp_conversation, giving clear context on when to use it. It also provides practical guidance on handling link expiry ('request a new one if it expires'). However, it does not explicitly mention when not to use it, but since no alternative download tool exists among siblings, this is acceptable.

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?

With annotations already indicating readOnlyHint=true and destructiveHint=false, the description adds useful behavioral context by revealing the exact data returned (transcript, config snapshot, timestamps) and timestamp format. It does not contradict annotations and provides more behavior than just declaring it a read operation.

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

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

One sentence delivers the action, the param source, and the important return fields. Everything earns its place and key info is front-loaded.

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

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

With a single param, an existing output schema, and annotations covering safety, the description is nearly complete. It lacks explicit error behavior, but this is low-friction for a getter and the provided context plus schema are enough for correct invocation.

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

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

The schema only defines callId as a string with no description, and schema description coverage is 0%. The description compensates by specifying that callId is 'an ID returned by list_calls', giving the param provenance and expected form beyond the raw 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 states a specific verb and resource ('Get one call'), names the direct source for the ID (list_calls), and lists the distinctive returned data (transcript, frozen assistantConfigSnapshot, ISO 8601 timestamps). This clearly distinguishes it from sibling tools like list_calls and other get_* 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 gives clear context by tying the callId to 'ID returned by list_calls', implying a workflow. It does not explicitly say when not to use it or contrast it with list_calls, so it lacks explicit exclusions, but a reader understands the intended usage.

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

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

Annotations already handle the read-only, non-destructive, and closed-world behavior, so the burden on the description is lower. The description adds a minor behavioral detail about where the ID comes from, but it offers no extra visibility into errors, permissions, or response shape. The output schema covers the rest, making this acceptable.

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

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

One sentence containing only essential information: the verb, resource, and parameter source. No filler, no repeated schema, and the content is front-loaded and scannable.

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 a simple get-by-ID with an output schema, one documented parameter, and read-only annotations. The description plus structured fields cover what an agent needs to choose and invoke it correctly.

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

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

Schema coverage is 0%, so the description must compensate for the caseId parameter. It helps by stating that caseId is an ID from list_cases, providing source and semantic value beyond its simple string type. This works well for a single required parameter.

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

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

Uses a precise verb and resource: 'Get one case by an ID returned by list_cases.' It clearly distinguishes this from list_cases (single vs. many) and from create_case/update_case/delete_case. An agent can immediately understand the tool's function.

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 by linking to list_cases as the source of the required ID, so an agent understands when this tool makes sense. It doesn't explicitly state what not to use, but the purpose of the single-case retrieval is well implied by the sibling list_cases tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the constraint that the ID must come from search_contacts or list_contacts, which is useful. However, it does not disclose behavior for invalid or missing IDs, rate limits, or any other operational details. With annotations present, this is acceptable but not rich.

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?

A single, efficient sentence with zero wasted words. It front-loads the action and resource, then immediately clarifies the ID source. Perfectly concise for a simple get-by-ID 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?

The description is sufficient for an agent to call the tool correctly: it states the purpose and the exact provenance of the required parameter. With an output schema present (though not shown) and annotations covering safety, the description covers what is needed. Minor gaps like error handling might be handled by the output schema, so this is complete enough.

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 no description for contactId (0% coverage), so the description carries the burden. It clearly explains that the parameter is an ID returned by specific tools, giving the agent meaningful guidance on what to pass. This compensates well for the schema gap, though it could specify expected format or type beyond string.

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

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

The description states a specific verb ('Get'), a specific resource ('one contact'), and the exact identifying source ('by an ID returned by search_contacts or list_contacts'). This clearly distinguishes it from other getters like get_case or list_contacts, and it is not a tautology.

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 implies the tool is used when you already have an ID from search_contacts or list_contacts, which provides clear context. However, it does not explicitly state when NOT to use it (e.g., when you need to search by criteria) or name alternatives beyond the implied source. It is contextual but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds a small behavioral note (ID must come from list), but doesn't mention error handling, response details, or edge cases. Given the annotations cover the core safety, a 3 is appropriate.

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?

A single, precise sentence with zero waste. The critical piece of information (ID source) is front-loaded, and there's 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?

For a simple get-by-ID operation with an output schema and annotations covering safety, the description is adequate. It tells the agent how to obtain the ID and implies a read operation. Missing details like not-found behavior are likely in the output schema, so this is complete enough.

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 defines assistantId as a string, and the description repeats that it's an ID from the list. No additional format, validation, or semantics are provided. Since the schema is sufficient for this simple parameter, the baseline of 3 applies.

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

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

The description states a specific verb ('Get'), a clear resource ('inbound assistant'), and the method of identification (by ID from list_inbound_assistants). This clearly distinguishes it from list and get_outbound_assistant, leaving no ambiguity about what the tool does.

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

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

It explicitly specifies that the ID must come from list_inbound_assistants, giving a clear usage context. It doesn't explicitly contrast with alternatives like get_outbound_assistant, but the name and sibling list make that obvious. The instruction on ID provenance is a useful guideline.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds context beyond that: it explains that no organization ID is required because the authenticated connection determines it, and it discloses the permission requirement and the recommended action if access is denied. This is useful behavioral context not covered by 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 with a distinct purpose: the first lists what is returned, the second explains the use and the lack of a parameter, and the third covers the permission and alternative tool. There is no redundancy or filler—every sentence earns its place.

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

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

Given that the tool has no parameters and there is an output schema (so return format is documented), the description covers purpose, usage, permission, and distinguishes it from get_usage. Nothing critical for calling this tool correctly is missing, making it complete.

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

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

There are zero parameters, so the schema is vacuous. The description explicitly states that no organization ID is needed and that the connection determines the target, which adds meaning beyond the empty schema. Since the baseline for 0 params is 4 and the description adds clarity, it earns a 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 states a specific verb ('Get') and resource ('the connected ErzyCall organization'), and enumerates the exact fields returned (ID, name, description, contact email/phone, profile timestamps). It also clarifies the tool's role—identifying which organization the connection can access—and explicitly differentiates from get_usage by pointing to it for plan/balance info.

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 provides a clear use case ('Use this to identify which organization this connection can access'), names an alternative for a specific need ('For plan and balance information, use get_usage'), and warns that it requires organization:read permission, with guidance to reconnect and authorize if access is denied. This is explicit when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds value by disclosing that the response includes the full config objects, and warns about the PATCH replacement behavior for the sibling tool, which is relevant context for the agent's workflow. 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 with zero fluff. The first sentence states purpose and scope; the second provides a critical caution about the update workflow. The key information is front-loaded, and every clause earns its place.

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

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

For a simple single-parameter read with an output schema and read-only annotations, this description is complete. It covers purpose, ID provenance, payload expectations, and an important cross-tool warning. Nothing an agent needs to call it correctly is missing.

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

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

The single parameter assistantId is not described in the schema (schema description coverage is 0%). The description compensates by stating it is an ID returned by list_outbound_assistants, giving the agent a precise way to obtain a valid value. This exceeds the schema's bare type declaration.

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 state a specific verb (get), a specific resource (an outbound assistant), and the source of the identifier (returned by list_outbound_assistants). It enumerates the payload contents (full voice, model, and transcriber config), which distinguishes it from list_all (which returns a collection) and update (which mutates).

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 to read this tool before update_outbound_assistant and explains why: voice/model/transcriber are stored as whole objects and a PATCH replaces each one entirely, so an omitted sub-field is dropped. This is clear when-to-use guidance that also routes the agent to the correct companion 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 mark the tool read-only, and the description adds meaningful semantics: totalMins can legitimately differ from deductedMins, period.source defines the window type, and outboundBlockedReason distinguishes exhausted minutes from a missing plan. This helps an agent interpret the response correctly.

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?

Five sentences packed with caveats and field semantics, with the core purpose front-loaded in the first sentence. Every sentence contributes either invocation guidance or interpretation context.

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 zero-parameter read-only tool with an output schema, the description fully covers how to know whether usage is exhausted or missing a plan, how period.source should be interpreted, and why totals differ. Nothing needed to invoke or interpret the tool is missing.

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

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

The input schema has zero parameters, so there is no parameter meaning for the description to add; the 0-parameter baseline applies. No parameter details are present, but none are needed for 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 opens with a precise resource and result set: the organization's current plan, minutes balance, minutes spent, and days left in the billing period. It distinguishes the tool from list_calls by warning not to estimate balance, spend, plan, or renewal from call 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?

It explicitly directs agents to read this before answering anything about balance, spend, plan, or renewal and instructs them to never estimate those values from list_calls. It also gives conditional guidance for reconciled Outreach data, which is more than is strictly required.

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 meaningful behavioral detail beyond the readOnlyHint annotation: it explains that settings contains stored values while effectiveSettings includes runtime defaults, and warns that effectiveSettings must not be copied into unrelated updates. It also tells the agent to use the returned revision as expectedRevision, which is critical for correct update behavior. This goes well 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?

The description is three sentences with no filler. The primary purpose is front-loaded, followed by critical field semantics and permission. Every sentence adds useful information for correctly using the 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?

For a simple read tool with one parameter and an output schema, the description covers what matters: the read-before-edit workflow, revision handling, effectiveSettings caveats, and required permission. The output schema handles return value details, and annotations cover safety, so nothing essential is missing.

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

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

The schema has 0% description coverage for agentId, and the description does not explicitly explain what agentId is or where to obtain it. The name 'agentId' is self-explanatory, but in a 0% coverage situation the description should at least mention that agentId identifies the agent to read, or point to list_whatsapp_agents. It does not compensate for the schema gap.

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

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

The description clearly states a specific action and resource: 'Read one discovered WhatsApp agent before editing.' It distinguishes this from sibling tools like list_whatsapp_agents and update_whatsapp_agent by focusing on reading a single agent in preparation for editing. No ambiguity remains about what the tool does.

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

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

The description provides clear usage context: it should be used before editing, and the returned revision should be passed as expectedRevision. It also mentions the required permission. It does not explicitly name alternatives or exclusions, but the 'before editing' cue strongly implies the intended workflow, so this is clear context without explicit exclusions.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds meaningful context beyond those annotations: it specifies the required whatsapp_calls:read permission and clarifies that the result includes transcript/recording availability without claiming to return the content itself.

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 compact and front-loaded: it states the core purpose, the distinctive return information, and the required permission in two short clauses without any filler.

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 single-ID read with an output schema and annotations available, the description covers the auth requirement and the key distinguishing detail about transcript/recording availability. It could explicitly point to sibling download/transcript tools, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the parameter. It references the call ID but does not define its format, origin, or how it relates to the returned availability. Since there is only one required callId parameter and the verb 'get' makes its role fairly inferable, this is minimally adequate.

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

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

The description names a specific operation (retrieve) on a specific resource (a single internal WhatsApp call) and notes that it returns transcript/recording availability. It is clear enough to be told apart from list_whatsapp_calls and get_whatsapp_call_transcript, though it does not explicitly distinguish itself from get_call.

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 provides a useful usage signal by stating the required permission and implying this is a lightweight read for checking availability. However, it does not explicitly say when to use this tool instead of get_call, get_whatsapp_call_transcript, or download_whatsapp_call_recording, so the guidance is implied rather than direct.

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, and the description adds substantial behavioral context beyond that: default/max limits, byte bounds, concatenation rules, interruption-state preservation, cursor restart behavior, independence of state/sourceComplete from pagination, and handling of missing/disabled/expired/deleted artifacts. This is a model of transparent behavior disclosure.

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

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

Every sentence adds necessary operational detail: purpose first, then auth, then limits, then pagination and edge cases. There is no repetition of the tool name, no filler, and the structure front-loads the most critical selection information before diving into pagination mechanics.

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 paginated read tool with an output schema, the description is complete: it covers auth requirements, pagination semantics, cursor handling, limits, and degenerate artifact states. The output schema already documents return structure, so the description does not need to restate response fields, and nothing necessary for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It adds real value by explaining the limit default (100) and max (500), the need for a call ID, and cursor staleness/restart behavior. It does not name the parameters explicitly, but an agent can map 'call ID', 'max 500 fragments', and 'stale cursor' to callId, limit, and cursor without difficulty.

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 opens with a specific verb and resource: 'Read retained spoken turns for one internal WhatsApp call ID.' This clearly distinguishes it from sibling tools like get_whatsapp_call (metadata) and download_whatsapp_call_recording (audio), so an agent can tell exactly what operation this performs without guessing.

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

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

The description clearly establishes that this tool reads transcript content for a single call and requires ownership/read scope. It does not explicitly name alternative tools or state when not to use it, but the focused 'spoken turns' wording makes the appropriate context unambiguous enough for selection among siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by describing the returned document message fields (filename, content type, size, storage status, download availability) and the conditional follow-up, 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?

The description is three sentences with no redundancy. It front-loads the core purpose, then adds relevant detail about document messages, and ends with a concise actionable instruction. 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?

The tool has an output schema, so the description does not need to enumerate return fields. It covers the essential aspects: retrieving recent messages, document message attributes, and the download condition. The only gap is the unexplained parameter, which is minor given the tool's simplicity and the presence of a 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?

Schema description coverage is 0%, so the description must explain the parameter. It does not mention conversationId at all, leaving its meaning and origin implicit. The single parameter is simple, but the description adds no value beyond the schema's property name, failing to compensate for the missing schema description.

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 retrieves a single WhatsApp conversation and its recent messages, with a specific verb and resource. It also distinguishes from the sibling list_whatsapp_conversations by implying a singular focused retrieval rather than a listing, and adds detail about document message fields.

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

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

The description gives a clear follow-up action for document downloads ('Use download_whatsapp_document...') but does not explicitly contrast when to use this tool versus alternatives like list_whatsapp_conversations. It implies usage for fetching a specific conversation's details, but leaves the selection criteria unstated.

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 safety behavior is covered. The description adds helpful result-field semantics: scheduledAt null for immediate calls and startedAt null until the call starts. However, it does not mention pagination, filtering behavior, or any auth/rate-limit constraints.

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 precisely two sentences: one for purpose, one for output field behavior. Both are valuable and concise; no filler or redundant details add value.

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

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

For a tool with 7 filter parameters and no required fields, the description is sparse. It provides no notion of filter scoping, pagination, default ordering, or result limits. Although an output schema exists, the lack of parameter and usage context leaves the agent to infer heavily.

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 only 14%, so the description must explain the seven parameters. It mentions only output fields, not the meaning of to, from, status, limit, caseId, or contactId. Agents cannot learn which filters are available or how date/time windows work from this description.

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

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

The description states the verb 'List' and the resource 'calls in the connected ErzyCall organization', making the tool's core purpose clear. It does not explicitly differentiate from siblings like get_call, but the list action is implicit enough to recognize.

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 implies usage when a listing of calls is needed, but it does not explicitly state when to use this tool over get_call, search_contacts, or another sibling. No alternatives, prerequisites, or exclusion conditions are mentioned.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the scoping constraint 'available to the connected organization' and hints at the search behavior, which are not in the annotations. No contradiction; it adds modest value beyond the structured data.

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 with no fluff. The purpose is front-loaded, and the usage hint is a natural follow-on. Every word earns its place.

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

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

An output schema exists, so return format is covered. The description covers the core purpose and a workflow. Pagination details (cursor behavior) are in the schema, so not missing. Minor gap: no mention of the org-scoping beyond the phrase, but that is already stated.

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 already documents cursor and search with detailed descriptions, covering 67% of parameters. The description adds intent for the search parameter ('resolve a case by title') but does not address limit or cursor beyond the schema. Since coverage is moderate, the description does not fully compensate but adds some value.

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

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

The description clearly states the tool lists or searches call cases, which is a specific verb+resource. It distinguishes itself from list_calls (calls vs cases) and get_case (single vs collection), and even ties it to a workflow (resolving a case before creating a call).

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 concrete usage scenario: 'Use search to resolve a case by title before creating a call.' This implies when to use the tool, but it does not explicitly contrast with alternatives like get_case for a known case ID. It gives a clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no further behavioral context—no mention of pagination, return format, or any side effects. Since annotations cover the core safety profile, the description's minimal addition is acceptable but not enhancing.

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

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

The description is a single, direct sentence with no filler or redundancy. It is optimally concise and front-loaded with the key action and resource.

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

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

For a simple list tool with no parameters and an existing output schema, the description is largely adequate. It states the operation and resource, and the output schema covers return details. However, it does not clarify whether the listing is exhaustive or if any implicit limits exist, and it lacks differentiation from sibling tools, so a 4 is appropriate.

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 tool has zero parameters, and the schema documents none. According to the calibration, a baseline of 4 applies when there are no parameters, since there is nothing to explain. The description correctly stays silent on 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 states the verb 'List' and the resource 'contact groups', clearly indicating what the tool does and distinguishing it from sibling tools like list_contacts and search_contacts. However, it lacks any scope qualification (e.g., 'all groups' or 'groups matching criteria'), making it slightly less informative than ideal for a simple listing 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or references to sibling tools like list_contacts or search_contacts. An agent has no indication of why to pick this over similar listing tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context such as pagination behavior, default sorting, or that it supports filters via parameters. It adds nothing beyond what annotations already state.

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

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

The description is a single concise sentence with no wasted words, making it efficient. However, it is also under-specified, but for conciseness it earns a 4 since it is appropriately brief and front-loaded with the core purpose.

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 5 optional parameters and a sibling tool 'search_contacts', the description is too sparse. It doesn't mention that it supports filtering or pagination, and it doesn't clarify the difference from search_contacts. The presence of an output schema reduces the need to explain return values, but the description still lacks essential context for correct usage.

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

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

Schema description coverage is only 20% (only the cursor parameter has a description in the schema). The tool description does not describe any of the parameters (tags, limit, search, groupId), so it fails to compensate for the low schema coverage. It adds no meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'List' and the resource 'contacts' within the connected organization, giving a specific action and scope. However, it does not differentiate from the sibling tool 'search_contacts', which also deals with contacts, so it lacks the distinction needed to choose between them.

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

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

The description provides no guidance on when to use this tool over alternatives like search_contacts or list_contact_groups. There are no explicit conditions, exclusions, or context about when this tool is appropriate versus its siblings.

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

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

The annotations already declare this read-only and non-destructive, so the safety profile is known. The description adds no behavioral context beyond that, such as whether it returns all records, pagination behavior, or ordering, so it does not enrich 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?

The description is a single, front-loaded sentence with no filler or redundant wording. For a zero-parameter list tool, five words are appropriately sized and well structured.

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

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

With no parameters, annotations covering the safety profile, and an output schema that can describe the return shape, the minimal description is mostly sufficient. The only gap is that it does not explicitly say it returns all inbound assistants or mention the single-record alternative, but those are easily inferred from the name and sibling tools.

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 tool has zero parameters, so the description cannot reasonably add parameter-level semantics. The baseline for a 0-parameter tool is 4, and no further explanation is needed here.

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 ('list') and a specific resource ('inbound assistants'), making the action and object clear. The 'inbound' qualifier distinguishes it from sibling tool list_outbound_assistants, and 'list' separates it from get_inbound_assistant, though it stops short of stating any scoping or return 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?

Usage is implied by the naming convention and sibling tools: an agent can infer that this lists inbound assistants rather than a single one or outbound ones. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of preferring get_inbound_assistant for a single record.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context beyond the name, such as pagination, ordering, or return format. Since the output schema exists, the return structure is defined elsewhere, but the description does not mention any behavioral nuances.

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

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

The description is a single short sentence that directly conveys the action and resource. It is front-loaded and contains no extraneous information, making it highly concise and easy to parse.

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 list operation with no parameters, the description is sufficient for an agent to invoke the tool correctly. The output schema defines the return structure, so no further detail is required. However, the description does not mention whether the list is complete or if there are any implicit filters, which is a minor gap given its simplicity.

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

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

There are zero parameters, so the schema covers all parameter semantics by default (covered 100%). The description correctly states the operation without needing to elaborate on parameters. A baseline of 4 is appropriate given the absence of 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 states a clear verb ('List') and a specific resource ('outbound assistants'). It is unambiguous and distinct from siblings like 'list_inbound_assistants' by the explicit 'outbound' qualifier. However, it does not elaborate on what constitutes an outbound assistant, which is minor for a listing 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?

The description implies the tool's purpose but provides no explicit guidance on when to use it over alternatives such as 'get_outbound_assistant' for a single assistant or 'list_inbound_assistants' for inbound. There are no exclusions or alternative names mentioned, leaving the agent to infer based on the tool name alone.

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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that only 'connected' caller phone numbers are listed, not any other phone numbers, but it does not disclose pagination, filtering, or response behavior beyond that.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning of the tool, which is appropriate given the zero-parameter schema.

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 simple zero-parameter input, the read-only annotations, and the presence of an output schema, the description is mostly sufficient for an agent to invoke the tool. It is only slightly incomplete because it leaves some ambiguity about what counts as a 'connected caller phone number' and whether any account-level scoping applies.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to explain about parameters. The baseline for zero-parameter tools is 4, and the description does not need to compensate for missing parameter docs.

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 and resource: 'List connected caller phone numbers.' It is distinct enough from sibling list tools (list_calls, list_againsts, list_whatsapp_accounts) by scoping to caller phone numbers, though it does not explicitly differentiate itself from 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?

There is no guidance about when to use this tool versus alternatives. No prerequisites, exclusions, or comparison to sibling tools are provided, so an agent must infer usage from the name alone.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description adds ordering (newest first), the signed semantics of amountMins, and a critical correlation note that providerCallId won't be accepted by get_call and should be matched on apiCallId. These are useful behavioral details not present in 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 a single paragraph that front-loads the purpose, then explains filtering, amountMins, and correlation. It is informative without being verbose, though slightly longer than necessary due to the correlation 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?

Given the presence of an output schema (which covers return values) and the read-only annotations, the description covers key behavioral aspects like ordering, signed amounts, and correlation with other tools. It lacks explicit pagination guidance beyond the cursor (already in schema) but is otherwise complete for a read-only listing 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 only 40%, so the description should compensate. It explains the 'type' filter and mentions cursor validity (though that is already in schema), but does not describe the 'to', 'from', or 'limit' parameters. It adds some meaning but does not fully cover the undocumented 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 the tool lists the organization's balance history newest first, covering call usage, plan renewals, top-ups, coupons, and admin adjustments. It specifies a distinct resource (balance history) and differentiates from sibling list_calls by focusing on usage/balance rows and mentioning correlation with get_call.

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 gives context that this is for balance history and mentions related tools (get_call, list_calls) and warns about providerCallId incompatibility, which implies when to use this vs. those. However, it does not explicitly say 'use this instead of list_calls when you need usage data', but the distinct purpose is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the word 'connected', which implies only accounts that are connected to the system are listed, providing slight additional context. However, it does not describe return format, pagination, or authentication requirements, though these may be covered by the output schema.

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

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

The description is a single, concise sentence that front-loads the verb and resource. There is no unnecessary detail, making it highly efficient.

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

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

For a simple list operation with no parameters and an output schema present, the description is sufficient. It clearly states the action and resource. It could optionally mention that it returns a list, but that is implied and likely in the output 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?

There are no parameters, and the schema coverage is 100% vacuously. The description does not need to explain parameters. Baseline for zero-parameter tools is 4, and the description adds no irrelevant parameter information.

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

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

The description states the verb 'List' and the resource 'connected WhatsApp accounts', which is specific and distinguishes from sibling tools like list_whatsapp_conversations or list_phone_numbers. It clearly indicates what the tool does.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or direct the agent to other list tools for different resources. The agent must infer usage from the resource name alone.

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 establish readOnlyHint=true and destructiveHint=false, and the description adds meaningful context beyond them: it reveals that disabled agents are included, that duplicate names may exist, and that freshly consented whatsapp_agents:read is required. No contradiction with annotations exists.

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, all of which add value: the core purpose, the disambiguation guidance, and the permission requirement. It is front-loaded with the primary action and contains no filler.

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

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

Given that an output schema exists and annotations cover the read-only/non-destructive profile, the description is largely sufficient. It covers authentication, scope, and duplicate-name handling, though it leaves the semantics of limit and integrationId to be inferred from their parameter names.

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 only 33%; only cursor is documented in the schema. The description does not explain limit or integrationId, even though low coverage means the description should compensate. The mention of 'account phone/name and agentId' refers to output attributes, not input 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 uses a specific verb and resource ('List WhatsApp agents') and adds scope ('across connected accounts') plus an important inclusion criterion ('including disabled agents'). It is clearly distinct from siblings like get_whatsapp_agent and update_whatsapp_agent.

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 useful context around target disambiguation and the required consent scope, but it does not explicitly state when to prefer this tool over alternatives such as get_whatsapp_agent or list_whatsapp_accounts. Usage conditions are implied rather than spelled out.

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 builds on this with ordering, independent transcript/recording states, exclusion of bodies/signed URLs, cursor behavior on empty filtered pages, and a permission requirement. 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?

Four crisp sentences, each earning its place: purpose and ordering, a limit usage tip, payload scope, and auth plus pagination. No filler or repetition.

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

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

For a read-only list tool with an output schema, the description covers ordering, scope, authorization, and pagination well. However, given 9 parameters at 0% schema coverage and no enums, the undocumented filter semantics leave an agent guessing, so completeness falls short of excellent.

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 for the 9 optional parameters. It only clarifies 'limit' and 'cursor'; the remaining filters (phone, outcome, integrationId, recordingState, transcriptState, to, from) are left undefined, with no enums or defaults in the schema. This is a significant gap for an agent trying to filter 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?

The description states a specific verb and resource: 'List your organization's WhatsApp call history,' and adds ordering ('newest started first'). It distinguishes itself from sibling download tools by noting it 'never bodies or signed URLs' and from generic list_calls by scoping to WhatsApp.

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 provides actionable usage context: 'Requires whatsapp_calls:read' for authorization, 'Use limit:2 for the latest two' as a common pattern, and 'Continue with the returned cursor, including on empty filtered pages' for pagination. It does not explicitly name alternative tools, but the exclusion of bodies and signed URLs implies recording retrieval should use other tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral detail such as pagination behavior, cursor requirements, or how status filtering affects results. It does not disclose that the tool returns a paginated list or that the cursor must remain consistent.

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

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

The description is a single concise sentence with no filler or redundancy. It is appropriately brief, though it under-specifies for a tool of this complexity. As a concise statement it is acceptable.

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

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

The tool has three optional parameters, pagination via cursor, and a sibling get tool. The description does not mention that it returns a paginated list, that the cursor must be reused only with identical filters, or that status can filter results. Even though an output schema exists, the description lacks operational context needed for correct invocation.

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

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

Schema description coverage is only 33% (only cursor has a description). The tool description provides no explanation of limit, status, or cursor semantics, and does not compensate for the missing parameter documentation. An agent gets no help understanding what these parameters do beyond the bare 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 states a clear verb and resource: 'List WhatsApp conversations.' It is distinct from the sibling get_whatsapp_conversation by name, but the description does not explicitly call out that differentiation. The purpose is understandable, though minimal.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of filtering, pagination, or that get_whatsapp_conversation is for a single conversation. The plural vs singular is only implied by the tool name, not the description.

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 safety profile is covered. The description adds no behavioral context beyond the directive—no mention of what fields are searched, whether matching is fuzzy, or any special limitations.

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

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

The description is a single short sentence with no fluff, which is structurally clean. However, it is under-specified rather than merely concise—it states the action but omits critical details, so it does not earn a higher score.

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?

There is an output schema, so return values are covered, and the annotations handle safety. Yet the description lacks any detail on search behavior, parameter semantics, or differentiation from sibling tools. For a simple two-parameter tool, it still feels incomplete.

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 carries the full burden of explaining 'query' and 'limit'. It does neither, leaving the agent to guess what a query string should contain (name, email, phone?) and how limit affects result ordering or pagination.

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 a search operation on contacts with a verb and resource, making the primary purpose unambiguous. However, it does not distinguish this tool from siblings like list_contacts or get_contact, which reduces its differentiating clarity.

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 provides a clear usage context: 'Search contacts before selecting a contact ID' implies a prerequisite lookup step. This gives the agent a specific scenario, but it does not mention alternatives or when not to use it, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation. The description adds important behavioral context: the tool requires explicit confirmation before sending, and it emphasizes the need for recipient context and exact content. This goes beyond the annotations by warning about the irreversible nature of sending a message. No contradiction with annotations.

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

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

The description is a single sentence that front-loads the action ('Send a WhatsApp text or template') and immediately states the critical precondition. Every word earns its place; no fluff or repetition of schema details.

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

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

The tool has an output schema, so return values are covered. The description covers the key behavioral requirement (confirmation) and the mutating nature. It doesn't mention rate limits or specific error cases, but for a send operation with annotations and schema, the description is sufficiently complete. The confirmation requirement is the most critical context and it's present.

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 67%, with 'confirmed' and 'idempotencyKey' already described in the schema. The description adds meaning by tying the 'confirmed' parameter to the explicit confirmation requirement and by framing the operation as a write that needs idempotency. The 'message' parameter's structure is well-defined in the schema, so the description doesn't need to repeat it. The description adds value 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 states a specific verb and resource ('Send a WhatsApp text or template') and adds a critical precondition ('only after confirming the conversation, recipient context, and exact content'). It distinguishes itself from read/list tools in the sibling set, though it doesn't explicitly name an alternative for sending. Clear enough for an agent to know what the tool does.

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

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

The description gives explicit when-to-use guidance: only after confirming conversation, recipient context, and exact content. This is a strong usage constraint. However, it doesn't mention when not to use it or name alternatives (e.g., no sibling send tool exists, so this is less critical). The guidance is clear but not exhaustive.

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 only declare readOnlyHint=false and destructiveHint=false, so the description adds significant value: it discloses that only sent fields are changed (partial update), that confirmation is mandatory, and that prompt updates are refused with CONFLICT when the case uses a library prompt. No contradiction with annotations.

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

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

Three sentences, each dense with information. The core purpose is front-loaded, followed by usage instructions and conflict handling. No filler or redundancy.

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

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

The description covers the essential workflow (read first, confirm, update), the conflict scenario, and the partial update behavior. Given the tool's complexity (10 params, write operation), this is quite complete. It doesn't mention idempotency key usage or other error cases, but an output schema exists, reducing the need to explain return values.

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

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

Schema coverage is only 20%, so the description compensates by clarifying partial update semantics (only fields sent are changed) and the special behavior of the prompt parameter (CONFLICT with systemPromptId). It also ties the 'confirmed' parameter to the explicit confirmation step. However, it doesn't address other optional parameters like tags, title, or variables beyond what the schema's types imply.

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 'Update' and the resource 'case', and specifies the required workflow of showing proposed changes and confirming. It distinguishes itself from sibling tools like update_contact by targeting 'case' and referencing get_case as a prerequisite.

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

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

The description explicitly instructs to 'Read it with get_case first', clarifying the sequence of operations. It also specifies when to use (after user confirmation) and when not to (when systemPromptId exists, report CONFLICT rather than retrying), which is a clear exclusion.

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 this is not read-only and not destructive, so the safety profile is partially covered. The description adds meaningful behavioral context: the need for an explicit confirmation step before applying changes, which is not encoded in the annotations and is important for an agent to invoke the tool safely.

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

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

The description is a single concise sentence that front-loads the core operation and uses 'after showing... and confirming' to add critical process detail without verbosity. Every phrase 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?

The tool has 11 parameters, nested objects, and a confirmation requirement, but the description does not explain how the confirmation flag should be set or how idempotencyKey is used. The output schema likely covers return values, but the description plus sparse schema coverage leaves gaps around parameter usage and safe invocation for a complex update operation.

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

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

Schema description coverage is only 36%, so the description carries a heavier burden for explaining parameters. It only hints at 'confirmed' through the confirmation workflow but does not explain contactId, idempotencyKey, tags, groupIds, customFields, title, email, notes, or phone semantics. The schema covers some fields, but the description adds little beyond that.

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 ('Update') and resource ('a contact'), and adds a distinctive workflow requirement ('after showing the exact proposed changes and confirming') that distinguishes this tool from create_contact and delete_contact. It leaves no ambiguity about what the tool does.

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

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

The description explicitly establishes the key usage condition: the update should only be performed after proposed changes have been shown to the user and confirmed. However, it does not explicitly state when not to use this tool or name alternatives such as create_contact for new contacts or delete_contact for removals.

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

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

The annotations already indicate this is a non-read-only, non-destructive operation, and the description reinforces that by saying 'Update' and adding the explicit-confirmation gate. It does not contradict the annotations, but it also does not reveal much beyond what the schema and annotations already convey.

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

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

The description is a single, front-loaded sentence with no filler: the verb and object come first, and the important confirmation precondition is included. Every word earns its place.

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

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

The output schema and annotations carry part of the burden, but this is still a mutation tool with three required parameters and two optional updateable fields. The description is minimally adequate for selection, yet it leaves the agent to infer what can actually be updated and what the idempotency/confirmation workflow means for invocation.

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

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

Schema description coverage is only 40%, so the description should help clarify parameters like assistantId, name, and systemPromptId, but it does not mention any of them. The phrase 'after explicit confirmation' aligns with the `confirmed` parameter, but that is already described in the schema, so the description adds little parameter-level value.

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

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

The description states a specific verb ('Update') and a specific resource ('an inbound assistant'), and the word 'inbound' separates it from the sibling update_outbound_assistant. It is unambiguous and not a mere restatement of the tool name because it adds the confirmation precondition.

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 provides a clear precondition: the operation should only happen after explicit user confirmation. However, it does not describe when to prefer this tool over alternatives such as update_outbound_assistant, nor does it mention when NOT to use it, so the usage guidance is implied rather than explicit.

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 this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable context: voice, model, and transcriber are replaced as whole objects, and the confirmation step is mandatory. It doesn't contradict annotations and provides additional behavioral nuance beyond them.

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

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

The description is two sentences with no waste. It front-loads the core action, then immediately provides the critical behavioral detail. Every clause 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?

Given the tool's complexity (14 params, nested objects, output schema), the description covers the essential gotchas: whole-object replacement, fetch-before-update, and confirmation. It doesn't explain every field, but the output schema and existing param descriptions handle most details. The description is sufficient for correct invocation.

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

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

With only 14% schema description coverage, the description compensates for the most complex parameters (voice, model, transcriber) by explaining the replace semantics and how to handle them. However, it does not touch on other parameters like name, description, or booleans, which are self-explanatory but not explicitly clarified. It partially offsets the low coverage.

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

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

The description clearly states the action 'Update an outbound assistant' and the resource, distinguishing it from siblings like create, delete, or get. It also adds the specific nuance about replacing voice, model, and transcriber as whole objects, which is unique to this 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?

Provides explicit guidance on the required workflow: fetch current config with get_outbound_assistant, apply edits, and confirm. It also implies the use case of updating an existing assistant, though it doesn't explicitly contrast with create_outbound_assistant. The confirmation requirement is clearly stated.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, so the description adds substantial value beyond them: it discloses that saving affects future turns, sends no message, requires idempotency handling, and mentions REVISION_CONFLICT handling. This is rich behavioral context beyond the structured fields.

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

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

The description is long but every sentence carries essential information: prerequisites, effects, consent, retry, and post-check. It is structured logically and front-loads the main action. It could be tightened but remains efficient for the complexity.

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

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

Given the tool's complexity (nested updates, idempotency, conflict handling, consent), the description covers prerequisites, update semantics, persistence, no-message effect, and error recovery. An output schema exists, so return values need not be explained. Nothing critical is missing for correct invocation.

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

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

Schema coverage is only 40%, so the description compensates. It explains idempotencyKey reuse, expectedRevision on retry, and that omitted fields in updates remain unchanged. It also directs resolving group IDs for audienceGroupIds. It does not detail every field, but it adds meaning beyond the schema for the key 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 the action: 'Update the exact WhatsApp agent' – a specific verb and resource. It adds context by requiring a prior read and confirmation of the selected account, agent, and changes, which distinguishes it from read-only tools like get_whatsapp_agent and other resource update 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?

Provides explicit usage conditions: must read first, confirm the exact changes, and resolve group IDs using list_contact_groups. It also states that omitted fields stay unchanged, requires fresh consent, and gives retry behavior on conflict – all clear guidance on when and how to use it.

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