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

Annotations only carry idempotentHint:false (confirming this is a non-idempotent write), so the description must do the rest — and it does, disclosing the scope requirement, plan-level agent cap, provider/language restrictions, and the two_way default for communication. It does not describe what happens on limit breach or what the response contains, but for a creation call the behavioral coverage is solid.

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 with the mode distinction front-loaded, then rules, then the one-way configuration, then the scope requirement. No filler and nothing 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?

With no output schema, the description need not explain return values, and it covers the scope, defaults, plan limits, and the two-way/one-way conditional structure adequately for a nested-object creation tool. Minor gap: it doesn't say which identifier comes back or whether the agent is usable immediately after creation, which matters for chaining with place_call or update_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%, so a 3 is the floor, but the description adds cross-parameter conditional semantics the schema does not express: prompt is two-way only and omitted entirely for one-way, announcement is required when communication is one_way, and communication defaults to two_way. That conditional logic is the main value-add for a 5-param nested-object 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?

States a specific verb (Create) plus resource (agent) and immediately distinguishes the two variants it can produce: conversational/two-way versus one-way script-only with no listening. An agent can tell this apart from get_agent, update_agent, and create_campaign without opening 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?

Gives concrete routing guidance for the one-way path (set communication:"one_way" and pass announcement:{script, useCase}) and surfaces prerequisites: the plan's agent limit, provider/language restrictions, and the required "agents" scope. It lacks an explicit when-not-to-use or a named alternative tool, which keeps it from 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 only declare openWorldHint=true and idempotentHint=false, so the description carries most of the burden — and it does: draft-only creation, no live dialing, trial block, concurrency cap, calling-hours narrowing, required 'campaigns' scope and a workspace entitlement. It does not say whether repeated calls with the same name duplicate campaigns (relevant given idempotentHint=false) or describe the response payload.

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 compact sentences, front-loaded with the core action and the draft-state caveat first. Every clause carries information an agent needs; there is 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 12-parameter, nested-object mutation tool with no output schema and only thin annotations, the description covers the essential call flow (draft creation, promotion via update_campaign, auth scope) well. It falls short on several non-required parameters whose meaning lives nowhere, but the critical path is complete.

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

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

Schema coverage is only 42% across 12 parameters, so the description must compensate and only partially does: it implies targetType/leadGroupId/targetFilter semantics via 'against a lead group or a filter', and reinforces the concurrency clamp and calling-hours narrowing. budgetCapCents, retryEnabled, maxRetryAttempts and targetFilter internals remain undocumented in both places.

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 outbound campaign') plus the targeting source (lead group or filter). It also implicitly separates itself from the sibling write tool by naming update_campaign as the state-transition path, so an agent can distinguish create from update without opening schemas.

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

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

Gives explicit lifecycle guidance: the campaign is created as a draft and will not dial until update_campaign is called with status:"running". The alternative tool and the condition that selects it are both named, 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?

Adds real behavior beyond the idempotentHint annotation: it discloses the deduplication key (phone number), the differing status codes (201 vs 200), and how to detect which branch occurred. That is substantive, though the phrasing 'check the tool's isError/status if that distinction matters to you' is vague about the actual 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?

A single front-loaded sentence that gets the primary action out first, with the status-code detail in a compact parenthetical. Nothing is wasted, though the trailing aside about isError is slightly chatty.

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 5-parameter mutating tool with no output schema and only an idempotentHint annotation, the description covers the idempotency semantics well but leaves the remaining parameters undocumented and says nothing about validation or required-field consequences. Adequate but with clear gaps.

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

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

Schema coverage is 0% across 5 parameters, so the description carries the full documentation burden, yet it only describes the role of 'phone' (the match key). The other four parameters (name, tags, email, source) get no meaning, format, or requiredness guidance anywhere.

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 ('Creates') and resource ('a lead') and goes further by describing the upsert branch, which clearly separates it from siblings like list_leads or get_lead_for_call. An agent knows exactly what this tool produces 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?

The upsert behavior implies usage context (safe to call without checking existence first), but there is no explicit when-to-use/when-not-to-use statement and no named alternative for the lookup-only path. Guidance is inferable but not spelled out.

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

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

The annotation only sets idempotentHint=false, so the description carries real weight here: disclosing that the signing secret is returned ONCE and cannot be read back is a critical, non-obvious behavioral caveat not present in the schema. It stops short of covering auth/permission requirements or 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?

Two tight sentences with zero waste; the event list is front-loaded and the irreversible secret caveat is stated immediately after, both earning their 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 3-param mutation tool with no output schema, the description covers the key return value (one-time signing secret) and the event domain. It omits auth requirements and idempotency behavior, but the annotation covers idempotentHint.

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

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

Schema coverage is only 33% and the events parameter has no enum in the schema, so the description's enumeration of valid event values (call.started, call.ended, ..., '*') adds substantial meaning that the schema cannot convey. The 'description' parameter remains undocumented in both places.

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 (Subscribes) and resource (a URL to specific events), which clearly differentiates it from list_webhooks and delete_webhook. The events enumeration makes the purpose concrete, though it never explicitly names a sibling to route around.

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 event list (use it when you want notifications on those events), but there is no explicit when-to-use vs alternatives, no mention of list_webhooks/delete_webhook, and no stated prerequisites beyond storing the secret.

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 idempotentHint=true, so the safety profile is covered. The description adds genuinely new context: the deletion is 'Permanent' (irreversible), it does not cascade to previously placed calls, and it requires the 'agents' scope. That is exactly the kind of beyond-annotation detail this dimension rewards.

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 telegraphic sentences, front-loaded with the most critical fact ('Permanent'). Highly efficient, though the fragment style trades some readability for brevity.

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

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

For a destructive single-parameter delete whose safety hints are already in annotations, the description covers the crucial unknowns: irreversibility, non-cascading behavior, and required OAuth scope. No output schema exists, and none is implied to be needed for a delete. Only the agentId origin 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?

One required parameter (agentId) with 0% schema description coverage, and the description says nothing about the parameter's format, source, or how to obtain a valid ID. The schema carries no help either, so the gap is unfilled.

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 name/title establish the verb+resource (delete an agent), and the description narrows the blast radius precisely: 'only the agent record' and 'does not touch calls it already placed.' That scoping distinguishes it from a hypothetical broader cleanup operation, though it doesn't explicitly contrast with siblings like update_agent.

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

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

No when-to-use guidance, no indication of whether alternatives exist (e.g., disabling or updating an agent) or when deletion is the right choice versus deactivation. The imperative verb implies the action but provides no routing 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 destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds three things annotations cannot: the deletion is irreversible ('Permanent'), it does not cascade to already-placed calls, and it requires the 'campaigns' scope — an auth requirement that is genuinely useful 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?

Three terse sentences, zero filler, and the most consequential fact ('Permanent') is front-loaded. Every clause carries distinct information: irreversibility, blast radius, and auth scope.

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

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

For a destructive one-parameter tool with annotations covering the safety profile, the description supplies the key behavioral facts: permanence, non-cascading scope to calls, and required scope. It omits edge cases such as what happens to associated leads or the error behavior on an invalid ID, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 0% and the single required parameter (campaignId) is never mentioned or explained in the description. It is self-evident from its name, which keeps this from a 1, but the description does not compensate for the total absence of schema documentation as the rubric requires at low coverage.

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

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

The name and title establish a specific verb+resource (delete a campaign), and the description reinforces it with 'Permanent,' establishing irreversibility. It does not, however, distinguish this tool from siblings like delete_agent or delete_webhook 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?

There is no explicit when-to-use guidance, no prerequisites beyond the scope note, and no mention of alternatives (e.g., what to do instead if calls are pending). The word 'Permanent' hints at caution but the agent is left to infer the decision 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?

The annotations already declare destructiveHint=true and idempotentHint=true. 'Permanent.' adds the irreversible consequence beyond those hints, but says nothing about auth, scope, or side effects. A 3 acknowledges this single useful 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?

One word is concise but under-specified rather than efficient; it lacks the structure to front-load purpose or behavior. Similar to the 'Process' calibration, the brevity reflects omission, not 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 destructive delete tool, the description omits purpose, parameter meaning, and alternatives. It does disclose permanence, which annotations do not fully cover, so it is not the absolute minimum, but it remains 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 sole required parameter endpointId has 0% schema description coverage. The description says nothing about what the identifier refers to, its format, or where to obtain it. No compensation is provided for the schema gap.

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

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

The description is the single adjective 'Permanent.' It does not state a verb or resource; the tool's purpose is only inferable from its name and title. This is missing rather than a tautological restatement.

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 delete_webhook, when not to, or which alternatives such as update_webhook or list_webhooks might apply. The description gives no context for selection.

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 genuinely useful context beyond readOnlyHint=true: the required "agents" scope (an auth prerequisite annotations do not cover) and the conditional presence of a one-way script. It also enumerates returned content, which matters since there is no output schema. It does not discuss errors or missing-agent 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?

Two compact sentences, front-loaded with the return contents and ending with the scope requirement. No filler; only minor cost is the verbless opening noun phrase.

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 compensates by listing the returned configuration fields, and it notes the auth scope needed to call it. Annotations already cover the read-only safety profile. Only missing piece is when to prefer this over list_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?

Schema description coverage is 100% — the single agentId parameter is already documented as 'The agent's id, from list_agents.' The description adds nothing about the parameter, so the baseline of 3 is appropriate for a schema that carries the full burden.

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

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

The description enumerates exactly what the call returns (prompt, voice/model params, knowledge base, handoff rules, integrations, script), which makes the purpose of reading a single agent's full configuration unambiguous. The verb itself is only implied by the title 'Read one agent in full' rather than stated in the description, and there is no explicit contrast with list_agents, 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?

There is no statement of when to use this versus list_agents (enumeration) or list_agents/get_call style siblings; the only hint is that agentId comes 'from list_agents'. Prerequisites like permissions are limited to the scope note, and no alternatives or exclusions are named.

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 annotation already establishes a safe read operation, but the description adds useful privacy behavior: it explicitly says the response will never include the phone number or message text. It also enumerates the possible delivery status values, which is beyond what the annotation provides.

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 and contains no filler, but it is a fragment that leads with output values rather than the tool's purpose or usage. It is concise but under-specified in a way that hurts front-loading.

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, the description covers return-value privacy and possible statuses, which is useful since there is no output schema. However, it omits an explicit purpose statement, usage guidance, and any explanation of the deliveryId parameter, leaving notable gaps.

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

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

Schema description coverage is 0%, and the description does not explain the required deliveryId parameter at all. The parameter name is somewhat self-explanatory, but there is no information about where to obtain it, its format, or how it relates to send_announcement.

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 implies a status lookup by listing possible delivery states, but it never states a verb or resource explicitly. The title helps, yet the description alone does not clearly distinguish this from sibling tools like get_call or get_campaign_report.

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

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

No guidance is given about when to use this tool, what prerequisites exist, or how it relates to send_announcement, place_call, or get_call. The agent must infer usage entirely from the name and 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?

readOnlyHint=true already covers the safety profile, so the description must add context beyond that. It does disclose the payload composition (outcome, sentiment, summary, extracted details) and the implicit joins with transcript and lead, which an agent cannot infer from annotations or schema. Failure modes (invalid/missing UUID) are not covered.

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 leads with the resource and then lists contents. Efficient, though 'full record' plus the enumerated fields is mildly redundant and the closing clause is slightly obscured behind dashes.

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 reasonably by naming the payload fields and the joined transcript/lead. It stops short of describing error behavior or rate/permission constraints, which are minor for a single-item read.

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 required parameter with 0% schema description coverage, and the description never mentions callUuid, its format, or behavior on lookup failure. The schema alone gives a bare string type, so the description fails to compensate for the coverage gap.

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

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

Specific resource (one call's full record) with an explicit enumeration of what that record contains, plus the non-obvious note that transcript and lead are joined in. This distinguishes it from list_calls, get_transcript, and get_lead_for_call without naming them. The retrieval verb is implied 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?

Usage is only implied: the mention that transcript and lead are 'merged in' hints at using this instead of stitching together get_transcript and get_lead_for_call, but no when-to-use or when-not rule is stated. No prerequisite (e.g., needing a valid callUuid) is given.

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

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

readOnlyHint=true already declares this as a safe read, so the safety burden is lifted. The description still adds useful content-scope detail: this returns live counters (callsPlaced, callsCompleted, callsConnected) while report-style analytics live elsewhere. It doesn't mention auth, freshness, or pagination, 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?

Two sentences, zero filler, and the highest-value information (what the tool returns) is front-loaded before the routing hint. 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?

No output schema exists, so the description must carry the return-value burden, and it does by enumerating the counter fields. Combined with the sibling routing, an agent has what it needs, though the campaignId parameter and lookup-miss behavior remain unaddressed.

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

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

Schema coverage is 0% and the single campaignId parameter is undocumented in both schema and description. The description does imply an ID-based lookup, and the parameter name is self-evident, but it adds no format or sourcing detail. Minimum viable.

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 the exact resource and its contents ('a campaign's full settings and live counters'), and explicitly distinguishes itself from the sibling get_campaign_report, which the agent might otherwise confuse it with. An agent can pick the right tool 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 states the alternative by name and the condition that selects it: 'For outcomes/sentiment/the numbers it collected, use get_campaign_report instead.' That is an explicit when-to-use-this / when-to-use-the-other split.

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?

readOnlyHint=true already establishes this is a safe read, so the description is not the sole source of the safety profile. It adds one genuinely useful behavior: csv:true yields a spreadsheet-ready export instead of JSON. It says nothing about pagination, result size, or whether a campaign with no completed calls returns empty.

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?

It is short, but the opening rhetorical question ("Did it work...") costs words without adding information, and the return-field list is packed into a single colon-delimited clause. The operational instruction (csv:true) is buried after the field enumeration instead of being front-loaded.

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

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

With no output schema, the description usefully enumerates the returned fields so the agent knows what comes back. Combined with the csv-format note, it covers the essentials for a two-parameter read tool; only campaign-scoping and edge cases are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It does explain csv:true (spreadsheet export rather than JSON), which is real added meaning, but campaignId is left entirely to inference from its name.

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 and enumerates the returned analytics (per-lead outcome, sentiment, talk time, intent score, collected numbers/names), which separates it from get_campaign and list_campaigns. It is framed as a question plus a field list rather than a clean verb+resource statement, but an agent can tell what it retrieves.

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?

"Did it work, and what did it collect" implies post-campaign outcome analysis, and the csv:true note tells the agent how to switch output format. However, there is no explicit when-to-use vs alternatives guidance and no mention of prerequisites such as the campaign needing to have finished.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. Beyond that, the description adds nothing behavioral: it does not say whether the lookup can fail, what happens for a call with no lead, or whether a lead can be linked to multiple calls. It restates the operation rather than disclosing traits.

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 no filler, and the resource-plus-relationship information is front-loaded. It is efficient, though the terseness comes at the cost of the guidance and behavioral detail scored elsewhere.

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 must carry the return-value burden, and it only minimally indicates that a lead record is returned without describing its shape or the no-lead/null case. For a lookup tool keyed on an undocumented identifier, this leaves real gaps.

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

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

Schema description coverage is 0% for the single required parameter. The phrase 'a given call' vaguely implies callUuid identifies the call, but the description supplies no format, source, or mismatch behavior to compensate for the missing schema documentation, leaving the only parameter effectively undocumented.

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 resource (the lead record) and the exact relationship it resolves (the lead linked to a given call), so an agent can distinguish it from get_call, list_leads, or create_lead. It is a noun fragment rather than a verb+resource statement, but the retrieval intent 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 when-to-use guidance at all: no statement of prerequisites, no mention of alternatives such as list_leads or get_call, and no indication of what to do when a call has no associated lead. The agent must infer usage entirely 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?

The readOnlyHint annotation already establishes this is a safe read operation, so the description is not obligated to restate safety. It adds only that the payload is turn-by-turn conversation content, which is mildly useful but silent on pagination, speaker labeling, or whether the transcript can be absent for short/failed 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?

One compact sentence with zero filler and the key scope constraint front-loaded. It is efficient, though it verges on under-specification rather than being deliberately tight.

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 and an undocumented required parameter, the description needed to carry more weight. It says nothing about identifier format, transcript availability, or how it differs from get_call, so an agent has real gaps to close before invoking it.

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

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

Schema description coverage is 0%, so the single callUuid parameter is documented nowhere. The description does not explain that the identifier must be a call UUID or where to obtain it (e.g., from list_calls or get_call), leaving the caller to guess the format.

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 resource and scope: the turn-by-turn transcript of a single call. An agent can tell it returns conversation turns rather than call metadata. It does not, however, distinguish itself from the sibling get_call, which an agent might reasonably confuse it with.

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 get_call, get_lead_for_call, or any alternative. No prerequisites, no conditions, no exclusions. The agent must infer everything 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?

readOnlyHint already marks it as a safe read. The description adds that samples are recent real events mirroring live POSTs, which helps the agent understand the data's fidelity and intended test use. It does not cover auth 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?

A single, tightly written sentence that front-loads what the tool returns and includes only the essential use case.

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 usefully characterizes the return shape as identical to a live POST. It remains incomplete about the optional limit parameter, but otherwise covers the tool's purpose and safe read-only nature.

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 event parameter has schema examples, but limit has no description in the schema. The tool description never mentions either parameter or explains that limit controls the number of samples returned, so it leaves the limit semantics undocumented.

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 title and description convey that it returns sample payloads for a specific webhook event, and the phrase 'exact shape a live delivery POSTs' clarifies the return format. It does not explicitly name sibling tools or contrast with list_webhooks, so it is 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?

The description gives a clear use case: building a receiver before real events have fired. It does not specify when to avoid using it or mention alternatives, but for this narrow testing purpose that context is sufficient.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond the schema: it is names-only (id, name, active) and it discloses that get_agent needs an extra auth scope, which is useful for planning calls. It stops short of describing ordering or whether archived agents are included.

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, front-loaded with what the tool returns before the alternative. Every clause earns its place: what you get, why it's enough, and where to go for more.

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-parameter, read-only list tool with no output schema, the description covers the return fields, the purpose, and the sibling alternative including a scope caveat. Nothing an agent needs to call it correctly is missing.

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

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

There are zero parameters, so the baseline is 4. The description correctly adds no parameter guidance because none is needed, and instead spends its words on return shape and sibling routing.

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 concrete verb+resource (list this workspace's AI agents) and immediately specifies the returned fields (id, name, active). It also explicitly distinguishes itself from get_agent, so an agent can tell the two apart 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?

Gives a positive use case (enough to choose an agent for place_call or send_announcement) and an explicit alternative with its condition (full setup via get_agent, which requires the separate "agents" scope). When-to-use and when-to-use-something-else are both covered.

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

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

Beyond the readOnlyHint annotation, the description discloses ordering (newest first), that outcome/sentiment/summary appear only once a call is analysed, and the required auth scope — useful behavioral context not present in structured fields. It omits pagination behavior, which is relevant given limit/offset parameters.

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 that front-loads the resource and scope before the returned fields and auth requirement. 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?

With no output schema, the description usefully sketches the returned fields and notes analysis-dependent availability, plus the required scope. However, for a paginated list tool the absence of any limit/offset semantics leaves a real gap an agent must guess at.

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

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

Schema description coverage is 0% for both limit and offset, leaving the description responsible for explaining them. It says nothing about pagination, defaults, or the maximum of 200, so the two parameters remain semantically opaque.

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 the resource (this workspace's calls), the ordering (newest first), and the returned analysis fields, so an agent knows exactly what it retrieves without opening a schema. It is clearly a listing operation and distinct from get_call/get_campaign, though it never explicitly contrasts with those siblings.

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

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

The only usage guidance is the prerequisite "Needs the 'calls' scope", which is genuine and actionable. There is no statement of when to prefer this over get_call or list_leads, so the when-to-use context is only implied by the resource 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds genuinely useful context not present in annotations: the required 'campaigns' scope, which is an auth prerequisite an agent otherwise could not anticipate. It says nothing about pagination, result limits, or whether all campaigns are returned.

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, zero filler, and the resource is front-loaded ahead of the auth requirement. It is efficient, though bordering on under-specified for a list operation.

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, non-destructive read with no output schema, the description covers the resource and the auth requirement, which is close to sufficient. It omits any statement about return volume or ordering, which is the main remaining gap an agent would care about.

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 zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter claims conflict with the empty 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 identifies the resource ('this workspace's outbound campaigns') and the name supplies the verb 'list', but the description itself never states that it returns a collection. It is a noun phrase rather than a stated action, so the agent must borrow meaning from the tool 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 and no mention of alternatives such as get_campaign for a single record or get_campaign_report for analytics. The only routing information is the required scope, not a selection criterion between 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, so safety is covered. The description does add two facts not present in structured data: the required "leads" scope and the newest-first ordering. It says nothing about pagination, page size limits, or what happens when the list is empty.

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, with the resource and ordering front-loaded before the scope requirement. Nothing 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, no parameter documentation and only a readOnlyHint annotation, the description omits default limit, pagination semantics, and response shape. The auth scope note is valuable but the pagination gap is significant for this tool type.

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

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

Schema description coverage is 0% and the description mentions neither limit nor offset, nor the maximum of 200. An agent has no way to learn the default page size or how offset interacts with the newest-first ordering from either field.

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

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

States a specific resource (this workspace's leads) and an ordering constraint (newest first), which lets an agent separate it from create_lead, get_lead_for_call and list_calls. It does not explicitly reference any sibling, 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?

There is no when-to-use or when-not-to-use statement and no alternatives named. The agent must infer from the name and the phrase "this workspace's leads" that this is the enumeration tool rather than a lookup, with no guidance on when to prefer get_lead_for_call.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the annotations: the required 'webhooks' auth scope.

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, front-loaded fragments with no filler. It is a noun phrase rather than a full verb statement, but 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 simple, zero-parameter list tool with no output schema, the definition supplies resource scope and auth requirement. Return format is not described, but this is minor given the tool's 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a 0-param tool 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 names the specific resource ('this workspace's outbound webhook endpoints') and, with the name/title, makes the list purpose clear. It does not explicitly contrast with sibling read tools like get_webhook_samples, but the resource 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?

It states a prerequisite ('Needs the "webhooks" scope') but gives no when-to-use context or alternatives. It does not say when to prefer this over get_webhook_samples or how it relates to create_webhook/delete_webhook.

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

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

Annotations only declare openWorldHint and idempotentHint; the description adds substantial context beyond them: the specific gates enforced (do-not-call list, calling hours, wallet balance, concurrency), the refusal-code branching surface (suppressed, outside_hours, wallet_low), and the non-default 'dial' scope requirement. This is exactly the behavioral disclosure 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?

Four sentences, each earning its place: what it does, the gating behavior, the error surface, and the routing alternative. The critical scope prerequisite and the cheaper sibling are front-loaded rather than 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?

With no output schema, the description usefully explains the refusal-code return surface, and it covers gating and auth. The one gap is parameter meaning for leadId/agentId, which neither the schema nor the description explains.

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

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

Schema coverage is only 33% — 'to' is documented as E.164, but leadId and agentId have no schema description. The description mentions none of the parameters, so it fails to compensate for the coverage gap; an agent gets no guidance on what agentId or leadId must reference.

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 ('Starts a real conversational call from this workspace's own number') and immediately distinguishes itself from the sibling send_announcement by contrasting listening conversation vs fixed script. An agent can differentiate this from send_announcement 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?

Names the alternative explicitly ('For a fixed script with no listening... use send_announcement instead - it is far cheaper') with the condition that selects it. It also states the prerequisites (dial scope, gates) that gate a successful call, 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 only cover openWorldHint and idempotentHint, so the description carries the rest and does so richly: TTS-only with no conversation, billed at one-way rate, values pre-formatted for speech, empty script fields refused by name, and externalId deduplication for safe retries. This adds substantial behavioral context the annotations do not 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?

Front-loads the core action and keeps the comparison to place_call early. Dense but nearly every clause carries new information; sentences are long and packed with parentheticals, costing some 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?

No output schema, but the description explains the send/retry outcome ('answers with the first send instead of ringing again'), billing context, and refusal behavior. It omits error cases beyond the empty-script-field rule and any return payload shape, leaving a minor gap for a 5-param call 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 80% (to, agentId, variables, externalId already documented), yet the description still adds real meaning: how variables' values are formatted for speech, that a valueless script field is refused by name, and what externalId does on retry. Slightly above the baseline because it explains parameter behavior the schema only implies.

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 ('Plays a one-way agent's fixed script to one number') and immediately names the sibling it differs from ('far cheaper than place_call'). An agent can distinguish this from place_call 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?

Makes the selection condition clear via the price comparison to place_call and the 'text-to-speech only, no conversation' constraint, and the schema/description require a one-way agent. No explicit when-not statement, but the alternative is named with the reason to prefer this one.

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 idempotentHint=true; the description adds meaningful context that is consistent with it - PATCH-style merge semantics (omitted fields untouched) and an explicit authorization requirement ('agents' scope). It stops short of describing side effects of mutating live fields like prompt or announcement, but it clearly carries more than the annotation layer.

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 with zero filler; the merge semantics and the scope requirement are front-loaded 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?

For a 7-parameter tool with nested objects and no output schema, the description leaves the parameter surface entirely undocumented and gives no hint about update scope or effects. The merge/scope notes are useful but insufficient for the tool's 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 0% across 7 parameters, including nested objects (prompt, announcement, params) and an enum (communication), so the description carries full responsibility here. It explains only the merge behavior and never mentions what name, active, communication, prompt, or announcement do.

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 ('Change') and resource ('an agent's fields'), and the resource name alone distinguishes it from update_campaign in the sibling list. It does not explicitly contrast with create_agent/delete_agent, but the mutation target 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?

Gives real usage guidance for a partial update ('Send only what changes - fields left out are untouched') and states the required 'agents' scope. However, it never says when to prefer this over create_agent/delete_agent or what conditions make an update appropriate, so the when-to-use aspect 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 only declare openWorldHint and idempotentHint=false, so the description carries most of the behavioral burden — and it does add real value: "kicks the dialer right away - real calls start going out" discloses a consequential external side effect, and it notes the campaign.status_changed webhook. It omits reversibility of "cancelled" (stated as permanent, which is good) and 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?

Compact and front-loaded: the core action comes first, then the status semantics, then the webhook side effect. Slightly awkward inline quoting of "status:"running"" but no wasted sentences.

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 non-idempotent mutation with an open-world hint, no output schema, and 5 undocumented parameters, the description covers the status side effects and webhook well but leaves the settings-oriented parameters (name, concurrency, budgetCapCents) and the remaining enum values unexplained.

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

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

Schema description coverage is 0%, so the description must compensate. It explains three of the six status enum values (running/paused/cancelled) but ignores completed/scheduled/draft, and says nothing about name, concurrency, or budgetCapCents. Partial compensation, so a mid score.

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 concrete verb+resource ("Change settings, or change status") and the title enumerates the operations (update, start, pause, resume, cancel). It is clear what the tool does, though it doesn't distinguish itself from siblings like delete_campaign or create_campaign beyond the operations listed.

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: the status values hint at when to start/pause/cancel, but there is no explicit guidance on when to use this versus delete_campaign (cancel vs delete) or create_campaign, and no prerequisites stated. The one hard constraint (campaignId required) comes from the schema, not 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the auth-verification behavior and the failure mode it addresses (401s), which is meaningful context beyond annotations, though it doesn't explain the error behavior when the key 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 tight sentences, front-loaded with what the tool does and followed by the trigger. 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 zero-param, no-output-schema diagnostic tool, the description is nearly complete. It could state what happens on invalid key (error vs. false response), but the core need is met.

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, so the baseline is 4 per the rubric. The description doesn't need to add parameter detail; its mention of org id is contextual rather than a parameter 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 action (confirms key validity, returns workspace name) with a clear resource and no ambiguity. The title reinforces this and the tool is trivially distinguishable from all sibling campaign/call/agent 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 says 'Call this first if a tool starts failing with 401s,' giving a concrete trigger condition. That is the exact when-to-use guidance an agent needs for a diagnostic tool.

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