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

Annotations already declare this is a non-read-only, destructive state change, so the safety bar is covered. The description adds genuinely useful context beyond that: activation makes live/production events execute the workflow. It doesn't mention permissions, idempotency, or the effect on in-flight events.

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 short sentences, effect stated first and the sibling routing second. Nothing redundant; the parenthetical tag is the only 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 single-parameter state-toggle with no output schema and full annotation coverage, the description covers purpose, effect, and the sibling pairing. Only the implicit publish prerequisite and error/return behavior are unstated, which is acceptable here.

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

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

One parameter with 100% schema description coverage, so the schema already documents workflow_id fully. The description adds no format or constraint detail beyond what the schema supplies; baseline 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?

States a specific verb and resource (turn the published workflow on) plus the observable effect ('so real events run it'), and names the inverse sibling deactivateWorkflow. It does not, however, distinguish itself from publishWorkflow or testWorkflow, which an agent could plausibly confuse with activation.

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

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

Explicitly tells the agent when to use it ('resume a workflow you paused with deactivateWorkflow'), naming the counterpart tool. It stops short of when-not guidance — e.g., that the workflow must already be published, or that publishWorkflow is the tool for a draft.

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

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

Beyond annotations (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?

Annotations already carry the safety profile (destructiveHint=true, openWorldHint=true), and the description adds genuinely non-obvious behavior: duplicates are kept rather than merged and result in two calls, and per-row validation failures land in `rejected` while the rest of the batch still succeeds. The gap is timing: it never says whether added contacts are dialed immediately or queued until startBulkCall, which matters for a destructive bulk operation.

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

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

Front-loaded with the core action and limit, then layered by decision relevance (positioning, then data semantics, then failure semantics). Every sentence carries information, though the trailing '(Tags: Bulk calls)' is pure noise and the prose runs slightly long for a two-parameter 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?

With no output schema, the description does the right thing by naming the `rejected` field and explaining partial-success semantics. It also resolves the nested `custom_variables`/`metadata` distinction against the sibling tool. The one unresolved item is when the queued calls actually fire.

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 baseline is 3, but the description adds meaning the schema cannot: the limit of 1000, the divergence from createBulkCall's `contact_list` naming, and the crucial caveat that required columns depend on the campaign's `call_conditions` (which are not evaluated on this route). That last point changes how an agent must build the payload.

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, resource and scope ('Add up to 1000 contacts to a campaign in one request'), and explicitly positions itself against two siblings: the singular 'Add contact to dynamic campaign' and the differently-shaped 'Create bulk call'. An agent can route between them without opening a 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?

Gives an explicit selection rule ('Prefer it whenever you have more than a handful') with the reason (one request of 500 is cheaper than 500 requests) and names the singular alternative for small batches. The when-to-use decision is fully resolved in the text.

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 declare readOnly=false and destructive=false, so the safety profile is covered. The description adds real value beyond them: it discloses that existing actions are untouched by the add, and it explains the Idempotency-Key retry contract (same key and body returns the prior-added action, adding nothing new). It stops short of noting auth requirements or per-channel side effects.

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

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

Three short sentences, purpose front-loaded, then the non-destructive scope, then the retry detail. Nothing is wasted; the trailing '(Tags: Agents)' is the only extraneous token.

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?

Annotations cover the mutation safety profile and the schema fully documents every field, so an agent has what it needs to call this correctly. There is no output schema, and the description only gestures at the return value via the idempotency sentence; a note on prerequisites (existing agent) would close the remaining 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% and the schema already documents agent_id, the request body, and the Idempotency-Key header in depth, so the baseline is 3. The description restates the idempotency semantics but adds no format, constraint, or channel-specific meaning beyond what the schema already provides.

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

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

States a specific verb and resource — 'Add one post-call action to the agent' — and the qualifier 'one' clarifies it is a single-action operation, not a bulk one. It does not explicitly name the sibling updatePostCallAction or listPostCallActions, so sibling differentiation rests on the verb alone.

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 only implied: 'Add' versus the sibling 'update'/'delete' names make the intent inferable, but there is no statement of when to prefer this over updatePostCallAction, no prerequisite (the agent must exist), and no exclusions. The 'other actions are not changed' note hints at scope but is not usage guidance.

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

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

Annotations 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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the word 'existing' as a prerequisite hint; it says nothing about whether the phone number must be unassigned, whether prior bindings are replaced, or what errors occur if the agent or number is missing.

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 short sentence, front-loaded with the verb and target, so it is efficient. The trailing '(Tags: Phone numbers)' artifact is metadata noise that earns no place in the description.

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

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

For a simple one-object mutation with fully documented parameters and no output schema, the description is minimally adequate. It leaves the return value and failure/prerequisite behavior unstated, which matters for a state-changing call that binds a purchased resource to an agent.

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

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

Schema description coverage is 100% — agent_id and phone_number_id each carry their own schema descriptions — so the baseline of 3 applies. The description adds no format, ID-type, or constraint detail 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?

States a specific verb (attach) and resource (phone number) plus the target (an existing agent), so the action is unambiguous. It does not explicitly differentiate itself from the inverse sibling detachPhoneNumber, but the name and phrasing make the direction obvious without opening a 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?

There is no guidance on when to choose this over alternatives such as purchasePhoneNumber, importTwilioNumber, or detachPhoneNumber, and no stated prerequisites. The only usage signal is the implied 'attaching to an existing agent', which restates the purpose rather than routing the agent.

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

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

Annotations 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 declare destructiveHint=true, and the description adds valuable context beyond that: the operation targets scheduled campaigns and is refused for running or draft campaigns. This tells the agent the state constraints. It doesn't explain side effects on contacts or notifications, but with annotations the bar is lower.

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

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

Two concise sentences, front-loaded with the core purpose and followed by the precondition. 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?

For a single-parameter mutation tool with annotations covering safety and a clear precondition, the description is nearly complete. It could mention whether cancellation is reversible or what happens to scheduled contacts, but no output schema exists so return values needn't be explained.

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 single parameter is fully described in the schema. The description adds no additional syntax or meaning about bulk_call_id beyond what the schema provides, so 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?

States a specific verb (cancel) and resource (scheduled bulk-call campaign), which distinguishes it from siblings like startBulkCall, retryBulkCall, and getBulkCall.

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

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

Explicitly states when the tool will be refused (already running or still a draft), giving clear conditions for when it can be used. It doesn't name an alternative sibling for those cases, but the preconditions are clear.

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

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

Annotations already 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 already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the access-gating constraint on voicemail, which is useful context beyond the annotations, but says nothing about mutation side effects such as whether an existing agent with the same name is rejected, or the idempotency/safe-retry behavior. 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?

Purpose is front-loaded in the first sentence, the capability list follows, and the access-gate caveat is placed after the relevant mention of voicemail. Slightly long given that the feature list duplicates the schema, but each part is readable and nothing is buried.

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 large create tool with a very rich nested schema and no output schema, the description usefully orients the caller by naming every major configuration area and flagging the one gated feature. It is close to complete; the missing piece is any note about required fields (name, context_breakdown) or conflict behavior, both of which the agent must infer from the schema.

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

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

Schema description coverage is 100% across both parameters, so the schema already carries full parameter documentation (including the Idempotency-Key semantics). The description's enumeration of config areas mirrors the schema rather than adding format, required-field, or interaction detail beyond it. 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?

States a specific verb and resource ('Create a new agent with the provided configuration') and then enumerates the configurable surface (transcriber, model, voice, web search, transfer, end-call, post-call actions, background track, ringing, multilingual). It never names or distinguishes itself from close siblings like updateAgent, createAgentVersion, or deleteAgent, so an agent gets a clear purpose but no routing signal.

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 one genuine prerequisite (voicemail detection is access-gated on a per-account basis, request access before configuring the `voicemail` object), which is real usage guidance. It stops there: no statement of when to call this instead of updateAgent, whether name uniqueness is required, or what happens on conflict, so it is implied rather than explicit 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 declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds real context — that the campaign dials immediately unless saved as a draft, and that the reference documents refusal messages and their fixes — but says nothing about authorization requirements, side effects on existing campaigns, or idempotency.

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 action and the minimum payload are front-loaded in the first sentence, with the behavior taxonomy following immediately. The second paragraph leans on phrasing about a 'journey' and a guide that isn't contained in the definition, which is slightly promotional but still short and earns its place as a pointer to documentation.

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 deeply nested, behavior-dense tool with 100% schema coverage and annotations covering safety and openness, the description supplies the missing orientation layer: minimum required input and a taxonomy of optional behaviors. Return values are not described, but no output schema exists and the description points to a reference that documents the response.

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 baseline is 3 and the schema does the heavy lifting. The description nonetheless adds a synthesis the schema lacks: it identifies the minimal required trio (name, phone_number_id, contact_list) and groups every remaining field by the single behavior it activates, giving the agent a mental model for progressive configuration.

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 ('Create a new bulk-call campaign') and immediately clarifies the minimum viable payload, so the agent knows exactly what the call produces. It gestures at sibling territory ('the endpoints that operate a campaign once it runs') but never names a sibling tool, so differentiation stays implicit.

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 does say what is needed to 'dial a list now' versus the incremental fields that layer on behaviors (drafts, rotation, filtering, scheduling, retries, dynamic feeding), which is genuinely useful field-selection guidance. However it gives no guidance on when to choose this tool over alternatives such as dispatchCall or createWorkflow, and no prerequisites or exclusions are stated.

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

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

With annotations covering only the safety triad (not read-only, not destructive, closed-world), the description adds substantial behavior beyond them: asynchronous creation with 202/processing, the 429 refusal on limits, the 5/hour, 20/day, 200-stored quotas, and the fact that the consent attestation is recorded against the clone. This is exactly the operational context annotations cannot carry.

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?

Paragraphs are short, front-loaded, and each carries actionable content (formats, async flow, consent, limits). Slight redundancy with the schema on the clip constraints and the consent requirement keeps it from a 5, but nothing is 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?

No output schema exists, and the description compensates by describing the return contract (202 with status: processing), the status states, and how the resulting voice_id is consumed. For a nested-body, async mutation tool, an agent has everything needed 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 description coverage is 100%, so the clip size range (1 KB–25 MB), accepted formats (MP3/WAV/WebM), and consent=true are all already documented in the schema. The description restates these rather than adding syntax or format detail beyond them, so 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?

Opens with a specific verb+resource ('Clone a voice from an audio sample') and immediately names the input medium and accepted formats. An agent can distinguish it from siblings like getClonedVoice, listClonedVoices, and regenerateClonedVoiceSample without opening 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?

Explicitly describes the full workflow: synchronous 202 return, polling GET /voices/{voice_id} until status is ready or failed, then using voice_id with voice.provider cartesia. It also states the consent precondition and the per-user rate limits, so the agent knows both when to call and when a retry will be refused with 429.

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 (write operation, non-destructive, closed-world), the description discloses lifecycle traits (short-lived, single-use, expires), what is returned (`ws_url`), what is not triggered (no audio), and a security constraint (API key must never reach the browser). This is substantial behavioral context an agent cannot derive from the annotation block.

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 paragraph is front-loaded with the core definition and return contract, and each sentence carries weight (lifecycle, return value, server-side handling, security). The trailing pointer to 'Connect the client and talk' refers to documentation outside this definition, which is slightly wasteful, but the structure is otherwise efficient.

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

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

With no output schema, the description carries the return-value burden and does so by naming `ws_url`. Combined with a fully documented input schema and clear role/security guidance, it is nearly complete; only minor gaps remain (e.g., how long the session lives before expiring, error behavior).

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

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

Schema description coverage is 100% and the single nested `requestBody` is documented exhaustively in the schema itself, so the baseline is 3. The description adds no parameter-level detail (agent_id, metadata, custom_variables, post_call_actions) 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 states a specific verb and resource ('Create a voice Session') and immediately defines what a session is: a short-lived, single-conversation reservation. It also positions the tool in the flow ('step 1 of 2') and clarifies what it does NOT do ('does not start any audio on its own'), which cleanly separates it from any call-dispatching sibling.

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 clear context for use ('Call this endpoint from your server with your API key') and the sequencing ('step 1 of 2'), which tells an agent when this tool applies. However, it names no explicit alternative or when-not-to-use condition, so it falls short of a 5.

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

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

Annotations already declare it is a non-readonly, non-destructive, non-open-world write. The description adds real value beyond that: the default draft content, that graph input passes the same validation as editWorkflow ops, and that the response carries the `revision` needed for editing. It does not state the resulting activation/publish state or any permission requirements.

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

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

Four short sentences, front-loaded with the core action, then default behavior, then the graph caveat, then the return contract. No filler; the only overhead is the '(Tags: Workflows)' suffix.

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

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

There is no output schema, and the description compensates by naming the `revision` field returned. The deeply nested graph object is fully documented in the schema. Missing only peripheral context such as the created workflow's initial state.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds conditional semantics the schema cannot: what the draft contains when `graph` is omitted, and the 'only' caveat for supplying it. This meaningfully reduces the chance of over-sending a full graph.

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?

Specific verb+resource: 'Create a workflow with a draft', plus the default behavior (one trigger node) that no sibling tool shares. It also names editWorkflow as the downstream consumer, which anchors this tool's role in the workflow lifecycle.

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

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

Explicit conditional guidance: omit `graph` to get an editable draft, and 'Pass `graph` only to start from a complete graph.' It does not explicitly frame alternatives at the tool level (e.g., why createWorkflow vs. editWorkflow from scratch), but the when/when-not for the key decision is clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds real value beyond them by disclosing the scope of the change ('real events stop running it') and that data is preserved ('the workflow and its draft stay'), which is the key fact an agent needs since the operation is reversible. It omits effects on in-flight executions and any permission requirements.

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 short sentences, effect first, reversibility second, routing to the sibling third. No filler; the tag suffix is the only non-essential text.

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

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

For a one-parameter, no-output-schema state-change tool with annotations covering safety, the description covers purpose, effect, reversibility, and the alternative. Minor gaps remain around in-flight executions and error conditions (e.g. deactivating an already-unpublished workflow).

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents workflow_id fully. The description adds no format, range, or sourcing detail beyond it, which is the expected baseline when the schema carries 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?

Names a specific verb and resource ('deactivate the published workflow') and immediately states the concrete effect: real events stop running it. It also distinguishes itself from related siblings by clarifying the workflow and draft are preserved, implicitly contrasting with deleteWorkflow, and by naming activateWorkflow.

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

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

Explicitly names `activateWorkflow` as the path to re-enable, giving the agent a clear counterpart and the condition that selects it. It doesn't, however, explicitly distinguish this from permanently removing a workflow via deleteWorkflow, leaving that inference to the 'workflow and its draft stay' clause.

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, so the destructive nature is covered. The description adds value beyond that by disclosing the external side effect ('remove it from the provider') and a state-based restriction on deletion, which the annotations do not express.

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: the action first, then the precondition. Every clause carries information and nothing 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 single-parameter destructive tool with full annotation coverage and no output schema, the description covers the action, its external effect, and the key precondition. Only minor details (e.g., what is returned or idempotency on a nonexistent id) are absent, which is acceptable here.

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

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

Schema coverage is 100% with a documented `voice_id`, so the schema already carries the parameter meaning. The description adds no syntax or format detail for the id beyond what the schema provides, 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?

States a specific verb (delete) and resource (cloned voice), plus the additional effect of removing it from the provider. An agent can distinguish it from getClonedVoice, updateClonedVoice, and listClonedVoices without opening a 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?

The description gives a clear precondition/exclusion: a voice still in `processing` state cannot be deleted. It does not name a sibling alternative (which is not really needed for a unique delete operation), but the state gate is explicit and actionable.

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

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is known. The description usefully adds blast-radius context ('The agent's other actions are not changed'), but says nothing about irreversibility, required permissions, or what happens if the action_id is invalid.

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 short sentences, front-loaded with the operation and followed by the scoping caveat; nothing is buried. The trailing '(Tags: Agents)' fragment is metadata padding that earns no place in the prose.

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 destructive tool with full schema coverage and annotations covering the safety profile, the description is nearly sufficient. It is missing only where action_id comes from and an irreversibility confirmation, which are minor against the structured data already 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 required parameters (agent_id, action_id) are fully documented in the schema. The description adds no format, range, or sourcing information beyond that, which is the expected baseline when the schema does the work.

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 ('Remove') and resource ('one post-call action from the agent'), and the second sentence scopes the effect to a single item. It does not name the sibling tools it sits beside (addPostCallAction, updatePostCallAction, listPostCallActions), but an agent can still tell what this does and how its blast radius is bounded.

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 when-to-use or when-not-to-use guidance. Nothing tells the agent to use listPostCallActions to obtain the action_id first, nor how this differs from updatePostCallAction, which is the natural sibling confusion point.

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, but the description adds concrete behavioral context beyond them: the published version stops running, the action is irreversible, and user confirmation is required. It doesn't cover auth needs or rate limits, but for a single-resource delete this is strong added 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?

Three short sentences, each earning its place: the action, the consequence, the irreversibility/confirmation warning, and the alternative. The consequence and alternative are front-loaded with zero waste.

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

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

For a simple one-parameter delete with annotations covering safety and no output schema, the description supplies everything an agent needs: the effect on the published version, irreversibility, confirmation requirement, and the non-destructive alternative.

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 single `workflow_id` parameter is fully documented in the schema. The description adds no syntax, format, or meaning beyond what the schema already provides, 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 and resource ('Delete a workflow') and explicitly distinguishes itself from the sibling `deactivateWorkflow` by explaining that the latter stops a workflow without deleting it. An agent can route correctly without opening 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?

It gives explicit when-to-use guidance ('Delete a workflow'), a when-not alternative ('To stop it without deleting, use `deactivateWorkflow`'), and a required precondition ('confirm with the user first'). Nothing is 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?

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 already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond restating the operation: it doesn't clarify whether the number is merely unassigned or freed, whether the agent is affected, or whether the action is reversible, despite the destructive flag.

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 short sentence front-loads the verb and resource with no wasted words, followed only by a tag. It is appropriately sized, though the minimal content leaves room that could have been used for the missing behavioral context.

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

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

For a simple single-parameter operation whose annotations cover the safety profile and whose schema covers the parameter, the description is minimally sufficient. However, the ambiguous consequence of a destructive detach (reassignment vs. permanent removal) is left entirely to the agent to guess.

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 only one parameter exists, so the schema fully documents phone_number_id. The description adds no syntax, format, or ID-source information beyond what the schema already provides, matching the baseline 3 for schema-heavy definitions.

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 ('detach') and resource ('phone number') plus the source relationship ('from its agent'), so the effect is unambiguous. It does not explicitly distinguish itself from the sibling attachPhoneNumber, though the antonym is self-evident from the name.

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 when-to-use guidance, prerequisites, or alternatives are given. Nothing tells the agent when to detach versus releasePhoneNumber or other number-management siblings, leaving selection 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 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 declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the agent knows this is a mutating, externally-visible operation. The description adds the number-format requirement but says nothing about real-world consequences (a live outbound call is placed), cost, or that post-call actions supplied here override the agent's configured actions for this call only.

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 short sentences, front-loaded with the action and followed by the one hard constraint. Nothing is padded, though the parenthetical '(Tags: Calls)' is noise that adds no selection value.

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

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

For a tool that triggers a real, destructive, open-world outbound call with a deep nested payload, the description is thin: no return value (e.g. call id), no auth or balance prerequisites, and no differentiation from bulk-call siblings. With no output schema, the description should carry more of that burden.

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 single requestBody parameter is documented exhaustively, including agent_id, to_number, metadata, languages and the large post_call_actions tree. The description merely restates the to_number format already in 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?

States a specific verb and resource ('Initiate a call to a phone number using a specified agent') with a concrete constraint on the number format. It is clear on its own but never distinguishes itself from sibling tools such as createBulkCall or createSession, which an agent could reasonably confuse with a single outbound dispatch.

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 only guidance is a data-format rule ('must include a country code with a leading plus'), which is really a parameter constraint. There is no statement of when to use this versus createBulkCall for volume dialing, nor any prerequisite such as needing a valid agent_id or an available from number.

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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing atomicity ('apply all together or not at all'), optimistic-concurrency behavior (mandatory revision, 409 retry loop), secret round-trip masking ('********' must be sent back unchanged), and draft-vs-live scope. These are exactly the behavioral traits an agent cannot infer from the structured fields.

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

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

Front-loads what the tool does, then the atomicity constraint, the revision requirement, the error path, and the draft-vs-publish distinction. Every sentence carries an operational fact and none is padding.

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 nested ops and no output schema, it covers everything an agent needs: scope (draft only), concurrency contract, atomicity, secret handling, and the escalation path to publishWorkflow. No relevant behavior is left unstated.

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 op-level table already documents every field per operation, so the description's op list and secret/revision notes are largely duplicative. It does add one genuinely non-schema fact, that the ops apply atomically, which justifies going above the baseline 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 opening sentence names a specific verb (change/edit) and resource (the draft) and enumerates the op families: add, update, move, delete nodes, connect/disconnect. It also explicitly separates itself from the sibling publishWorkflow, so an agent can distinguish it without opening either 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?

States the condition that selects this tool ('edits the draft only') and names the alternative for the other intent ('Use publishWorkflow to make it live'). It also gives the required precondition (send the revision from your last read) and the recovery path for the 409 revision_conflict case, which is explicit when/when-not 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, 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 only supply readOnlyHint/openWorldHint; the description adds real behavioral context the schema cannot: a zero balance does not always halt calls for usage-based billing orgs, and the call requires Billing access with a documented 403 remedy path. This is exactly the kind of non-obvious operational detail that prevents wrong agent conclusions.

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

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

Front-loaded with what the call returns, then usage timing, then edge cases and auth. Every section earns its place, though the seven-paragraph layout is longer than strictly necessary and could be tightened without losing the 402/403/zero-balance guidance.

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

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

With no output schema, the description carries the burden of describing the return payload and does so (balance, minutes, plan, concurrency, auto-recharge). Combined with scope, timing, and auth/error handling, an agent has everything needed to call it correctly and interpret 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?

Zero parameters, so the schema-based baseline of 4 applies. The description usefully clarifies that the absence of parameters is intentional and scope is fixed to the API key's organization, but there is no parameter syntax to document.

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 ('Read your organization's wallet') and enumerates exactly what the payload contains: balance, minutes at your rates, plan, concurrency headroom, auto-recharge. No sibling tool covers account balance, and the description makes the scope unambiguous.

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

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

Gives explicit when-to-use ('before a campaign, or on a schedule') with the rationale (surface low credit here rather than via a 402), and an explicit when-not/alternative ('there is no parameter for reading another account; resellers read a client's figures through the Reseller endpoints').

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 safety profile is covered. The description adds one genuinely useful behavioral detail beyond the structured data – that the response carries a can_publish boolean tied to organization version-history settings – but omits other return-value 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?

Two sentences, front-loaded with the core action, and the trailing tag is minor overhead. It is efficient and easy to scan.

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

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

With no output schema, the description carries the burden of describing return values, yet it names only one field (can_publish) out of the full agent detail object. Annotations cover the safety profile, but the return-shape picture remains partial.

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 single agent_id parameter is already documented in the schema as 'The ID of the agent.' The description adds no format or type detail beyond that, so 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 a specific verb and resource ('Get details of a specific agent by ID'), which clearly distinguishes a single-record fetch from the list-oriented siblings like listAgents. It does not explicitly name an alternative, so it stops short of the 5-level sibling differentiation.

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 when-to-use guidance and no mention of alternatives such as listAgents or listAgentVersions. The agent must infer usage from the name and ID parameter 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 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?

Annotations already declare readOnlyHint=true and openWorldHint=false so the safety profile is covered. The description adds that the response includes creation status, a useful behavioral detail, but nothing about errors for invalid/missing voice_id.

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

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

A single compact sentence, front-loaded with the resource and disclosing the key returned field. Zero waste.

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

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

For a simple one-param read tool with annotations and a fully-described schema and no output schema, the definition is nearly complete. Only minor gap is not stating behavior on unknown voice_id or that status values are enumerated.

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?

Single required param with 100% schema coverage; the schema describes voice_id fully. The description adds nothing beyond 'a cloned voice' which the schema already conveys, 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?

States a specific verb+resource: retrieves a single cloned voice, and calls out the creation status. It contrasts implicitly with listClonedVoices and sibling getVoice, though it doesn't explicitly differentiate.

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 singular 'one cloned voice' versus the plural listClonedVoices sibling, but there is no explicit when-to-use or when-not-to-use guidance.

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

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

Beyond readOnlyHint/openWorldHint, it discloses the auth requirement (API key in the Authorization header), the ownership restriction, and the specific error code for a missing sample. These are exactly the operational traits annotations cannot convey.

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

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

Three tight sentences: purpose first, then access constraint, then error/auth conditions. No filler, and the most decision-relevant fact (what it returns) 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?

For a single-param streaming getter with no output schema, the description covers purpose, ownership, error behavior, and auth. It is nearly complete; only the recovery action for sample_not_ready (regenerate) is unstated.

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 voice_id is already documented in the schema. The description adds no syntax, format, or constraint detail about the parameter beyond what the schema provides, 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?

States a precise verb and resource: 'Stream the generated mp3 sample of a cloned voice.' This is clearly distinguishable from siblings like getClonedVoice (metadata) and regenerateClonedVoiceSample (which produces, not fetches, the sample). An agent can route to it without opening 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?

Gives clear conditions: owner-only access and a 404/sample_not_ready state when no sample exists yet. It does not, however, explicitly route the agent to regenerateClonedVoiceSample when the 404 occurs, so the alternative path is left 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 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?

With readOnlyHint already covering the safety profile, the description adds real value: secrets are masked as `********`, and the revision is a precondition for edits. This is behavioral context the annotations do not convey, though return/pagination specifics are absent.

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

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

Front-loaded with what it returns, then the usage trigger, then the view tip, then the secret-masking note. Every sentence carries distinct information with no filler.

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

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

No output schema exists, so the description carries the return-shape burden, and it does name the key fields (draft, status, revision). For a two-parameter read tool this is nearly complete; minor gaps remain on error/not-found behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's note on `view=structure` (nodes and edges without config) largely restates what the schema already documents, adding little beyond the enum description.

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

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

Specific verb (get) and resource (one workflow), and it enumerates what is returned: draft, status, and `revision`. This clearly separates it from listWorkflows (singular vs list), but no sibling is named explicitly, so it stops short of the top band.

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?

Gives a concrete when-to-use rule: 'Call it before every edit to get the current `revision`.' It also adds a conditional for `view=structure` on large workflows. No explicit when-not-to-use or named alternative tool, so it's clear context rather than full routing 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 openWorldHint=false, so the safety profile is covered. The description adds the completion-state semantics, which is useful beyond the annotations. However, it doesn't disclose return shape, pagination, or how results are structured per step, leaving some behavioral gaps for a read tool with no output schema.

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

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

Three short sentences, front-loaded with the resource identity, followed by usage and completion semantics. Every sentence contributes.

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

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

Complete enough for a read-only retrieval tool whose annotations cover safety and whose two params are fully documented in schema. Without an output schema and with a per-step result payload, the description could say more about the return structure, but the essential calling context 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 coverage is 100%, so the baseline is 3, but the description adds meaning by explaining execution_id as coming from testWorkflow – a provenance hint the schema also touches on. It doesn't add syntax detail beyond the schema, keeping it modestly above baseline.

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 resource ('one run of a workflow, with the result of each step') and a concrete use ('read the outcome of testWorkflow'). It clearly distinguishes itself from getWorkflow and testWorkflow in the sibling list.

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

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

Names the action it pairs with ('read the outcome of testWorkflow') and gives the terminating condition for use ('a run is finished when state is completed, failed or cancelled'). This routes the agent from testWorkflow to this tool for retrieving results.

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 safety profile is covered. The description adds real behavioral context beyond that: the returned `fields` are the config keys for the node, and `detail=full` expands the response with descriptions, examples and output_example, which tells the agent what a heavier 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?

Two tight sentences with zero filler; the primary purpose and the pre-edit usage rule are front-loaded, and the detail-param caveat follows as secondary guidance.

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

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

No output schema exists, yet the description still characterizes the return (settings with types, required flags, outputs, and what full detail adds). Combined with full param coverage and read-only annotations, an agent has everything needed 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 baseline is 3. The description earns above baseline by explaining the practical trade-off of `detail=full` (help text and examples, use only when needed) and by tying `node_type` semantics to the config-key relationship, adding meaning the enum/default alone doesn't convey.

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: it returns the settings one node type reads, including types, required flags and outputs. It's clear what comes back, but it never explicitly names its closest sibling (listWorkflowNodeTypes) to contrast the single-type lookup against the listing, leaving that distinction to 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?

Gives a concrete when-to-use rule ('Call it before you add or edit a node') grounded in a reason (its fields are the keys of the node's config), and adds a when-to-use for the detail param. It stops short of stating when not to use it or naming an alternative 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 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 disclose readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context on top of that - no mention of auth/permissions, whether the number must be verified, or what state change occurs on import. It essentially restates the verb already in the name.

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

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

A single front-loaded sentence carrying the core action, plus a short tag line. Nothing is padded, though the tag '(Tags: Phone numbers)' is metadata rather than instruction and the sentence is arguably too terse for the underlying complexity.

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

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

This is a mutation tool wrapping a 10-property nested object with no output schema, yet the description says only that it imports a number. It omits anything about prerequisites, side effects, or how the import relates to the attach/detach and other provider-import siblings, which is not sufficient for a tool of this complexity.

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

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

Schema description coverage is 100%, so the nested requestBody and all ten fields (sip_host, sip_port, phone_number, sip_trunk_name, sip_strip_country_code, etc.) are already fully documented in the schema. The description adds nothing about parameter meaning, so 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 gives a specific verb (Import) and resource (a phone number associated with a SIP trunk), which is enough to separate it from generic number tools like purchasePhoneNumber or searchPhoneNumbers. However, it never differentiates itself from the near-identical siblings importTwilioNumber and importExotelNumber, so the agent must infer the distinction from the name alone.

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 explicit when-to-use guidance and no named alternatives. Given that importTwilioNumber, importExotelNumber, attachPhoneNumber and purchasePhoneNumber all exist as competing ways to get a number onto the account, the description should route the agent but does not.

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?

With readOnlyHint=true already declaring the safety profile, the description still adds real behavioral content: result ordering (newest first) and the fact that results mix manual (named), automatic, and pre-restore system backup versions. It stops short of describing pagination behavior or result shape, and it does not clarify how the three listed kinds map onto the two-value `kind` filter.

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 tight sentences with the core action and ordering front-loaded, no redundancy. The trailing "(Tags: Agents)" line is inert metadata that adds no selection or invocation value, keeping it out of the top band.

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

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

For a read-only listing tool with fully documented parameters and annotations, the description covers what is returned and in what order. However, with no output schema, it says nothing about the shape of a version entry (IDs, names, timestamps) that an agent would need to chain into diffAgentVersion or restoreAgentVersion.

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 pageno, pagesize, search, agent_id, and the kind enum are all already documented; baseline 3 applies. The enumeration of version kinds is tangential to the `kind` parameter rather than explaining it, and the ambiguity between "automatic" and "system" versions is left unresolved.

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+resource ("List an agent's saved versions") plus ordering ("newest first") and the three version types returned. That is enough to distinguish it from diffAgentVersion, restoreAgentVersion, and renameAgentVersion by verb alone, but the description never explicitly names those siblings as 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?

Usage is only implied: an agent can infer this is the enumeration step before diff/restore/rename, but there is no explicit when-to-use statement and no mention of adjacent tools such as getAgent or diffAgentVersion. No exclusions or prerequisites are given.

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

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

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 cover the safety profile (readOnlyHint, openWorldHint=false), so the bar is lower. The description still adds real context: deterministic oldest-first ordering, cursor-loop pagination semantics, and a state gate (only ready voices have a usable voice_id).

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 ordering and pagination rule come first, which is the right priority, and the whole thing is three short sentences. The trailing '(Tags: Voice cloning)' is filler that earns nothing.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming next_cursor and the ready/voice_id fields. An agent has enough to page correctly and to consume results, though the full voice object shape is never sketched.

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 both parameters are already documented with defaults, max, and opaque-cursor notes. The description restates the cursor contract but adds no new syntax or constraints beyond the schema, making the baseline 3 correct.

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 resource (cloned voices) and result ordering (oldest first), which cleanly separates it from listVoices and getClonedVoice. It never uses an explicit verb like "list," but the phrasing leaves no ambiguity about what is returned.

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 concrete call procedure (call with no cursor, then loop on next_cursor until null) and explains the downstream action once a voice is ready (use voice_id with provider cartesia). It does not, however, say when to prefer this over listVoices or getClonedVoice.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that credentials (tokens, secrets, passwords, API keys, custom API header/param values) are masked as `********`, that `********` is rejected on create, and that certain OAuth providers are dashboard-managed. This is exactly the behavioral context annotations cannot convey.

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

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

Front-loads the purpose, then adds masking and creation caveats. The sentence about 'when you create an integration' is slightly tangential to a list operation, but it clarifies the meaning of the masked value, so it earns its place.

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

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

With no output schema, the description carries the return-value burden and does so: it names the returned fields and the masking format. For a zero-parameter read tool, nothing needed to call it correctly is missing.

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

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

The tool takes no parameters, so the baseline is 4. There is nothing to document, and the description appropriately focuses on output behavior instead.

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 ('List the integrations connected to your workspace') and specifies the returned fields (`id` and `integration_type`). It is clearly distinguishable from the many sibling list* tools (listAgents, listWorkflows, listVoices) since it names the exact resource.

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?

Gives clear context: stored credentials are never returned on this read, real values must be sent when creating an integration, and OAuth-based providers are connected via the dashboard rather than here. It does not name a specific sibling alternative, but the conditions for use are well stated.

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

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral detail — that each action carries an `id`, hinting at how update/delete siblings are targeted — but says nothing about pagination, ordering, or what an agent-less agent_id returns.

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 short front-loaded sentence that carries the essential scope and return shape; the trailing '(Tags: Agents)' is metadata noise rather than content, but the body itself wastes nothing.

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 tool with full schema coverage, annotations carrying the safety profile, and no output schema, the definition covers what an agent needs. Only the return format (whether actions include trigger config, ordering) is left implicit.

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 a single required parameter and 100% schema description coverage, the schema already documents agent_id fully. The description's phrase 'on the agent' only restates that scoping without adding format or constraint detail, so 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?

States a specific verb (List) and resource (post-call actions) scoped to the agent, and notes each entry carries its own `id`. The verb naturally separates it from the add/update/delete siblings, though the description never names them explicitly.

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 when-to-use guidance, no prerequisites, and no mention of the sibling tools (addPostCallAction, updatePostCallAction, deletePostCallAction) that an agent would need to choose between. The text only asserts what the tool returns.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds a genuinely non-obvious behavioral trait: filtering support is provider-conditional, and non-ElevenLabs/Cartesia providers degrade to pagination-only. It omits whether unsupported filters are silently ignored or error out.

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 compact sentences front-load the capability and then the provider-conditional caveat; nothing is redundant. The trailing "(Tags: Providers)" is low-value noise but minor.

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, no-required-argument list tool with no output schema and annotations covering safety, the description supplies the one thing structured fields cannot: provider-dependent filtering behavior. The only real gap is the outcome when a filter is passed to an unsupported provider.

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 every parameter is already documented in the schema with types, enums, defaults, and provider notes. The description's mention of name/language/accent/gender filters merely restates that coverage and adds no syntax or semantics beyond it, so 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?

States a specific verb ("Retrieve") and resource ("voices") and pairs it with the filtering/pagination scope, which distinguishes it from getVoice (single) and listClonedVoices (cloned subset). It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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 useful context that advanced name/language/accent/gender filtering only applies to ElevenLabs and Cartesia while other providers support pagination only, effectively telling the agent when a filter will have an effect. However, it never says when to pick this over getVoice or listClonedVoices, so alternative selection is 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 declare read-only and closed-world. Description adds the `400 no_options` error case and instructs to ask the user, which is useful error-handling behavior not in annotations. However, it doesn't describe return format beyond 'choices'. With annotations covering safety, this adds moderate 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?

Two sentences plus a tag. Front-loads the purpose and immediately follows with usage and error guidance. No filler.

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

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

For a simple list tool with full schema coverage and read-only annotations, the description covers purpose, usage, and error handling. It does not describe output format, but with no output schema and a straightforward list return, this 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 descriptions are 100% coverage, so the baseline is 3. Description hints that the field is a '`ref` field' and that `depends` relates to a dependency, but adds no syntax or format details beyond the schema's own descriptions.

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

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

States it returns 'choices for one `ref` field of a node type' and gives examples (phone numbers, agents, integrations). This distinguishes it from `listWorkflowNodeTypes` and `getWorkflowNodeType`, which deal with node types rather than field options. Clear and specific.

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

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

Tells when to use ('for every `ref` field', 'never guess an id') and when not to ('400 no_options' means ask the user). Provides explicit error-handling guidance and a fallback behavior. No other tool alternatives are named, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the discovery-then-detail sequencing, but says nothing about pagination, result size, or whether the listing is exhaustive or filtered server-side — behavior an agent would want for a search endpoint.

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 short sentences that front-load the purpose and then the routing advice, with a parenthetical tag that costs nothing. 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 two-parameter, read-only list tool with fully documented params and no output schema, the description covers the essential decision (use this before `getWorkflowNodeType`). The only minor gap is the shape of the returned node-type list, which matters somewhat since no output schema exists.

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 both parameters are documented in the schema (including the full category enum), so the schema does the heavy lifting. The description's example terms overlap with the `q` parameter description but add no new semantics, so 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?

States a specific verb (search/list) and resource (node types a workflow can use), with concrete examples (`whatsapp`, `voice_ai`, `conditional`) that make the resource unambiguous. It also implicitly distinguishes itself from the sibling `getWorkflowNodeType`, which is named for the per-type lookup.

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

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

Explicitly positions the tool in a workflow: call it first when you do not know which node to add, then call `getWorkflowNodeType` for the settings of a single type. This is a clear when-to-use plus a named follow-up alternative, leaving nothing 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond them: result ordering is oldest-first and the caller must keep passing next_cursor until it is null, which tells the agent exactly how to drain the result set.

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 short sentences plus a tag; the scoping fact (oldest first, paginated) leads and the terminal condition follows. Nothing is padded and no sentence is 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 paginated list tool with no output schema and full annotation coverage, the description supplies what an agent actually needs: ordering, page-slicing, and the loop termination condition. It stops short of hinting at what a workflow record contains, which is a minor gap rather than a blocking 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 limit and cursor already documented, so the baseline is 3. The description reinforces the cursor loop ('pass back next_cursor until it is null') but adds no syntax, bounds, or default information the schema does not already carry.

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 the resource (your workflows) plus its ordering (oldest first) and pagination model, which is enough to separate it from getWorkflow, createWorkflow, and the node-type listers. It never uses an explicit verb like 'list', but 'one cursor page at a time' plus the plural resource makes the read-listing intent unambiguous.

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

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

'Use it to find a workflow id' gives a concrete reason to call it, which is more than most siblings. However, no alternative is named (e.g. getWorkflow for a single known id) and there are no conditions for when not to use it, so the routing guidance is implied rather than explicit.

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