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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the mutation and safety profile is covered. The description adds one useful behavioral constraint (custom_fields keys must match the workspace's custom fields), but says nothing about duplicate handling or what happens to an existing phone number, which is notable given idempotentHint=false.

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 no filler, and the core action is front-loaded before the custom_fields constraint. Nothing redundant or padded.

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

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

For an 8-parameter, nested-object mutation tool with 25% schema coverage and no output schema, the description is too thin. It omits what is returned on success, duplicate/conflict behavior, and semantics for most 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?

Schema description coverage is only 25% (list_id and description), so the description is expected to compensate but does not. It explains only the custom_fields key constraint and leaves phone, email, first_name, last_name, and job_title semantics entirely to the schema's types and constraints.

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

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

States a specific verb and resource ('Add a contact to a contact list'), which clearly separates it from the list_contacts and create_contact_list siblings. It stops short of explicitly naming or contrasting with any sibling, but the purpose is unambiguous.

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

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

There is no guidance on when to use this versus qcall_create_contact_list or qcall_list_contacts, and no stated prerequisites or exclusions. The only quasi-guidance is the custom_fields key constraint, which is a data requirement rather than usage context.

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

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

Annotations already declare the safety profile (write op, not read-only, not destructive, not idempotent, open world), so the bar is lower. The description adds genuine context beyond that: settings deferred to the web app and the workspace-default voice fallback behavior 'until a voice is chosen'. It still omits that repeated calls create duplicate assistants despite idempotentHint=false, and says nothing about auth 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?

Two tight sentences, front-loaded with the core action before the caveat about where voice/model are set. The parenthetical URL and arrow notation are slightly heavy but still earn their place by pointing the user to the relevant app screen.

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 eight-parameter mutation tool with no output schema, the definition covers the essential inputs, the deferred-configuration workflow, and the default-voice behavior, which is enough to call it correctly. The main gap is the absence of any note on duplicate creation or required permissions, though annotations partly compensate.

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

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

Schema description coverage is 100%, so every parameter is already documented, which sets the baseline at 3. The description names the four required fields (name, goal, company, script) but adds no syntax, format or meaning beyond the schema, and is silent on the four optional parameters.

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

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

States a specific verb and resource ('Create an AI voice assistant') plus the four required inputs, which is unambiguous and clearly distinct from the list/get/update assistant siblings. It stops short of explicitly naming a sibling or scoping what this tool is not, so it is clear but not maximally 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?

The description usefully tells the agent that voice, AI model and knowledge base are configured in the QCall app rather than here, which is a real routing hint for the caller. However it gives no explicit when-to-use vs alternative guidance (e.g., create_knowledge_base first, or when to prefer update_assistant), leaving usage largely 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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral state — the campaign is created but NOT started — which prevents the agent from assuming calls begin immediately. It omits what happens on invalid dialer/segment ids and confirms no idempotency behavior 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?

Two sentences, zero filler, and the critical constraint (created, not started) plus the follow-up action are both front-loaded. Every clause earns its place.

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

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

For a 7-parameter mutation tool with full schema coverage, no output schema, and helpful annotations, the description covers purpose, state, and next step adequately. The only gap is that it never says a campaign identifier is returned/needed to invoke qcall_start_campaign, which the agent must infer.

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 explains every parameter, including cross-references to qcall_list_dialers and IANA timezone format. The description adds only indirect meaning ('every contact in a list' implies segment_id is a contact list) and names no parameter explicitly. Baseline 3 applies when the schema carries the load.

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 an AI calling campaign') plus the scope of what the campaign does ('calls every contact in a list with an assistant'). This clearly separates it from siblings like qcall_start_campaign, qcall_place_call, and qcall_create_contact_list without the agent needing to open any 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 routes the agent forward: 'use qcall_start_campaign after the user approves,' establishing both the sequence and the approval gate. It does not state when *not* to use this tool or contrast it with alternatives like qcall_place_call for one-off calls, so it stops just short of the top score.

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, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that base: it does not explain duplicate-name handling, whether re-creating an existing list fails, or any post-creation side effect, which is a meaningful gap for a non-idempotent mutation.

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 short, front-loaded sentence with no filler. It is not bloated, but its brevity reflects under-specification rather than disciplined economy.

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 3-parameter create tool with low schema coverage and no output schema, the description is too thin. It omits the required parameter, the duplicate-allowed option, and any return/error behavior, so an agent cannot call it confidently from the description alone.

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

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

Schema description coverage is only 33% (just is_duplicate_allowed documented), so the description must compensate, but it says nothing about any parameter. It does not note that 'name' is required or explain the description field's role.

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 contact list') and adds the '(segment)' synonym, so an agent can distinguish it from sibling list/create tools like qcall_create_campaign or qcall_create_assistant. It is clear, though it offers no explicit sibling differentiation beyond the resource 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?

The description gives no when-to-use, when-not-to-use, or alternative routing guidance. It does not say how a contact list relates to qcall_add_contact or qcall_list_contact_lists, leaving usage entirely 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=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety and repeatability profile is covered structurally. The description adds that input is plain text rather than files and that the result feeds assistants, but it omits size limits (100k chars), duplicate-creation behavior, and any auth/permission notes, so it only modestly exceeds 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?

A single front-loaded sentence with no waste; the verb and resource lead, and the parenthetical content examples earn their place. Slightly more brevity or a second clarifying clause would be needed for a 5.

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 three-parameter creation tool with no output schema and modest annotation coverage, the description covers what goes in but not what comes back (e.g., a knowledge base ID needed for later attach/update operations) or whether duplicate titles are allowed. Adequate but leaves gaps an agent would have to discover by calling.

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 67%: 'data' and 'language' are documented in the schema, and 'title' is self-describing. The description's 'plain text' phrasing reinforces the format of the required 'data' parameter but adds no format, length, or language-handling detail beyond the schema. 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 and resource ('Create a knowledge base') and clarifies the accepted content ('plain text (FAQs, product details, policies)') plus the downstream consumer ('assistants can answer from'). It does not explicitly contrast itself with the sibling qcall_list_knowledge_bases, but the create-vs-list distinction is self-evident from the verb.

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 scenario (content assistants should answer from) but gives no explicit when-to-use guidance, no prerequisites, and no mention of alternatives or follow-up tools. An agent gets context but no routing rules.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds only the scope of returned data (name, limits, renewal) and says nothing about auth requirements, caching, or freshness of the plan data, so it adds modest value over 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?

A single tight sentence with the resource named first and the payload summarized in a parenthetical. No filler, nothing to trim.

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, so the description usefully compensates by naming the key returned fields (name, limits, renewal). For a zero-required-parameter read tool this is nearly sufficient, though it omits any note about what happens when no plan is active.

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 response_format parameter is fully documented with its enum and default in the schema. The description adds nothing about the parameter, 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 and resource ('Get the workspace's active QCall subscription plan') and enumerates the returned fields (name, limits, renewal), which makes the purpose unambiguous. It does not, however, distinguish itself from the closest sibling qcall_get_balance, which an agent could plausibly confuse with plan/limits retrieval.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as qcall_get_balance for monetary queries. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the configuration contains, but says nothing about auth requirements, error behavior when the id is invalid, or whether fields can be null.

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 with no wasted words; the field enumeration earns its place by previewing the payload. It is terse but not truncated.

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 getter with no output schema, the description helpfully previews the returned configuration fields, compensating for the absent output schema. Missing only edge-case behavior (invalid id, null fields), which is minor for this tool class.

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 parameters (assistant_id and response_format enum) are fully documented in the schema itself. The description's field list describes the return content rather than the parameters, so it adds no parameter-level meaning beyond the schema; 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 ('Get') and resource ('one assistant's configuration'), and enumerates the fields returned (goal, script, greeting, voice, model, transfer number). The singular 'one' implicitly distinguishes it from qcall_list_assistants, but no sibling is named 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?

Usage is only implied: fetching a single, already-identified assistant versus listing them. There is no explicit when-to-use, no exclusions, and no mention of alternatives like qcall_list_assistants or qcall_update_assistant.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value by explaining the wallet's billing role, but says nothing about auth requirements, rate limits, or whether the balance is cached/real-time.

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 core action, followed by the billing rationale and return fields. No filler or redundancy.

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

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

For a zero-required-parameter read tool with no output schema, the description is nearly sufficient: it names the returned fields (amount, currency) and explains the wallet's purpose. Auth and freshness semantics are the only untold details.

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

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

Only one optional parameter (response_format) and schema description coverage is 100%, so the schema fully documents its enum values. The description adds no parameter detail, which is the expected baseline when the schema carries the burden.

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

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

States a specific verb and resource ('Get the QCall wallet balance of the connected workspace'), and the billing note distinguishes it from other read tools like qcall_list_transactions or qcall_get_active_plan that also expose account-level financial data.

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 clear use condition: 'check it before placing calls,' which ties the read to a concrete workflow. It does not name alternatives or state when not to use it, but the trigger context is unambiguous.

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, idempotent and non-destructive behavior, so the safety profile is covered. The description adds behavioral value by naming the concrete return payload (transcript, recording URL, duration) in the absence of an output schema. It does not mention auth requirements or rate limits, which keeps it short of a 5.

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

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

Two sentences, no filler, with the returned fields and the SID source front-loaded and the alternative-tool note last. Every clause earns its place.

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

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

For a two-parameter read tool with full annotation coverage and no output schema, the description covers purpose, parameter origin, return content and routing. The only minor gap is that it doesn't mention the response_format choice, though the schema documents it adequately.

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 baseline is 3. The description goes beyond the schema by adding provenance for `call_sid` (it comes from qcall_list_campaign_call_logs), which genuinely helps an agent supply the right value.

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

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

States a specific verb (Get) plus the exact resources returned (transcript, recording URL, duration) and scopes it to a campaign call identified by call SID. It also distinguishes itself from qcall_list_calls, so an agent can separate the two 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?

Explicitly tells the agent where the required `callsid` comes from (qcall_list_campaign_call_logs) and states the exclusion rule: 'For single calls, the transcript is already in qcall_list_calls (json).' When-to-use and when-not-to-use are both present.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only that results are workspace-scoped aggregate statistics mirroring the dashboard, which is useful framing but not rich behavioral detail (no time-window semantics, no aggregation rules).

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 that states verb, scope, and returned metrics with zero filler. Every clause earns its place.

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

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

For a read-only, zero-required-param tool with no output schema, the description partially compensates by naming the four metric families returned. Slightly incomplete in that it gives no sense of time window or aggregation granularity, but adequate for correct invocation.

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

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

There is one optional parameter with 100% schema description coverage, including a documented enum (markdown vs json) and default, so the schema does the heavy lifting. The description adds nothing about response_format or output shaping, 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 names a specific verb (Get) and resource (workspace call statistics) and enumerates the metrics returned (totals, answered, minutes, spend). It distinguishes itself reasonably from sibling read tools such as get_balance and get_active_plan by naming the call-statistics scope, though it never explicitly contrasts with them.

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

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

There is no statement of when to use this tool versus alternatives, nor any prerequisites or excluded cases. The 'as shown on the QCall dashboard' phrasing implies a summary/reporting context, but the agent must infer it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered without the description. The description contributes the cross-tool id contract but says nothing about pagination, result size, or ordering; with annotations doing the heavy lifting, a 3 is appropriate.

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

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

Two short sentences, zero filler, and the core purpose is front-loaded before the downstream id hint. Nothing here is redundant with the schema or annotations.

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, zero-required-parameter list tool with full schema coverage and rich annotations, this covers purpose plus the key downstream contract. Minor omissions (pagination, whether all assistants or a filtered subset are returned) keep it from being fully complete, and there is no output schema to lean on.

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 optional parameter with 100% schema description coverage, and the enum values ('markdown' vs 'json') are already fully explained in the schema. The description adds no format-selection guidance 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?

States a specific verb and resource ('List the workspace's AI voice assistants'), which cleanly separates it from the singular qcall_get_assistant and the create/update siblings. It stops short of explicitly naming those siblings or the scope boundary (e.g., all assistants vs. filtered), so it is clear but not maximally 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?

Adds a genuine usage cue: the returned `id` is consumed as `assistant_id` in call and campaign tools, which tells an agent when this lookup is a prerequisite. It does not say when to prefer this over qcall_get_assistant (e.g., for a single known assistant), so exclusions are absent.

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, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real behavior beyond that: results are sorted newest-first, which fields are surfaced, and that json mode exposes the transcript and recording_url while markdown is the default summary. It does not mention pagination limits or empty-result behavior, keeping it short of a 5.

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, zero filler, with the core listing behavior front-loaded before the format guidance. Nothing is redundant, though it stops just short of a maximally economical definition.

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 burden of describing returns and does list the returned fields, plus the format switch that controls readability. Filtering behavior on status/sentiment is the remaining gap, but for a 5-param, 0-required read tool it is largely complete.

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

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

Schema coverage is 60%, so the schema already documents page, perpage and response_format. The description adds meaning for response_format (json exposes transcript and recording_url) but is silent on the status and sentiment filters, which are enum-constrained in the schema but unexplained in either place as meaningful query narrowing.

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 single calls placed from the playground/API') and adds scope details: ordering (newest first) and returned fields (status, duration, cost, sentiment). The qualifier 'single calls' distinguishes it from the sibling qcall_list_campaign_call_logs without needing to open 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?

Implies usage by noting that response_format=json is how you read transcripts and recording URLs, which is a useful routing hint. However, it never states when to use this list tool versus qcall_get_call_transcript or qcall_list_campaign_call_logs, so selection among siblings 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the workspace-wide scope and a date-format convention, but says nothing about pagination behavior or result shape, so it adds only modest value beyond structured fields.

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

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

Two short sentences with the core scope front-loaded and zero filler. The closing date-format sentence is somewhat redundant with the schema pattern but still earns its place by clarifying the two undocumented date params.

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 need not explain returns for a read-only list tool whose annotations cover the safety profile. It remains incomplete on pagination and why one would choose it over qcall_list_calls, keeping it out of the top band.

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 57%: status, perpage and response_format are documented in the schema, while fromDate/toDate carry only a regex pattern and sentiment has none. The description partially compensates by specifying the YYYY-MM-DD date format, but adds no meaning for filtering semantics like what 'all' sentiment includes.

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

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

The description states a specific verb and resource — 'List calls made by campaigns across the workspace' — which is clearer than a bare 'list calls'. However, it never names the sibling qcall_list_calls or explains how campaign-scoped logs differ from the generic call list, so an agent must infer the distinction.

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 statement of when to use this tool versus alternatives such as qcall_list_calls or qcall_list_campaigns. No prerequisites, no exclusions, and no routing guidance are given, leaving the agent to guess from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that status is returned, without noting default page size, pagination behavior, or result ordering.

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 short sentence with the core action front-loaded and no filler. It is efficient, though extremely terse for a tool that returns paged data.

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 must carry the return-value burden; it only vaguely says 'with their status'. For a simple read-only list tool with fully documented parameters this is minimally adequate, but an agent gets no sense of the response shape or paging 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 page, perpage, and response_format are already documented in the schema. The description contributes no additional parameter meaning beyond what the schema provides, making the baseline 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?

States a specific verb and resource ('List AI calling campaigns') and adds that status is included in the result. It is clear on its own, but offers no differentiation from the many sibling list_* tools such as qcall_list_calls or qcall_list_campaign_call_logs.

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 use this versus alternatives, nor any prerequisites or scope conditions (e.g. whether it lists all campaigns or only active ones). Usage is only inferable from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the cross-tool identifier aliasing, which is real behavioral context, but says nothing about pagination, filtering behaviour, or result volume — acceptable given the annotation coverage, but not generous.

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, purpose first and the cross-tool identifier mapping second. Every clause carries information and 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?

For a read-only list tool with fully documented parameters and no output schema, the description covers purpose and the important downstream identifier semantics. It omits any note on pagination limits or what a list entry contains, but the schema already handles the paging inputs, so the gap is minor.

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

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

Schema description coverage is 100%, so all four parameters (page, search, perpage, response_format) are already documented in the schema and the baseline of 3 applies. The description adds no parameter meaning beyond that — the `id`/`list_id`/`segment_id` note concerns output identifiers, not inputs.

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 contact lists') and pre-empts the vocabulary mismatch by equating them with 'segments'. It does not, however, distinguish itself from near-neighbours such as qcall_list_contacts or qcall_create_contact_list, so the agent must infer the boundary 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?

The second sentence is genuine cross-tool guidance: it tells the agent that the returned `id` is consumed as `list_id` by contact tools and as `segment_id` by campaign tools, which is useful chaining information. It still gives no when-to-use/when-not guidance relative to siblings like qcall_list_contacts, so usage is implied rather than 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond them — no note about pagination behavior, search filtering, or the response_format default, which would be valuable for a list tool.

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

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

A single short, front-loaded sentence with no wasted words. It is efficient, though arguably under-specified rather than optimally 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?

For a read-only list tool with fully documented schema and annotations covering the safety profile, the description is minimally adequate. It does not mention pagination or the search/filter capabilities an agent would otherwise need to infer, but the schema compensates.

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

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

Schema description coverage is 100%, so the schema already documents page, search, list_id, perpage, and response_format. The description adds no parameter meaning beyond what the schema provides, making the baseline 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?

States a specific verb (List) and resource (contacts) scoped to 'in a contact list', which distinguishes it from the sibling qcall_list_contact_lists (contact lists themselves). However, it does not name any sibling or explicitly differentiate, so it falls short of a 5.

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 says what the tool does but gives no guidance on when to use it versus alternatives such as qcall_list_contact_lists or qcall_add_contact, and no prerequisites or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds a genuinely useful data-sensitivity fact beyond the annotations: 'Credentials are never returned,' which tells the agent what the response will not leak.

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 clauses with zero filler. The primary purpose is front-loaded and the credentials caveat follows immediately where it is relevant.

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-required-parameter read-only list with full schema coverage and no output schema, the definition covers purpose, downstream use, and one behavioral caveat. It is nearly complete, missing only an explicit boundary against the phone-numbers sibling.

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 only one optional parameter (response_format) and schema coverage is 100%, so the schema fully documents it with enum values and a default. The description adds nothing about format selection, which is the correct 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 clear verb (List) and resource (dialers), and even defines what a dialer is ('caller numbers / carrier connections') plus its role as a `dialer_id` input to calls and campaigns. It does not explicitly distinguish itself from the nearby sibling qcall_list_phone_numbers, which is the one plausible confusion point.

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 'usable as `dialer_id` for calls and campaigns' – an agent can infer this is the lookup needed before placing a call or creating a campaign. However, there is no explicit when-to-use vs. when-not, and no routing to or away from qcall_list_phone_numbers.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds genuine cross-tool context by identifying the returned hash_id as the field used when attaching to an assistant, but says nothing about the returned list contents, pagination, or auth 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?

Two short sentences with zero waste: the purpose is front-loaded and the follow-on sentence earns its place by tying the output to a real workflow. No filler or repetition of the title.

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 trivial read-only list tool with one optional enum parameter and no output schema, the description covers purpose and the key field name an agent needs to act on the result. It could note that it returns multiple knowledge bases with ids/names, but nothing essential to calling 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?

There is a single optional parameter with 100% schema description coverage and an enum, so the schema fully documents it. The description adds no format or default information beyond the schema, which is the expected baseline 3 when the schema does the heavy lifting.

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

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

The description uses a specific verb+resource ('List knowledge bases') that cleanly distinguishes it from the sibling qcall_create_knowledge_base and the other qcall_list_* tools. It is clear but does not explicitly differentiate scope from any near-neighbor, so it stops short of a 5.

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 second sentence describes a downstream use (attaching a result to an assistant via `knowledge_base_Id`), which hints at why an agent would call this, but it never states when to use this tool versus alternatives or any preconditions. No explicit when/when-not guidance is present.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the 'workspace owns' scoping note and says nothing about pagination, result caps, or whether the list is filtered by anything else.

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 front-loaded sentence with no filler or repetition of the title. It is efficient, though arguably under-specified for the amount of routing information an agent needs.

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 no-required-parameter read tool with full annotation coverage and a self-documenting schema, the description is minimally sufficient to invoke it. It is thin on output expectations and pagination, but no output schema exists and the operation is a simple list, so the gap is modest.

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 response_format parameter is fully documented in the schema with its enum and default, so the description does not need to explain it. Baseline 3 applies; the description adds no parameter meaning of its own.

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 ('phone numbers') with the scope qualifier 'the workspace owns', which separates it from generic call or contact listings. It does not name a sibling alternative, but the resource noun is distinct enough among the qcall_list_* family that an agent can route to it.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as qcall_list_dialers or qcall_list_contacts, which are the closest overlapping resources. An agent must infer the boundary purely from the noun.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the 'recent' window constraint and the transaction types returned; it says nothing about pagination, how far back 'recent' reaches, or result volume.

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

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

A single sentence with zero filler, front-loading the resource and the scope constraint. Nothing to trim.

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 no-argument read tool with rich annotations and no output schema, the definition is nearly sufficient; the only gap is the vague 'recent' window and lack of any hint about ordering or volume of returned transactions.

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 response_format enum is fully documented in the schema, so the baseline is 3. The description adds no information about response_format or any output-shaping behavior beyond what the schema already states.

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 (wallet transactions) and clarifies the scope ('recent', 'for the workspace') plus what counts as a transaction (top-ups and charges). It is clearly distinct from qcall_get_balance, but it never names that sibling or any alternative, so it stops short of explicit 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?

Usage is only implied: an agent can infer this is for browsing transaction history rather than reading the current balance, but the description gives no when-to-use condition, no mention of when get_balance or get_active_plan would be preferred, and no prerequisites.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful behavioral context — no new calls are placed and the pause persists until resumed — beyond the structured hints, though it omits what happens to already-queued or in-progress calls.

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 states the action and its effect with no wasted words. The parenthetical is a compact clarification rather than 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 one-parameter, no-output-schema mutation tool with safety annotations, the description covers purpose and immediate effect adequately. Minor gaps remain around in-flight calls and whether pausing an already-paused campaign is harmless, though idempotentHint covers the latter.

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 single campaign_id parameter is fully documented. The description adds no format, source, or constraint detail beyond what the schema already provides, making baseline 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?

States a specific verb and resource ('Pause a running campaign') and explains the immediate effect. It does not, however, differentiate itself from sibling 'resume_campaign' or 'start_campaign' by 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?

The parenthetical implies the tool is used to stop new calls from being placed, but there is no explicit when-to-use condition, prerequisite, or named alternative such as resume_campaign. The description gives context but stops short of 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 cover safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely new behavior: the call is real and billed to a wallet, and confirm=true is gated on explicit user approval. It stops short of stating reversibility, cost magnitude, or failure behavior, so not a 5.

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 core action, then the preconditions, then the ID-sourcing hints. Three compact sentences with no filler; slightly dense but every line carries 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 billable, non-idempotent mutation with no output schema, the description covers the critical agent-facing concerns: real-world side effect, cost, and the confirmation gate. Minor gaps remain on the identity/context fields, but annotations plus schema largely carry those.

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 75% schema coverage the baseline is 3, but the description adds value beyond the schema by naming the source tools for assistant_id and dialer_id and clarifying that dialer_id is optional with a default. It does not touch email, first_name, last_name, or 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?

States a specific verb and resource ('Start an outbound call where a QCall assistant talks to the person') and adds the material scoping facts that it rings a real phone and is billed to the wallet. No sibling places calls, so it is unambiguous among the listed 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?

Explicitly prescribes the precondition ('confirm the number(s), assistant and cost with the user, then set confirm=true') and routes the agent to qcall_list_assistants and qcall_list_dialers for required/optional IDs, including the default-dialer fallback.

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=false, idempotentHint=true, destructiveHint=false), so the bar is lower, and the description still adds real value the annotations do not: calls resume and are billed to the wallet, plus a mandatory user-confirmation gate. It omits what happens on an already-running or non-existent campaign, keeping it short of a 5.

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 consequence, then the safety instruction. Every clause carries information and nothing is repeated.

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 supplies purpose, the financial side effect, and the confirmation requirement — everything an agent needs to invoke it correctly. Minor gap: no statement of behavior for campaigns not currently paused.

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%: campaign_id's provenance and confirm's const=true requirement are fully documented in the schema. The description only restates the confirm=true rule, adding no syntax or format detail beyond what structured fields already provide, 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 ('Resume a paused campaign') plus the state precondition, which implicitly separates it from qcall_start_campaign and qcall_pause_campaign. It never names those siblings explicitly, so the differentiation relies on inference from the word 'paused'.

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 invocation precondition and ordering ('Confirm with the user first, then set confirm=true'), which is clear procedural context. It does not, however, state when to prefer resume over start_campaign for a stopped-but-not-paused campaign.

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 a non-read-only, non-idempotent, open-world write, and the description adds genuinely useful context beyond them: the action dials every contact in the list and incurs wallet charges. It does not discuss failure/partial-dial behavior or whether the run can be stopped, but the cost disclosure is exactly the kind of 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?

Two sentences, no padding, and the highest-stakes information (what it does, that it bills, that the user must approve) is front-loaded. The confirmation instruction lands last as the immediate next action.

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

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

For a 2-parameter mutation with no output schema, the description covers effect, cost and the approval gate, which is most of what an agent needs. Minor gaps remain around what happens if contacts fail or whether the campaign can be stopped mid-run.

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 campaign_id already points at qcall_list_campaigns while confirm already documents the user-approval requirement, so the schema does the heavy lifting. The description reinforces the confirm gate but adds no syntax or sourcing detail beyond it — 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 (start) and resource (campaign), then spells out the actual effect: the assistant begins calling every contact in its list, billed to the wallet. This clearly separates it from siblings like create_campaign, pause_campaign and resume_campaign.

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 strong precondition — confirm with the user first, then set confirm=true — which is real usage guidance. However it never distinguishes 'start' from the adjacent resume_campaign or create_campaign siblings, so the agent must infer which lifecycle operation applies.

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 non-read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: PATCH-style partial mutation ('Only the fields you pass change') and the fact that three classes of settings cannot be changed through this tool. It does not mention auth/permission requirements, but the added update semantics are substantive.

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, then the mutation semantics, then the exclusion. No filler and every clause carries 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 10-parameter partial-update tool with full schema coverage and annotations covering safety/idempotency, this is nearly complete. The only untold item is the response shape, but no output schema exists and staged partial updates rarely require it; permission requirements would be the last 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 every parameter carries its own inline description (goal, script, start_speech, transfer_number E.164 pattern, etc.), so the schema does the heavy lifting. The description adds only the meta-point that some fields (voice, model, KB) are excluded from this operation, which is a scoping note rather than parameter-level meaning.

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

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

States a specific verb and resource ('Change an assistant's text/basic settings') and scopes it with the qualifier 'text/basic settings'. The note that voice, AI model and knowledge base are configured elsewhere clarifies the boundary of this tool versus other assistant management, though no sibling tool (e.g. qcall_create_assistant) is named.

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

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

'Only the fields you pass change' gives explicit partial-update semantics, and the voice/model/knowledge-base sentence is an explicit when-not, pointing the user to the QCall app instead. It stops short of naming alternatives for creation (qcall_create_assistant) or retrieval, so it is clear but not fully exhaustive.

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