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

Beyond annotations (readOnly=false, destructive=true), the description adds that the contact is 'queued immediately, and the campaign starts calling it as soon as it is within operating hours,' revealing real-time queueing and scheduling behavior. It also explains the lifecycle of dynamic campaigns, which is valuable context not 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 concise and front-loaded with the main action. The second sentence adds essential context about dynamic campaigns and the webhook use case, and the final sentence covers behavior. No filler or redundant information.

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

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

For a write tool with nested objects and no output schema, the description covers the workflow well: dynamic campaign creation, webhook feeding, queueing, and operating hours. It doesn't mention response format or error scenarios, but the annotations and schema provide sufficient context for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, and the tool description adds no additional parameter-level meaning beyond what the schema already provides. Baseline 3 applies because the schema does the heavy lifting.

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 exactly what the tool does: 'Push a single contact into a dynamic bulk-call campaign in real time.' It distinguishes this from siblings by explaining that dynamic campaigns are created from the dashboard and this webhook is how you feed them from a CRM, form, or automation platform, clearly separating it from bulk-call creation or management 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?

It provides clear when-to-use context: dynamic campaigns stay alive waiting for contacts, so this is the webhook to feed them from external platforms. However, it does not explicitly name alternative tools or state when not to use it, stopping short of full 5-level 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?

Beyond the annotations, the description adds important behavior: repeated numbers are kept rather than merged, failed rows are reported in `rejected` while the rest are still added, and rows failing `call_conditions` get status `Skipped`. This is substantive operational context that an agent could not infer from the schema or annotations.

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

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

The description is dense but focused: it front-loads the core purpose and then provides necessary caveats about duplicates, partial failures, and skipped rows. The tag 'Bulk calls' is mildly redundant, but no sentence feels wasted.

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 nested schema and the absence of an output schema, the description covers the key operational details needed for correct use. It could go slightly further by describing the response shape beyond `rejected`, but the core invocation context is complete.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description reinforces scale and batch behavior but does not meaningfully add parameter-level detail beyond what the schema provides, hence the baseline score of 3.

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 action and resource: 'Add up to 1000 contacts to a campaign in one request.' It also distinguishes this tool from the singluar form by calling itself the batch form, so an agent can tell it apart from siblings like addBulkCallContact without inspecting schemas.

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 says to prefer this tool 'whenever you have more than a handful' and explains the cost benefit. It also names the alternative ('Add contact to dynamic campaign'), giving the agent clear routing guidance between batch and single-add behavior.

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 the annotations, it discloses meaningful side effects and validation behavior: automatic agent attachment for unassigned numbers, refusal for numbers attached to a different agent, and the not-already-in-pool requirement. This is exactly the behavioral context an agent needs.

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 front-loaded with the action, followed by a pragmatic use context and necessary constraints in a compact, scannable structure. No sentence is wasted.

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 two-parameter mutation with no output schema, the description fully covers operation, when it is useful, prerequisites, side effects, and refusal behavior. The source of phone_number_id is already in the schema, so everything needed to call the tool correctly is 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 100%, so both bulk_call_id and phone_number_id are already documented. The description reinforces that phone_number_id must be one of the user's numbers but adds no new format or source details 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 a precise verb and resource: 'Add one of your numbers to the campaign's rotation pool.' It clearly scopes the operation to your numbers and distinguishes it from contact-add or generic number-management 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?

It gives a concrete use case—bringing in a fresh number while the campaign is running when the pool lacks healthy numbers—and states eligibility rules. It stops short of naming sibling alternatives or explicit when-not-to-use cases, so not a 5.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. However, the description adds no extra behavioral context: it doesn't disclose whether attaching files replaces existing attachments or appends to them, whether it requires the agent to exist, or what side effects occur. The description simply restates the core action without additional nuance.

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

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

The description is a single, focused sentence that immediately conveys the purpose. The parenthetical tag 'Knowledge base' is slightly redundant but harmless. There is no waste or filler, and the most important information is front-loaded.

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

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

While the schema provides parameter details, the description is incomplete for a mutation tool. It does not explain whether the operation is additive or replacing, what happens to existing file attachments, or what the response indicates. There is no output schema to fall back on. Given the complexity and lack of behavioral detail, the description leaves important gaps for an agent to select and invoke the tool correctly.

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

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

The input schema covers 100% of parameters, including descriptions for agent_id, file_ids, and when_to_use. The tool description adds no additional parameter meaning beyond the schema. According to the rubric, with high schema coverage, a baseline score of 3 is appropriate.

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: 'Attach multiple knowledge-base files to an agent.' It identifies the resource (knowledge-base files), the target (an agent), and the operation (attach). This distinguishes it from sibling tools like detachKnowledgeBaseFiles, uploadKnowledgeBaseFile, and listKnowledgeBaseFiles.

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, such as uploadKnowledgeBaseFile for uploading new files or detachKnowledgeBaseFiles for removing attachments. It only includes a 'Knowledge base' tag, which hints at context but does not explicitly state prerequisites, exclusions, or alternative scenarios.

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 and destructiveHint=false. The description adds useful context about 'account-owned' phone numbers and 'existing agent,' but omits side effects, failure modes, or multi-attachment behavior. Adequate but not thorough.

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 main sentence is concise and front-loaded, but the trailing '(Tags: Phone numbers)' is extraneous and does not earn its place. Otherwise, the structure is 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?

The operation is simple: one nested object with two well-documented parameters, no output schema. The description provides the key constraints (account-owned, existing agent). Could mention whether the number must be unattached, but is otherwise complete for this scope.

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

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

Schema description coverage is 100% for both parameters (agent_id, phone_number_id), so the schema fully documents them. The description adds no additional parameter-level detail, justifying the baseline score of 3.

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 specific action: 'Attach an account-owned phone number to an existing agent.' This distinguishes it from the sibling tool 'detachPhoneNumber' and accurately conveys the resource being modified.

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 action, but the description does not explicitly state when to use this tool versus alternatives like 'detachPhoneNumber' or any prerequisites/exclusions. No when/when-not guidance is provided.

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. The description adds the specific action types (pause/resume/reschedule) and the scope 'running campaign,' but it does not disclose side effects, permission requirements, or rate limits. It complements annotations without contradicting 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 concise, with the core action list immediately clear. The trailing '(Tags: Bulk calls)' is somewhat redundant and adds little value, but it does not detract significantly from the overall clarity.

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

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

While the schema covers parameter details, the description lacks important contextual information for a complex mutation tool: it does not clarify that 'reschedule' requires additional parameters (new_scheduled_datetime) or mention what happens after the operation (e.g., return value or side effects on the campaign). The description is adequate but under-specified for a tool with a nested request body and action-dependent parameters.

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

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

The input schema provides full descriptions for all parameters, including the action enum and the conditional fields (new_timezone, new_scheduled_datetime). The description adds no additional parameter-level detail beyond what the schema already documents, so the baseline score 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 clearly states the tool's function: 'Pause, resume, or reschedule a running campaign.' It uses specific verbs and identifies the resource (a campaign), and it distinguishes itself from sibling tools like cancelBulkCall and fetchBulkCalls by focusing on control actions rather than listing or canceling.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, such as cancelBulkCall. The phrase 'running campaign' implies a precondition, but there is no mention of when not to use it or when another tool would be more appropriate. Usage context is only implied.

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, so the destructiveness is known. However, the description adds no additional behavioral context, such as whether cancellation is irreversible, what happens to ongoing calls, or if any confirmation is needed. It simply restates the purpose without disclosing side effects beyond what annotations already indicate.

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 followed by a tag. It is extremely concise, front-loaded, and contains no wasted words. Every part earns its place, making it easily 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?

For a simple cancellation tool with one parameter and annotations, the description is adequate but not thorough. It omits behavioral nuances like what happens to already-placed calls or whether cancellation is reversible. Given the destructive nature (annotations), some additional context would improve completeness, but the tool's simplicity keeps this from being a failing score.

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 100% coverage, with bulk_call_id described as 'Id of the bulk call campaign.' The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate. No additional parameter context is needed for this simple one-param tool.

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

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

The description clearly states the action "Cancel" and the resource "bulk-call campaign," which is specific and distinguishes it from sibling tools like createBulkCall, getBulkCall, or bulkCallActions. The purpose is immediately obvious.

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 for cancellation, prerequisites, or contrast with similar tools like bulkCallActions, which might also modify campaign state. The intended use case is only implied by the verb 'cancel.'

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 the description aligns by using 'Check'. It adds a small amount of context by specifying that eligibility depends on size and type, but it does not disclose behavior such as response format, limits, or whether it checks workspace restrictions. With annotations present, the bar is lower, and the description provides only minimal additional value.

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 plus a tag. Every word earns its place, and the structure is clean and front-loaded with the verb 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?

The tool is simple, and the schema covers parameters well, but the description lacks details about the expected output or any size limit knowledge. Since there is no output schema, the agent does not know whether the response is a boolean, a reason, or a status. It is complete enough for a basic check, but missing context that could affect 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 100%; file_size and file_type have descriptive text including 'Only pdf is accepted.' The description's mention of 'size and type' duplicates what the schema already provides. No additional parameter meaning is added.

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 function: 'Check whether a file can be uploaded based on size and type.' It uses a specific verb (Check) and resource (a file) and specifies criteria (size and type). This distinguishes it from sibling tools like uploadKnowledgeBaseFile, which performs the actual upload.

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 for validation before upload but does not explicitly state when to use it versus alternatives. It lacks an explicit mention of uploadKnowledgeBaseFile or any exclusions. The context is clear enough for an agent to infer, but there is no direct guidance.

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

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

Annotations are minimal (readOnlyHint false, destructiveHint false), so the description carries some burden. It discloses that voicemail detection is access-gated and requires per-account enablement, which is genuinely useful behavioral context beyond the schema. It also communicates the scope of the create operation through the configuration list. 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 compact and front-loaded: main action first, then a concise feature list, then the important voicemail caveat in a blockquote. The '(Tags: Agents)' suffix is minor noise, but overall every sentence earns its place.

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

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

Given the very rich input schema, the description doesn't need to repeat parameter-level details. It covers the important non-obvious caveat (voicemail access gating) and gives an overview of the full configuration surface. It could mention that the request body must include name, welcome_message, and context_breakdown, but the schema's allOf already conveys this, so the gap is minor.

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

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

Schema description coverage is 100%, so the schema already provides detailed semantics for every field. The description adds a high-level feature summary and the voicemail access warning, which is parameter-relevant for the voicemail object, but it does not significantly expand on what the schema already documents.

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: 'Create a new agent with the provided configuration.' It clearly distinguishes from sibling tools like createSession and createAgentVersion by targeting the agent resource, and enumerates the configurable features (transcriber, model, voice, etc.), leaving no ambiguity about what this 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 implies usage: you use this when creating a new agent. However, it does not explicitly compare against alternatives such as updateAgent for modifying an existing agent, nor does it mention prerequisites like attaching a phone number afterward. The voicemail access warning is a constraint on a feature rather than tool-selection 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=false and destructiveHint=false. The description adds the concept of taking a snapshot of current configuration, which is useful but does not elaborate on side effects (e.g., whether it overwrites an existing version with the same name, limits on versions, or permissions required). It does not contradict annotations.

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

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

The description is a single sentence with a tag, which is very concise. It wastes no words, but the tag '(Tags: Agents)' adds little value. The information is front-loaded, but slightly more detail could be added without sacrificing conciseness.

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

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

Given the tool's simplicity (2 required parameters, no output schema), the description is mostly adequate. However, it lacks information about the return value (e.g., the created version object or ID). For a creation tool, the agent would benefit from knowing what to expect as a response. Prerequisites (agent existence) are also implied but not 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?

Schema description coverage is 100%, so the schema already documents agent_id and requestBody (including name and note). The description reinforces that the version is a snapshot of the current configuration, but does not add new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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 saves the agent's current configuration as a named version, using a specific verb ('Save') and resource ('agent's current configuration'). It distinguishes from sibling tools like createAgent, updateAgent, listAgentVersions, and restoreAgentVersion by focusing on version creation as a snapshot.

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. For example, it does not mention that the agent must already exist, that this should be called after updating configuration, or that it is distinct from listAgentVersions or restoreAgentVersion. The agent has no context to decide when to invoke this tool.

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

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

Annotations already signal mutation/destruction, so the bar is lower. The description adds meaningful behavior details: providing a contact_list causes dialing to start, save_as_draft defers dialing, and is_dynamic keeps the campaign alive via webhooks. No contradiction with annotations is present.

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 tightly written sentences with the most important guidance front-loaded. Every sentence earns its place, and there is no repetition of schema details or 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?

This is a complex tool with nested objects and no output schema, yet the description covers the required-vs-optional model and directs the agent to a fuller guide. The response format is not stated directly, though the guide reference partially compensates.

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

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

Schema description coverage is 100%, so the schema already documents parameters thoroughly. The description adds orientation by grouping optional fields into behavior categories, but it does not add significant per-parameter meaning beyond what the schema 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?

States a specific verb and resource: 'Create a new bulk-call campaign.' It also clarifies the minimal fields needed for a basic dialing run, making the tool's scope immediately obvious and distinguishable from sibling tools like getBulkCall or startBulkCall that operate on existing campaigns.

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 clear context on when to use this tool: creating a campaign, with the minimal payload called out explicitly. Optional fields are framed as independent optional behaviors, and the mention of 'endpoints that operate a campaign once it runs' gives a useful boundary, though it does not name specific sibling alternatives.

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

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

Beyond the annotations, the description reveals important behavioral traits: no audio starts on creation, the returned ws_url is single-use and expires, and the API key must remain server-side. It also explains why the ws_url is safe to hand out. These details materially help an agent reason about side effects and security without guessing.

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 front-loaded with the core purpose and then provides concise, high-value usage and security context. The 'Tags: Sessions' line and the pointer to client-connection documentation are minor noise, but every other sentence earns its place. It is appropriately sized for the complexity of 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?

Although there is no output schema, the description identifies the essential return value (ws_url) and gives enough security and usage context for an agent to invoke the endpoint correctly. It does not cover error responses or any potential additional response fields, which would make it fully complete. Overall, the missing pieces are not critical for tool selection or 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 input schema already documents every parameter with 100% coverage, including clear descriptions for agent_id, type, metadata, and custom_variables. The tool description does not add parameter-level meaning, so the baseline of 3 applies. There is no gap for the description to compensate for.

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 the exact action ('Create a voice Session') and precisely defines the resource: a short-lived, single-conversation reservation that returns a ws_url. It explicitly states that creating the session does not start audio on its own, which distinguishes it from call-dispatch and other voice-related tools. The 'step 1 of 2' framing further clarifies its role in the flow.

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 operational guidance: call this endpoint from your server with your API key, return only the ws_url to your client, and never let the API key reach the browser. It frames the endpoint as step 1 of 2, which tells the agent when it fits in the broader conversation flow. It does not explicitly name sibling alternatives or exclusion cases, but the usage context is strong.

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 include destructiveHint=true, so the destructive nature is known. The description adds 'permanently', reinforcing irreversibility, but does not disclose potential side effects like deletion of related versions or sessions. 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 one short sentence followed by a tag. It is front-loaded, concise, and contains no wasted words.

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

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

Given the simple one-parameter schema, the destructive annotation, and clear purpose, the description is nearly complete. The only gap is a lack of mention of cascading effects (e.g., deleting agent versions), but this is not critical for a basic delete 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 100%: the only parameter agent_id is described as 'The ID of the agent.' The description adds no additional meaning beyond the schema, so baseline 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 clearly states 'Permanently delete an agent' with a specific verb and resource. It distinguishes from sibling tools like deleteAgentVersion and deleteKnowledgeBaseFile by targeting the agent itself.

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

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

The description provides no explicit when-to-use or alternatives. Usage is implied by the tool's name and purpose, but there is no guidance on choosing this over other delete-related sibling tools such as deleteAgentVersion.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description's verb 'Delete' is consistent. However, it adds no extra behavioral context (e.g., permanence, required permissions, side effects) beyond what annotations provide.

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

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

The description is very short: one sentence plus a tag. It is front-loaded with the core action. However, the tag appears to be metadata leaking into the description, which is slightly distracting. It could add a bit more substance without becoming verbose.

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 tool (2 well-documented params, no output schema, clear annotations), the description is adequate but not fully complete. It could mention that deletion is permanent, or specify that version_number must come from list/save endpoints (which is already in the schema). The description provides minimal contextual supplementation.

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

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

Schema description coverage is 100%, with both agent_id and version_number documented in the schema itself. The description does not add any additional meaning or context about the parameters. Baseline 3 is appropriate because the schema carries the burden adequately.

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 'Delete a saved version' clearly states the verb (delete) and resource (a saved version of an agent). The title from annotations reinforces this. It distinguishes from siblings like renameAgentVersion and listAgentVersions by naming the delete action.

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

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

No guidance is provided on when to use this tool vs alternatives. For example, there is no mention that this deletes a specific version rather than the entire agent (for which deleteAgent exists). The description lacks usage context, conditions, or 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, but the description adds important behavioral context beyond that: permanence ('Cannot be undone') and the side effect on attached agents. This gives the agent a fuller picture of the operation's consequences.

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

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

The description is extremely concise, using three short sentences to convey action, side effects, and irreversibility. Every word earns its place, and the (Tags: Knowledge base) suffix adds contextual metadata without bloat.

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 delete operation with one well-documented parameter, the description is complete: it states the action, the permanent nature, and the agent detachment side effect. Annotations cover the destructive profile, and no output schema is needed, so no further explanation is required.

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

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

Schema description coverage is 100% for the single file_id parameter, which already documents its meaning. The description adds no extra parameter details, so the baseline of 3 is appropriate; it neither needs nor provides further elaboration.

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

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

The description clearly identifies a specific action ('Permanently delete a file') and resource ('a file' in the knowledge base context). It also distinguishes from siblings like detachKnowledgeBaseFiles by noting the file is removed from attached agents, making the scope explicit.

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 by stating the side effect ('Removes it from any attached agents'), which hints at when to use this vs detach, but it does not explicitly name alternatives or state when not to use. No direct comparison to sibling tools is provided, so usage guidance remains implicit.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description consistently describes a mutating operation. The description adds minimal behavioral context, such as the ability to detach multiple files at once, but does not disclose side effects or reversibility beyond what the annotations convey. It does not contradict 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 sentence that directly states the operation, followed by a useful tag. No filler or irrelevant information. It is appropriately front-loaded and concise.

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

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

The tool has a simple nested structure with two required parameters, fully described in the schema. Annotations indicate it is destructive, and the description clarifies the operation. Without an output schema, no return-value documentation is expected. The combination of description, schema, and annotations provides sufficient context for an agent to use the tool correctly.

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

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

The schema provides 100% coverage with descriptions for both agent_id and file_ids. The tool description adds no additional parameter details, but the schema descriptions are self-explanatory. Baseline 3 is appropriate given full schema coverage.

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

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

The description states 'Detach multiple knowledge-base files from an agent' with a specific verb (detach), resource (knowledge-base files), and target (agent). This clearly distinguishes from sibling tools like attachKnowledgeBaseFiles (opposite) and deleteKnowledgeBaseFile (delete vs detach).

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 implies the use case: when you need to remove knowledge-base files from an agent. However, it does not explicitly mention alternatives or exclusions, such as when to use deleteKnowledgeBaseFile instead of detach. The context is clear but not fully elaborated.

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 destructiveHint=true, so the destructive nature is already known. However, the description adds no additional behavioral context such as reversibility, effects on the agent, or permissions needed. It merely restates the action without enriching the annotation.

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, focused sentence that conveys the essential action without any filler. It is ideally concise and well-structured for quick comprehension.

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

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

Given the tool's simplicity (one parameter, no output schema) and the destructive annotation, the description is adequate. It could mention prerequisites (e.g., phone number must be attached) but is otherwise complete for an experienced user.

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 100% coverage with a clear description for 'phone_number_id', so the baseline is 3. The tool description does not add any extra semantic detail about the parameter 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 action ('Detach') and the resource ('a phone number from its associated agent'), making the purpose unambiguous. It also differentiates from sibling tools like attachPhoneNumber or listPhoneNumbers by specifying the reverse operation.

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 such as attachPhoneNumber. The description only states the action without any context on prerequisites or when this operation is appropriate, leaving the agent to infer usage from the name.

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, which indicates a safe read operation. The description adds that the diff is 'record-level' and explains the comparison modes. It does not disclose any other behavioral traits such as authorization requirements or rate limits, but given the read-only nature, it is sufficient.

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 the first sentence immediately stating the purpose. Each subsequent sentence adds specific information about the default behavior and the 'against' parameter. There is no redundant information, and the tag line is minimal.

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

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

The tool has no output schema, so the description should ideally describe the return value. It does not specify what the diff format looks like (e.g., list of changes, unified diff). While the description is adequate for basic usage, the lack of output description leaves a gap for the agent to understand the response structure.

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

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

The input schema has 100% coverage, with detailed descriptions for each parameter. The description adds value by explaining the default comparison and the semantics of 'against=current' (what restoring would change), which goes beyond the schema's 'agent's live config'. This additional context helps the agent understand the parameter's effect.

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

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

The description uses the specific verb 'Get' and the resource 'record-level diff' for this version. It clearly states the action and the object. Among sibling tools, no other tool provides diff functionality, so it is well-distinguished.

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 explains the default behavior (comparing with previous version) and provides examples for the 'against' parameter. However, it does not explicitly state when to use this tool versus alternatives like restoreAgentVersion or listAgentVersions, nor does it mention any prerequisites or 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 communicate that this is not read-only and is destructive/mutating, and the description's 'Initiate a call' is consistent. The description adds a useful precondition (leading + and country code), but it does not disclose asynchronous execution, response contents, or real-world side effects such as call costs.

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 short sentences with the action front-loaded and the key format constraint stated immediately after. It contains no redundant prose; the Tags line is the only marginal 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 side-effecting call tool with a nested request body and no output schema, the description is adequate but thin. It gives the core purpose and the most important input constraint, while relying on the schema for parameter detail; it leaves the agent uninformed about response shape or post-call behavior.

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

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

The input schema has 100% description coverage, including the country-code rule on to_number and the metadata webhook behavior. The description therefore adds no meaningful parameter semantics beyond the schema; the baseline 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 the specific action and target: 'Initiate a call to a phone number using a specified agent.' This clearly identifies the tool as starting a single outbound call and distinguishes it from list/bulk siblings, though it does not explicitly name an alternative such as createBulkCall.

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 dispatchCall versus siblings like createBulkCall, listCallLogs, or the bulk-call helpers. The only usage hint is the phone-number format requirement, which is a validation constraint rather than a selection criterion.

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, making the read-only nature transparent. The description adds behavioral details about pagination and status filtering, which go beyond the annotation. However, it does not disclose the response format, any authorization requirements, or potential rate limits, but given the annotation coverage, the added context 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 concise and front-loaded with the verb 'List'. The parenthetical '(Tags: Bulk calls)' is somewhat redundant with the tool name but does not significantly clutter the description. Overall, every sentence contributes to the core purpose without excessive verbosity.

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

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

For a simple read-only list operation with three well-documented optional parameters, the description covers the essential aspects: purpose, pagination, and filter capability. It does not detail the return structure, but the lack of an output schema and the tool's simplicity make this acceptable, especially with the readOnlyHint annotation.

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 provides 100% coverage with detailed descriptions for all three parameters, including types, defaults, and constraints. The description's mention of 'optional status filter' merely echoes the schema's status parameter description without adding new meaning, so it does not surpass the baseline for high schema coverage.

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

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

The description uses the specific verb 'List' and identifies the resource as 'bulk-call campaigns', further specifying pagination and optional status filtering. This clearly differentiates it from siblings like getBulkCall (single resource) and createBulkCall (creation), leaving no ambiguity about what the tool does.

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

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

The description does not provide any explicit guidance on when to use this tool versus alternatives. While sibling tool names imply a distinction (e.g., getBulkCall for a single campaign), the description itself offers no when-to-use or when-not-to-use context, nor does it mention any alternatives.

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

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

Annotations already declare readOnlyHint=true, so the safe read behavior is established. The description adds one useful behavioral detail: the response includes a version_history_enabled boolean. However, it does not disclose other behavioral aspects such as error handling, pagination, or organization scoping beyond that single field.

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 the primary action front-loaded. The markdown link and 'Tags: Agents' suffix add slight clutter, but the core message is concise and every sentence serves a 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?

For a simple single-parameter read operation, the description covers the essential purpose and highlights a notable response field. There is no output schema, but the description doesn't need to enumerate all return fields, and the readOnlyHint annotation covers safety context.

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

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

The input schema fully describes agent_id with 100% coverage, and the description's 'by ID' reinforces the parameter's purpose. No additional parameter semantics are needed because the schema handles the documentation burden.

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 ('details of a specific agent by ID'), which clearly identifies what the tool does. It also distinguishes itself from sibling list operations by emphasizing the singular 'specific agent by ID', and the mention of version_history_enabled adds a distinguishing detail about the response.

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 should be used when you have an agent ID and need details, but it does not explicitly contrast with alternatives like listAgents or state when not to use it. The 'by ID' condition gives context but no direct exclusion or routing guidance, so the usage guidance is only implied.

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 readOnlyHint=true annotation already indicates a safe read operation, and the description is consistent. However, the description adds no extra behavioral context—e.g., what 'detailed information' includes, error behavior, or pagination—beyond the annotation.

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 redundant content. The tag '(Tags: Bulk calls)' is minor but does not detract from clarity.

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

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

For a simple get-by-id tool with one required parameter and a read-only annotation, the description is nearly complete. The phrase 'detailed information' hints at the return value but could be more explicit about the response shape since no output schema is provided.

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 fully documents the only parameter bulk_call_id with an adequate description. The tool description adds no additional meaning beyond the schema, so 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 uses a specific verb ('Get') and resource ('bulk-call campaign') with a clear modifier ('detailed information'). This distinguishes it from sibling tools like getBulkCallLiveStatus, which focuses on live status rather than general 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?

No guidance is provided on when to use this tool versus alternatives such as getBulkCallLiveStatus or fetchBulkCalls. The description states what the tool does but gives no context for choosing it over other bulk-call 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, covering the safety profile. The description adds context that this is for 'running' campaigns and provides 'real-time' status, which is useful but does not disclose additional behavioral traits such as what fields the status includes or behavior if the campaign is not running.

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 that states the core purpose without unnecessary detail. The tag 'Bulk calls' adds little but is not distracting. Every word earns its place.

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

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

For a simple, read-only tool with one parameter and no output schema, the description is adequate. It conveys the key constraint ('running') and the real-time nature. However, it could be more complete by hinting at what status information is returned, but the low complexity level means this is not a major 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 100% for the single parameter (bulk_call_id), and the schema already describes it as 'Id of the bulk call campaign.' The description does not add any additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as retrieving real-time status of a running bulk-call campaign, with a specific verb ('status') and resource ('bulk-call campaign'). It distinguishes from siblings like getBulkCall by emphasizing 'running' and 'live', though it does not explicitly name alternatives.

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 appropriate use cases: use when you need the current live status of an ongoing bulk-call campaign. It does not provide explicit exclusions or alternatives, but the context is clear enough for an agent to differentiate from listing or general retrieval 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 declare readOnlyHint=true, so the description doesn't need to restate that. It adds context about return content (transcript, sentiment, extracted variables), but does not disclose any behavioral limitations or permissions. Adds some value beyond the annotation.

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 one sentence, front-loaded with purpose, and includes a useful parenthetical list of returned fields. The 'Tags: Calls' is minor extra but not detrimental. 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 single-parameter read tool with no output schema, the description gives a solid overview of return contents. It could mention error handling or the exact response shape, but the listed fields and specificity are sufficient for most agents.

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 call_log_id is fully described in the schema with clear provenance ('as returned by the call log list'). The tool description does not add new meaning, so baseline 3 applies given 100% schema coverage.

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

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

The description clearly states the tool retrieves detailed information about a specific call, enumerating key data points (duration, status, transcript, sentiment, extracted variables). This distinguishes it from sibling list/bulk call tools by focusing on a single resource's 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?

The description implies usage for single-call lookups via 'specific call', but it does not explicitly state when to use this over listCallLogs or fetchBulkCalls, nor does it mention exclusions or prerequisites. Context is present but not made 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?

The description adds no behavioral detail beyond the readOnlyHint and openWorldHint annotations. It does not disclose return format, permissions, or edge cases, but the annotations adequately cover the safety profile, so the description is not misleading.

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 redundant content. It front-loads the core purpose and avoids unnecessary details, which is ideal for a simple lookup 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 get-by-ID tool, the description, schema, and annotations together provide adequate context. However, without an output schema, the description could specify what metadata is included (e.g., name, provider, languages) to be more complete.

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

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

The input schema has 100% coverage with a descriptive explanation for voice_id. The tool description adds no parameter-level information, so the baseline of 3 is appropriate given the schema already handles the semantics.

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

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

The description clearly states the tool returns detailed metadata for a specific voice, implying a retrieval operation. It distinguishes from sibling tools like listVoices by targeting a single voice, though the verb is implicit rather than explicit.

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 such as listVoices or when it would be appropriate. The use case is only implied by the 'specific voice' wording, with no explicit context or 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 indicate a non-read-only, non-destructive operation. The description adds that credentials are required, which is useful context, but does not disclose side effects or expected results. With annotations already covering safety, this is adequate 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?

Very short and to the point, but includes a redundant '(Tags: Phone numbers)' line that adds no value. Otherwise efficient and front-loaded.

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

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

For an import operation with no output schema, the description is too sparse; it doesn't mention what the output or response will be, nor any side effects or prerequisites beyond credentials. The nested request body is fully documented in schema, but the lack of behavioral context makes it 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?

The schema fully describes all parameters with descriptions and required fields, so the description need not add parameter details. Baseline 3 is appropriate as the description adds no extra meaning beyond the schema.

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

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

Clearly states it imports an Exotel number, using a specific verb and resource. The mention of Exotel credentials distinguishes it from sibling import tools like importTwilioNumber and importSipTrunk.

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?

Implied usage: use when you have Exotel credentials and want to import an Exotel number. No explicit exclusions or comparison to alternatives, but the name and description are sufficiently specific.

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, implying a mutation. The description adds no additional behavioral transparency beyond that—it does not disclose whether the import overwrites existing numbers, requires special credentials, or has side effects on the SIP trunk configuration. With annotations present, the description should add context like idempotency or permission requirements, but it does not.

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 core description is a single concise sentence that directly states the action. The appended '(Tags: Phone numbers)' is a minor distraction but does not detract significantly. It is appropriately sized and front-loaded.

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

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

Given a complex nested requestBody with nine parameters and no output schema, the description is under-specified. It does not explain the import's effect, when it might fail, or how it relates to other phone number tools. The rich schema covers inputs but not behavioral context, leaving the description 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?

The input schema has 100% coverage with detailed descriptions for every parameter, including E.164 format and default port 5060. The description adds no extra parameter-level meaning; the baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description uses the specific verb 'Import' and identifies the resource as 'a phone number associated with a SIP trunk,' which distinguishes it from sibling tools like importTwilioNumber and importExotelNumber. However, the tool name 'importSipTrunk' and title 'Import SIP trunk' create some ambiguity about whether the trunk or the phone number is the primary object, so it is not perfectly 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 provides no guidance on when to use this tool versus alternatives such as importTwilioNumber or importExotelNumber. There is no mention of use cases, prerequisites, or conditions that would help an agent choose this tool over others.

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=false, so the agent knows this is a mutating but non-destructive operation. The description adds context about requiring Twilio credentials, which is also present in the schema. It does not disclose side effects, idempotency, or ownership checks, so it adds minimal behavioral value beyond annotations.

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

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

The description is a single sentence that front-loads the action and requirement. It contains no redundant information, and the tag is harmless.

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 import tool with a nested object schema, the description is adequate but minimal. It doesn't explain the outcome of the import, potential error conditions, or how the imported number will be used (e.g., for later attachment). Given the lack of an output schema, the agent might benefit from more context, but the core operation is clear 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?

Schema description coverage is 100%, with clear descriptions for phone_number, account_sid, account_token, and name. The description's mention of 'credentials' loosely maps to the SID and token but adds no detail beyond the schema, so it doesn't enhance parameter understanding.

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 ('Import'), the resource ('existing Twilio number'), and the method ('providing your Twilio credentials'). This distinguishes it from sibling tools like importExotelNumber and importSipTrunk, which target different providers.

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 use case (importing a Twilio number with credentials) but does not explicitly compare to alternatives or state when not to use it. There is no mention of prerequisites or exclusions, leaving the agent to infer from the tool name and 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 the description adds useful behavioral details beyond that: pagination support and authenticated user scoping. It does not contradict annotations and adds value by explaining the listing mechanism.

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 is front-loaded with the key action and resource. It is concise with no unnecessary fluff, though the parenthetical tag '(Tags: Agents)' is slightly redundant, it does not significantly detract from the clarity.

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

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

While the tool is simple and annotations are good, the description omits the name filter capability that is a key feature in the schema. It also doesn't describe the return format (no output schema), but one would expect a list of agents. The omission of filtering makes it less complete than it could be.

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

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

Schema description coverage is 100%, so the schema already fully describes the parameters. The description mentions pagination but does not add any parameter-specific meaning beyond what's in the schema, so a baseline score of 3 is appropriate.

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 ('Retrieve'), the resource ('all agents'), and the scope ('for the authenticated user'), making it easy to distinguish from siblings like getAgent (single agent) and createAgent. The pagination support is also mentioned, which adds specificity.

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

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

The description provides clear context for when to use the tool (listing agents for the authenticated user), and the pagination note implies usage for large datasets. However, it does not explicitly state alternatives or when not to use it, though the sibling list makes this fairly obvious.

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, signaling a safe read operation. The description adds value by specifying that versions include manual, auto, and system backups, and that results are ordered newest first. This goes beyond the annotations without contradicting them, providing useful behavioral context.

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

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

The description is extremely concise: two sentences covering purpose, ordering, version types, and a tag. Every sentence contributes meaning, with no redundant or extraneous text. This is a model of 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?

Given the absence of an output schema, the description should help the agent understand what the tool returns. It mentions ordering and version types but does not describe the structure of returned objects (e.g., fields like id, name, kind). While the tool is straightforward, the lack of output details leaves a gap for agents needing to parse results.

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

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

Schema description coverage is 100%, so the input schema already documents all 5 parameters thoroughly. The description does not add parameter-level details beyond the general purpose. Baseline of 3 is appropriate as the description adds no additional semantic value for 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 verb ('List') and resource ('an agent's saved versions'), specifies ordering ('newest first'), and enumerates included version types (manual, auto, system backups). This effectively differentiates from sibling tools like listAgents (lists all agents) and getAgent (single agent), making the tool's purpose unmistakable.

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 such as listAgents, getAgent, or version management tools. There are no explicit when-to-use, when-not-to-use, or alternative recommendations, leaving the agent to infer usage context from tool names 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?

The description adds that the response is comprehensive and bundles services and voices into one payload, which is useful context not present in annotations. However, it does not disclose pagination, authentication, rate limits, or what 'services' specifically covers. Annotations already indicate read-only behavior, so the bar for additional transparency is partially met.

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

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

The description is extremely concise, with one meaningful sentence and a tag. It is front-loaded and contains no fluff, making it quick 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?

The description is incomplete for a 0-parameter tool with no output schema. It fails to clarify what 'services' means, whether it includes all provider types, or how this tool relates to sibling listing tools. A complete description should at least state that it lists all providers in one call, serving as a combined endpoint.

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 fully covers parameter semantics (100% coverage). The description need not explain parameters; a baseline of 4 is appropriate for a no-parameter tool.

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

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

The description 'Comprehensive response with services and voices in one payload' lacks a clear verb and does not explicitly state that the tool lists all providers. The tag 'Providers' hints at the resource, but the purpose is vague and could apply to several sibling tools.

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

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

No usage guidance is provided. The description does not mention when to use this tool versus alternatives like listLLMProviders or listVoices, nor does it provide any exclusions or preferred contexts.

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 only state readOnlyHint and openWorldHint, so the description carries the behavioral disclosure burden and succeeds. It explains the cursor contract, oldest-first ordering, exactly-once paging guarantees, why transcripts are not embedded, and where to fetch them. No contradiction with 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 purpose is front-loaded and the rest is organized under clear Paging and Transcripts sections. The content is valuable, though some details repeat schema descriptions and the code block could be considered slightly redundant.

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 7-parameter paginated tool with no output schema, this description is complete: it covers the response shape, paging state machine, ordering, duplicate guarantees, and transcript retrieval beyond the endpoint. An agent has enough context to call and walk the endpoint 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 100%, so the baseline is 3. The description usefully reinforces cursor and pagesize behavior, but it does not add meaningful new semantics for search, call_status, interaction_status, bulk_call_id, or include_total beyond what the schema already documents.

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 and informative definition: per-contact results for a campaign, covering what happened on each call, variables sent with the contact, and a pointer to the recording. This clearly identifies the resource and distinguishes it from bulk-call-level or number-list-level sibling tools.

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

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

It provides concrete usage context: this is the tool for per-contact campaign results, and it gives a complete paging loop plus an explicit pointer to a separate endpoint for transcripts. It does not name sibling tools or state exclusions, so it falls just short of full alternative-based 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 the description adds meaningful behavioral details beyond that: it returns the current dialing number and explains the semantics of calls_this_cycle vs calls_dispatched. This helps an agent understand the live/stateful nature of the read operation and what the lifetime vs cycle counters mean.

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 core description is front-loaded and compact, with the main purpose stated first and field semantics following in two concise sentences. The trailing '(Tags: Bulk calls)' is minor noise but does not significantly hurt clarity.

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

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

With no output schema present, the description does enough by explaining the main return concepts (number pool, current dialing number, calls_this_cycle, calls_dispatched) and their operational meaning. It could be slightly more explicit about the full response shape, but for a simple one-parameter read-only tool 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 only parameter, bulk_call_id, is fully described in the schema ('Id of the bulk call campaign'), giving 100% schema description coverage. The description adds no additional parameter-specific detail, but none is needed given high coverage and a single simple 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 identifies the resource as the campaign's number pool and adds the distinctive live element of which number is dialing now. It is distinguishable from general tools like listPhoneNumbers and searchPhoneNumbers, though it doesn't explicitly say 'list' or name a sibling to differentiate from. The annotation title 'List campaign number pool' reinforces the action.

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

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

The description implies when the tool is useful by saying calls_this_cycle is the field to watch for the next rotation, giving practical guidance for interpreting results. However, it does not explicitly state when to use this tool over alternatives like listBulkCallLines or getBulkCallLiveStatus, nor does it mention 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 openWorldHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond annotations—it only restates the schema's filtering capability without disclosing return format, permissions, or other runtime behavior.

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 that clearly states the action and scope. The parenthetical '(Tags: Calls)' is minor noise but does not detract significantly. Overall, it is concise and structured for quick readability.

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

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

For a simple list tool with well-documented optional parameters and read-only annotations, the description is minimally adequate. However, it does not describe the return value or any sorting/default behavior, and with no output schema, the agent must assume the response contains a list of call logs.

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

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

Schema description coverage is 100%, so each parameter already has a clear meaning. The description mentions 'pagination and optional filtering' at a high level, which aligns with the schema but adds no per-parameter details beyond what the schema 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 uses the specific verb 'Retrieve' and resource 'call logs', indicating a listing operation. It mentions pagination and filtering, which clearly distinguishes it from getCallLog (retrieving a single log). However, it doesn't explicitly name siblings, so it's clear but not fully differentiated.

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 like getCallLog. The mention of pagination implies use for listing multiple records, but there is no explicit when-to-use or when-not-to-use statement, nor any mention of alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows it is a safe read operation. The description adds the authentication scope, which is useful but minimal. It does not mention pagination, result format, or rate limits.

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

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

One sentence, front-loaded, no wasted words. The tag adds minor context but does not detract.

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 list tool, the description covers the essentials. It lacks output schema details, but that is not necessarily required given the 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 no parameters and the schema is empty, so the description carries no burden. Baseline 4 is appropriate.

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 ('List') with a resource ('knowledge-base files') and scope ('for the authenticated user'). It distinguishes from siblings like upload/delete/attach by its listing nature.

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. While it is the listing counterpart to upload/attach/delete, there is no explicit context or 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 declare readOnlyHint=true and openWorldHint=false, and the description adds no significant behavioral details beyond restating the scope. The phrase 'all available' is consistent with openWorldHint=false but doesn't provide new information. No contradictions.

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

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

The core sentence is concise and front-loaded, but the 'Tags: Providers' suffix is unnecessary fluff. Overall, the description is efficient but not perfectly waste-free.

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 no output schema, the description is sufficient. It clearly states what the tool returns (all available LLM providers) and the annotations cover safety and world-openness. No additional context is needed.

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 baseline is 4. The description doesn't need to add parameter details since there are none, and the schema is trivially covered.

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 'retrieve' and the resource 'all available Large Language Model providers,' making the tool's purpose unambiguous. It also differentiates from sibling tools like listSTTProviders and listTTSProviders by explicitly focusing on LLM providers.

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 LLM providers are needed, and the name reinforces this. However, it doesn't explicitly compare against alternatives like listAllProviders or mention when not to use it. 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 declare readOnlyHint=true and openWorldHint=false, so the read-only, account-scoped nature is covered. The description adds useful context about the two sources of numbers (shop-bought and imported), but does not disclose additional behavior such as pagination behavior, ordering, or output shape.

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 main sentence is concise, front-loaded, and packs meaningful scope information into one clause. The parenthetical '(Tags: Phone numbers)' adds minimal value, but the description overall is tight 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?

For a simple paginated list tool with two optional, well-documented parameters and a readOnlyHint, the description is mostly complete. It does not describe return format, but the absence of an output schema and the simplicity of the operation make this a minor gap rather than a critical one.

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

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

Schema description coverage is 100%, with both pageno and pagesize fully described in the input schema. The tool description adds no parameter-specific information, but the schema already carries that burden, making the baseline score of 3 appropriate.

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 clear verb ('Retrieve') and resource ('the phone numbers on your account'), and explicitly includes both purchased and imported numbers. This makes the tool's purpose immediately distinguishable from related siblings like purchasePhoneNumber, importTwilioNumber, and searchPhoneNumbers.

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 this is the account-wide listing tool for phone numbers, but it does not explicitly say when to prefer it over searchPhoneNumbers or when not to use it. There is no mention of alternatives or exclusions, leaving usage context partially implied.

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

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

The description adds no behavioral context beyond the annotations. It says 'Retrieve all' which restates the readOnlyHint. There is no mention of response format, pagination, rate limits, or what the 'all' list contains. The openWorldHint=false is not explained. Given annotations already declare read-only, the description contributes little.

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 and front-loaded with the main action in the first sentence. The parenthetical tag '(Tags: Providers)' is arguably unnecessary but does not distract. It is appropriately sized for a trivial 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 no-parameter read-only list, the description is minimally adequate. However, it does not indicate the shape of the response (e.g., array of provider objects with ids/names) or any behavior like sorting or empty results. With no output schema, this information would be helpful. But given the simplicity, a score of 3 is reasonable.

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 zero parameters, there is nothing for the description to clarify. The schema is trivially complete (100% coverage). The description adds no parameter info but none is needed. Baseline is 4.

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

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

The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'Speech-to-Text providers', distinguishing it from sibling tools like listLLMProviders and listTTSProviders. The meaning is unambiguous, though it does not mention alternatives.

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 usage context or alternatives are provided. The description simply states what it does with no guidance on when to prefer this over listAllProviders or other provider lists. For a tool with no parameters, there is also no mention of prerequisites or limitations.

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 openWorldHint=false, and the description adds the 'all' scope. However, it does not disclose possible behavioral traits like pagination, response shape, or whether only active providers are returned. No contradiction 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?

The description is a single, front-loaded sentence that states the purpose clearly. The 'Tags: Providers' suffix is minor and does not detract from conciseness.

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

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

For a zero-parameter, read-only list tool with strong annotations and no output schema, the description sufficiently conveys what is retrieved. No critical information is missing for basic selection and 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 zero parameters and 100% schema coverage, the description has no additional parameter semantics to convey. The baseline of 4 is appropriate for a parameterless tool.

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

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

The description uses a specific verb ('Retrieve') and a clear resource ('all Text-to-Speech providers'). It distinguishes from sibling tools like listLLMProviders and listSTTProviders by explicitly naming the TTS domain.

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 TTS providers are needed, but it provides no explicit when-to-use guidance or alternatives. It does not mention that listAllProviders exists for a combined provider view, so differentiation is only implicit.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral differences: ElevenLabs allows advanced filtering by name, language, accent, and gender, while other providers only support pagination. This goes beyond annotations by explaining provider-specific constraints, though it stops short of detailing behavior when provider is omitted.

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

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

The description is two sentences: the first states the core purpose, the second adds provider-specific context. The 'Tags: Providers' suffix is minor but does not detract. Every word earns its place with no redundancy.

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

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

Given the tool's moderate complexity (7 optional params, provider variations) and lack of an output schema, the description covers the key nuance: which providers support advanced filtering vs basic pagination. It does not describe return structure, but the schema covers parameters and the name implies a voice list, making this 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 input schema already provides complete descriptions for all 7 parameters (100% coverage), including 'ElevenLabs only' labels. The description's mention of 'advanced filtering' simply summarizes the schema without adding new meaning, so it meets the baseline but does not exceed it.

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 voices with filtering and pagination support, using a specific verb and resource. It also distinguishes provider-specific capabilities, setting it apart from sibling tools like getVoice (single voice) and listTTSProviders (providers).

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

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

The description provides clear context for when to use the tool and what to expect across providers ('ElevenLabs supports advanced filtering... Other providers support basic pagination only'). It does not explicitly name alternative tools for single-voice retrieval, but the provider-specific guidance serves as practical usage direction.

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 the annotations (readOnlyHint=false, destructiveHint=true), the description discloses the financial impact ('monthly rental comes out of your wallet') and the state change ('number is added to your account'). It does not mention irreversibility or refund policy, but the key behavioral consequences are present and consistent 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 two substantive sentences are concise and front-loaded with the operation and its effects. The parenthetical 'Tags: Phone numbers' is minor non-functional metadata that keeps it from a perfect 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?

The tool has no output schema, but the description plus fully-covered schema gives an agent enough to invoke it correctly: the purchase source, cost, resulting account state, and the required/nested request body are all accounted for. The only notable gap is the lack of explicit coordination with search and import siblings, which is already reflected in the usage-guidelines score.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the schema (region enum, phone_number 'as returned by the search operation', Idempotency-Key for safe retries). The description adds no new parameter-level meaning, which matches the baseline for high 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 opens with 'Buy a phone number from the OmniDimension number shop', naming the verb, resource, and source. It also states the consequences (monthly rental, added to account, attach to agent), which distinguishes it from sibling import tools like importTwilioNumber.

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 shop provenance and 'ready to attach' imply when to use it, but there is no explicit statement of when not to use it or which alternatives to prefer. For instance, it does not tell the agent to call searchPhoneNumbers first or to use importTwilioNumber/importExotelNumber for externally hosted numbers.

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 flag destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds useful behavioral context beyond those flags: releasing the number stops rental charges at the next renewal and is only valid for numbers currently allocated to the account. It does not contradict 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?

Two tightly written sentences state the action, the consequence, and the precondition with no filler. The tag line is the only extra, and it does not degrade readability.

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

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

For a one-parameter destructive action with destructiveHint already present, the description provides the necessary context: what happens (stop rental), the cost effect (no renewal charge), and the valid condition (allocated number). No output schema is present, and none is needed for this simple release 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?

The schema already documents phone_number with 100% coverage, so the baseline is 3. The description adds a meaningful selection constraint on that parameter: only numbers currently allocated to the account are valid inputs. It does not provide format details, but those are not demanded by the schema's simple string type.

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 action ('Give up a phone number and stop its rental') and clarifies the financial consequence, so an agent immediately knows this is the tool for ending a phone number's rental. The precondition 'Only a number currently allocated to the account can be released' distinguishes it from number acquisition/import/detach operations among the siblings.

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

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

The description implies the tool is appropriate when a number is currently allocated and should no longer be rented, but it does not explicitly name alternatives (e.g., detachPhoneNumber) or state when not to use this tool. The guidance is contextual but left to inference.

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 mutation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds valuable context that version history is otherwise immutable, clarifying that only name and note can change. No contradiction.

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

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

Two sentences front-load the action and then add essential context about immutability. No filler or redundancy; every word earns its place.

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

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

For a simple rename/edit operation with three well-documented parameters and no output schema, the description is complete. It explains the scope of changes and the immutable context. Could optionally note the return behavior, but not necessary.

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

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

Schema coverage is 100% with clear parameter descriptions. The description does not add additional semantic guidance beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description explicitly states the tool renames or edits the note of a saved version, which is a specific action on a clear resource. It distinguishes from sibling version tools (list, create, delete, diff, restore) by focusing solely on metadata changes.

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 notes that version history is immutable except for name and note, implying that this tool is the only way to modify metadata. However, it does not explicitly contrast with siblings like createAgentVersion or restoreAgentVersion, nor state when not to use it.

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

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

The description goes beyond the destructiveHint annotation by explaining that a backup is automatically saved (making restoration undoable) and detailing that deleted knowledge files/integrations cannot be re-linked and are reported in a `skipped` field. This adds critical 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?

The description is two sentences plus a tag, front-loading the action and adding essential details about reversibility and limitations. Every sentence serves a purpose with no wasted words.

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

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

The description covers the core behavior, side effects, and a field in the response (`skipped`). Without an output schema, it provides sufficient information for an agent to decide when to use the tool, though a bit more detail on the full response structure would improve completeness.

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

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

Schema coverage is 100% and the description adds no additional meaning beyond what the schema already provides for agent_id and version_number. The baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool restores a version onto the live agent, with a specific verb and resource. It distinguishes itself from sibling tools like listAgentVersions and deleteAgentVersion by describing a distinct action.

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

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

The description implies the tool is for reverting an agent to a previous state, but it does not explicitly state when to use it versus alternatives such as diffAgentVersion or createAgentVersion. No exclusions or when-not guidance are provided.

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

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

Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds behavioral context beyond those hints by stating that the operation re-queues without creating a new campaign and that retried contacts keep their original variables. It does not fully enumerate consequences, but it meaningfully supplements 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 front-loaded with the core purpose file, followed by useful usage context and an important side-effect note. It is concise overall, though the colloquial examples and the 'Tags: Bulk calls' line add a little extra prose that is not strictly necessary.

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

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

Given no output schema, the description covers the main operational context: when to call it, what it does, and a key preservation guarantee. It does not describe response behavior or failure modes, but the schema fully covers the request parameters and the annotations clarify the safety profile, making this adequate 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 100%, so the parameters max_retries, retry_strategy, and failure_reasons are already documented in the schema. The tool description adds no per-parameter detail and only frames the general purpose, so the baseline score of 3 is appropriate.

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 action and resource: 'Re-queue contacts that did not connect, without creating a new campaign.' This directly distinguishes the tool from other bulk-call tools that start or create campaigns, and the title 'Retry unconnected contacts' reinforces the purpose.

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, contextual when-to-use guidance: 'after a campaign finishes with more no-answers than you expected' or when the failure was on the caller's side. It does not explicitly name alternative tools or state when not to use it, but the intended trigger conditions are unmistakable.

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 readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond those: price and validity are flat per region, every result shows identical monthly_rental_usd and validity_days, and that amount is exactly what a purchase charges. No contradiction with annotations.

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

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

Two sentences, front-loaded with the verb and resource, followed by a compact and important pricing caveat. 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 simple read-only search tool with one required parameter and no output schema, the description adequately covers what the tool does, how region affects results, and the key pricing behavior. It doesn't enumerate return fields beyond the two mentioned, but the schema and annotations fulfill the essential calling contract.

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

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

Schema coverage is 100% and each parameter has a description, so baseline is 3. The description only reinforces that region determines the flat price; it does not add new parameter-level detail 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?

States a specific verb ('Search'), a clear resource ('phone numbers available to buy in a region'), and scope. The phrase 'available to buy' distinguishes it from siblings like listPhoneNumbers (which likely lists owned numbers) and purchasePhoneNumber (which actually buys).

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 for browsing purchasable inventory, but it never explicitly states when to use this tool versus listPhoneNumbers or purchasePhoneNumber. No exclusions or alternative conditions are provided.

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 non-read-only, non-destructive mutation. The description adds behavioral context beyond that: the change can be applied to a running campaign, and the effective ceiling is the account's concurrency limit. This helps an agent understand the impact without over-promising specifics.

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 short, front-loaded with the primary action, and every sentence contributes: purpose, runtime applicability, operational tradeoffs, and the account limit constraint. There is no redundant 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 two-parameter setter, the description covers the core behavior, valid timing, value-selection guidance, and the limiting constraint. It does not describe the response shape, but no output schema exists and a straightforward mutation like this can reasonably omit that detail. Overall it gives an agent enough to call 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 100%, so the descriptions already define bulk_call_id and concurrent_call_limit. The description adds decision-making semantics for concurrent_call_limit — 'Raise it to finish sooner, lower it if your team cannot keep up' — which helps an agent choose an appropriate value rather than merely passing the field.

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: 'Change how many calls the campaign places at once' — clearly identifying the bulk-call concurrency setting. This distinguishes it from sibling tools like setBulkCallDailyTimeControl or setBulkCallNumberActive by focusing on the concurrency dimension.

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 situational guidance: raise concurrency to finish sooner, lower it if the team cannot keep up or numbers are answered less. It also notes the operation is valid 'while it is running.' It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to decide when this tool fits.

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 and destructiveHint=false, so the description carries the burden of explaining what the mutation does. It adds useful nuance: 'holds rather than finishing' and 'resumes the next day.' However, it does not disclose whether it overwrites existing settings or any side effects on in-progress calls, which are relevant for a mutation tool.

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

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

The description is two sentences with high information density. The purpose is front-loaded, and the behavioral consequence is stated immediately. No filler or redundant phrasing. The '(Tags: Bulk calls)' line is minor and does not harm conciseness.

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

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

Given the full schema coverage and absence of an output schema, the description adequately conveys the tool's purpose and behavioral effect. It could mention that the tool can also disable the daily window (since booleans exist), but this is implicitly covered by the schema. 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?

Schema description coverage is 100%, and every parameter is already documented with clear descriptions (e.g., 'Hour of day to stop, 0 to 23. Fractions are allowed'). The tool description adds no additional parameter-level meaning, so 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 ('Restrict') and resource ('a campaign') and immediately clarifies the behavioral effect: calls hold outside the window and resume next day. This clearly distinguishes it from other setBulkCall* tools (e.g., concurrency, number active) without needing to open the schema.

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

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

No guidance is given on when to use this tool versus alternatives, such as 'Use this when you need to set calling hours; for concurrency use setBulkCallConcurrency.' The description only explains what it does, not the decision context. Given many sibling tools, this is a notable gap.

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?

It discloses key side effects beyond the annotations: dialing moves to the next number, the paused number keeps history and counters, the last active number cannot be paused, and setting the desired state makes retries harmless. These details explain both the operational impact and the idempotency behavior.

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 front-loaded with the core purpose and every paragraph earns its place: usage guidance, behavioral effects, a constraint, idempotency semantics, and a parameter disambiguation. It is detailed but not padded.

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 mutation tool with three required parameters, full schema coverage, and no output schema, the description provides enough context to invoke it correctly. It covers when to pause, when pausing is not allowed, the exact meaning of the ambiguous parameter, and the idempotent behavior.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds crucial extra meaning for assignment_id, clarifying that it is the number's id within the campaign's pool and explicitly distinguishing it from phone_number_id. This is real semantic 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 opens with a specific verb and resource: 'Stop or resume dialing from one number in the pool.' It clearly identifies the tool's scope at the per-number level, distinguishing it from campaign-level siblings like setBulkCallConcurrency or bulkCallActions.

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 when-to-use guidance: 'Pausing is what you want when a number starts going bad mid-campaign.' It also states a meaningful exclusion: the last active number of a running campaign cannot be paused. However, it does not explicitly name alternative tools or say when to use one instead.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description adds value beyond these by clarifying that the action is irreversible in the sense that a finished/scheduled/running campaign cannot be started, and that attempting to do so will fail. This behavioral context is not present in the annotations. No contradiction with annotation hints.

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

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

The purpose is front-loaded in the first sentence, followed by a compact workflow explanation and a clear exclusion. Each sentence earns its place. The trailing '(Tags: Bulk calls)' is minor overhead, but the overall structure is efficient 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?

For a single-parameter action with no output schema and no nested objects, the description is thorough: it explains the draft setup lifecycle, the precondition, and the failure case. It could mention what a successful start returns, but given the tool's simplicity this is a minor gap, not a completeness failure.

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

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

Schema description coverage is 100% (bulk_call_id: 'Id of the bulk call campaign.'), so the schema already carries the parameter meaning. The description only loosely ties the ID to the draft concept via 'a campaign that was created with save_as_draft: true,' adding no new syntax or format details. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a specific verb+resource: 'Start a campaign that was created with save_as_draft: true.' This precisely scopes the action to draft campaigns, distinguishing it from siblings like createBulkCall, cancelBulkCall, and retryBulkCall without ambiguity.

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 draft workflow paragraph makes the intended timing clear — use it after creating, adding contacts, setting number pool and concurrency. It also states an explicit exclusion: 'A campaign that is already running, scheduled, or finished cannot be started.' It doesn't name a specific alternative tool, but the preconditions and exclusions are well defined.

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 (readOnlyHint=false) already establish this is a write operation, and the description's 'Update' is consistent. Beyond annotations, it adds genuine behavioral context: partial PATCH-like semantics (omitted fields are preserved) and the account-level access gate on voicemail detection, which would otherwise cause confusing failures. It doesn't mention effects on in-flight calls or reversibility, but the disclosed traits are the most decision-critical ones.

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 crisp sentences front-load the core action and the partial-update rule, followed by one blockquote that flags the only real-world caveat an agent must know before configuring voicemail. No filler or repetition of schema 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 tool with a massive nested schema that is already 100% self-documented and annotations that cover the safety profile, the description fills exactly the gaps the schema cannot express: partial-update behavior and an account-level access prerequisite. The absence of an explicit note on when to use this versus createAgent is a minor gap given the clarity of the verb.

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

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

Schema description coverage is 100%, and the requestBody contains detailed per-field descriptions, so the schema carries the documentation load. The description's main semantic contribution is clarifying that requestBody is a partial patch despite being required — genuinely useful, but it only illuminates one aspect of a large parameter surface.

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: 'Update an existing agent.' The modifier 'existing' and the update semantics clearly differentiate it from sibling tools like createAgent, getAgent, and deleteAgent without ambiguity. It lacks an explicit naming of sibling alternatives, but the purpose is unmistakable.

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 direct how-to guidance: 'Send only the fields you want to change,' which communicates the partial-update convention, and the blockquote adds a conditional constraint for the voicemail object (request access first). However, it never explicitly tells the agent when to prefer this over createAgent, createAgentVersion, or restoreAgentVersion, leaving lifecycle routing to inference.

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 only behavioral detail added beyond the annotations is the Base64 encoding requirement, which is already present in the schema's parameter description. The description does not disclose what happens on success, whether there are file size limits, if the upload is asynchronous, or what the response contains. Since there is no output schema, this omission is significant.

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 short and front-loaded, with two direct sentences plus a redundant tag. Every sentence carries some weight, though the tag '(Tags: Knowledge base)' is unnecessary given the tool name.

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 lacks an output schema, so the description should explain the return format or success indication, but it does not. It also omits reference to canUploadFile, which exists as a sibling and likely serves as a prerequisite. The nested requestBody structure is only clarified in the schema, leaving the agent without enough context for a complete 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 100% — both 'file' and 'filename' have descriptive text. The tool description reiterates 'PDF' and 'Base64' but adds no new semantic information beyond what the schema already provides. Baseline 3 is appropriate.

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 'Upload' and the target resource 'a PDF file', making the tool's purpose unambiguous. It is distinct from sibling tools like listKnowledgeBaseFiles and deleteKnowledgeBaseFile, although it could more explicitly tie it to the knowledge base context beyond the tag.

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 such as attachKnowledgeBaseFiles or canUploadFile. It does not mention any prerequisites, workflow steps, or exclusions, leaving the agent to infer the intended usage from the name and siblings.

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