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

Without annotations, the description fully discloses behavior: upsert by name (replace existing), edits saved to draft via read-modify-write, concurrent edit risks, need to publish_draft to make live, and that the agent decides when to invoke based on name+description.

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 well-structured with front-loaded purpose and logical flow. It is informative but slightly verbose with minor redundancy. Each sentence adds value, but some details (e.g., 'API-call tools let the agent...') could be tighter. Still, it respects conciseness expectations.

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

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

Given the tool's complexity (14 parameters, nested objects, no output schema), the description covers all necessary context: what the tool does, how to use it, side effects (draft editing, upsert behavior, concurrency risks), and related tools. It is complete for an agent to select and invoke correctly.

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

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

The description adds meaning beyond the schema by explaining the batch vs single-tool modes, the upsert behavior by name, and the workflow context. While schema coverage is 50%, the description does not detail every parameter but provides high-level guidance that aids parameter usage.

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

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

The description clearly states 'Add (or update) one or more API-call tools on a single_prompt agent' and explains what API-call tools do with examples. It distinguishes from siblings by mentioning remove_agent_tool and configure_call_actions, leaving no ambiguity about its purpose.

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

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

It explicitly tells when to use (to let the agent make HTTP requests), how to use (single tool via top-level fields or batch via `tools`), and when not to (use remove_agent_tool for deletion, configure_call_actions for end_call/transfer_call). It also advises making edits one at a time and publishing drafts.

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?

No annotations are provided, so the description carries full burden. It discloses max members per request and duplicate skipping, but does not mention error handling, partial success, or idempotency. For a simple add tool, this is adequate but not exceptional.

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

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

The description is three sentences, each serving a purpose: action, requirement, limits/behavior. No redundancy and front-loaded with the core 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?

Given the low complexity (two parameters, no output schema), the description covers essential behavioral aspects. It could mention response format or error scenarios, but it is largely complete for its purpose.

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%, baseline 3. Description adds value by specifying the phone number column requirement and providing an example. It also recommends using get_audience to check, which is beyond schema info.

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

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

The description clearly states 'Add members (contacts) to an existing audience' with a specific verb and resource. It distinguishes from sibling tools like delete_audience_members and search_audience_members by focusing on addition.

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

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

The description provides clear context: prerequisites (check audience for phone column), limits (max 10,000), and behavior on duplicates (skipped). It does not explicitly state when not to use or list alternatives, but the 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?

Discloses draft lifecycle, fallback behavior for first enabled playbook, and uniqueness rules (case-insensitive, including archived). Without annotations, this is adequate but could mention permissions or error handling.

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?

Well-structured with front-loaded purpose, then details. Somewhat long but every sentence adds value. Could be slightly more terse.

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?

Covers key aspects: what playbook consists of, draft lifecycle, fallback, uniqueness. Refers to related tools. Could mention return value or error conditions, but adequate for agent use.

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%, but description adds value beyond schema: explains draft context, fallback, and references configure_playbooks for identity tools. Also clarifies batch addition and uniqueness 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?

The description clearly states it adds one or more playbooks to a multi_agents agent, specifying the components: intent, prompt, tools, auth. It distinguishes from siblings like update_playbook (update) and get_playbooks (list).

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

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

Provides context that edits go on draft, need publish_draft, and uniqueness constraints. However, does not explicitly state when to use vs alternatives like configure_playbooks or update_playbook.

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

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

With no annotations, the description fully discloses critical behavior: 'this REPLACES the agent's current subscriptions' and that an agent points at one webhook at a time. It also warns about not guessing event types. This is comprehensive for a mutation tool.

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

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

The description is well-structured with a clear purpose, then usage details, then warnings. It is somewhat long but every sentence adds value. Slight improvement could be trimming redundancy, but overall effective.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description provides thorough guidance: workflow, behavioral replacement, event type warnings, and sibling differentiation. It fully equips an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the workflow (webhook_id from get_webhooks) and reinforcing the event_types constraint (ask user, don't guess). This extra context makes it a 4.

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

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

The description clearly states the action ('attach an EXISTING webhook to an agent for the given events') and the resource. It distinguishes from sibling tools like detach_agent_webhooks by specifying the action and including a workflow hint (find webhook with get_webhooks first).

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 provides when to use: 'send this agent's call-start/call-end/analytics to an already-created webhook', and the prerequisite to find the webhook with get_webhooks. It also warns against guessing event types and directs to ask the user, and differentiates from detach_agent_webhooks.

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?

Discloses turn-waiting behavior, filler messages, and that it returns full transcript. With no annotations, description fully covers safety and behavior.

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

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

Single paragraph but front-loaded with core purpose; every sentence adds value. Slightly long but warranted given complexity.

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

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

With 6 params fully described and no output schema, description covers all necessary behavioral and contextual details, including chargeability and turn handling.

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?

Each parameter has schema description; description adds context beyond schema (e.g., realistic messages, filler explanation for settle_ms).

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

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

Clearly states it holds a TEXT conversation with a published agent over WebSocket, no audio. Distinguishes from test_agent for unpublished drafts.

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

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

Explicitly describes programmatic use for testing agent behavior, mentions chargeable session, and directs to test_agent for unpublished drafts.

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

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

With no annotations, description carries full burden. Discloses draft behavior, auth note ('never gated behind auth'), and consequence of disabling end_call. Could mention return value but adequate.

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

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

Single paragraph with no wasted words. Could be broken into sentences for readability, but efficient.

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

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

Covers scope, draft lifecycle, auth, and a critical consequence. No output schema, but tool is configuration-oriented and return value may be implicit.

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

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

Schema coverage is 100%, so baseline 3. Description adds context like 'false = remove it' and E.164 example, but schema already covers most 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?

Clearly states the tool enables/disables end_call and sets/removes transfer_call number. Uses specific verbs and identifies resource as agent-level settings.

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?

Explains that settings are agent-wide, apply to all playbooks, and require publish_draft to go live. No explicit alternatives but context is clear.

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

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

No annotations are provided, so the description carries full burden. It discloses that edits land on a draft and that publish_draft is required to go live. It also mentions that weak_auth_tools and strong_auth_tools replace shared tools. However, it does not describe what happens if optional parameters are omitted (e.g., whether existing settings remain unchanged), nor does it disclose any destructive actions or side effects.

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

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

The description is a single paragraph that is front-loaded with the main purpose and then lists components. It is clear and every sentence adds value, though it could be slightly more structured with bullet points. No wasted words.

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

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

Given the complexity (7 parameters, no output schema), the description explains the purpose of each parameter group and the draft mechanism. However, it does not describe the return value or response upon success, nor does it mention prerequisites like the agent existing. It is adequate but not fully 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 100%, so each parameter has a description. The tool description adds meaning by grouping parameters into three areas (intent router, conversation guide, identity tools) and explaining their role. It also clarifies that weak_auth_tools 'REPLACES' shared tools, a detail not in the schema. This adds value beyond the schema.

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

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

The description clearly states the verb 'Configure' and the resource 'section-level Playbooks settings of a multi_agents agent'. It explicitly lists the three areas: intent router, conversation guide, and shared identity tools. It distinguishes from siblings by noting that the conversation guide is defined once here, not per-SOP, which is a key differentiator from tools like add_playbooks or update_playbook.

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

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

The description provides clear context for when to use this tool: to configure playbooks settings for an agent, specifically the intent router, conversation guide, and auth tools. It mentions that edits land on a draft and that publish_draft is needed to go live. However, it lacks explicit statements about when not to use this tool or direct comparisons with alternatives like add_playbooks, though the 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?

No annotations provided, so the description carries the full burden. It discloses default configurations (single_prompt, gpt-4.1, daniel voice, Pulse STT, returns agent ID) and explains that multi_agents requires allowlisting and playbooks must be added separately. It does not describe the agent's activation state, error conditions, or permission requirements, but overall provides good transparency about the creation process and defaults.

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

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

The description is a single paragraph of five sentences, each providing essential information: main purpose, defaults, multi_agents option, post-creation steps, and return value. No extraneous content; every sentence earns its place. The structure is front-loaded with the core 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?

Given the complexity (18 parameters, no output schema, no annotations), the description covers creation, defaults, agent type differentiation, post-creation steps, and return value. It also notes the domain-gating for multi_agents. It does not mention error scenarios or lifecycle hooks (e.g., if name already exists), but is fairly complete for typical use. The schema provides detailed parameter information, so the description complements well.

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

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

Schema coverage is 100%, so the description's role is supplementary. It adds context such as default values (e.g., model gpt-4.1, workflow_type single_prompt) that are already referenced in schema descriptions, and explains the workflow_type parameter's effect. However, it does not provide additional semantics beyond the schema for most parameters, and the mention of STT transcriber (not a parameter) could cause confusion. The description adds modest value.

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

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

The description clearly states 'Create a new AI agent in your organization' and distinguishes from siblings like update_agent, duplicate_agent, delete_agent. It specifies the resource (agent) and action (create), and differentiates between single_prompt and multi_agents workflows, providing a clear and specific purpose.

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

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

The description explains when to use this tool (to create a new agent) and what to do after creation (setting prompt via update_agent, adding playbooks via add_playbooks, changing STT via update_agent). It mentions the domain-gating for multi_agents. However, it lacks explicit guidance on when not to use this tool versus alternative creation methods like duplicate_agent, and does not mention prerequisites or constraints such as agent name uniqueness.

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

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

With no annotations, the description must explain behavior. It conveys that the branch starts from a source branch head, defaults to the live branch, and is non-destructive ('without touching the live agent'). It does not elaborate on error conditions or limits, but the core behavior is sufficiently disclosed.

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 pack all essential information: purpose, default behavior, and workflow. No redundant words; every sentence earns its place.

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

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

Given 3 parameters, no output schema, and no annotations, the description covers the workflow well, including defaults and links to siblings. It omits explicit mention of the required agent_id (though schema does) and potential errors, but overall is adequate for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, providing baseline clarity. The description adds value by explaining that source_branch_id defaults to the live branch if omitted, and that the new branch_id should be used for subsequent editing, which goes beyond the schema.

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

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

The description clearly states the tool creates a branch to work on changes in isolation, specifying the source branch default and linking to subsequent workflow steps. This distinguishes it from branch management siblings like delete_branch, rename_branch, and make_branch_live.

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 tells when to use (to work on changes without touching the live agent) and outlines the workflow (edit draft, publish, make live). It implicitly suggests using list_branches first via the source_branch_id parameter description, but lacks an explicit 'when not to use' or direct alternative mention.

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?

Given no annotations, the description covers key behaviors: campaign is created in draft unless scheduled_at is provided, and start_campaign is needed to begin dialing. It doesn't mention idempotency or error cases but is sufficient for a creation 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?

Three sentences, no waste, front-loaded with purpose. Each sentence earns its place, providing essential information succinctly.

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

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

Given 8 parameters and no output schema, the description explains core behavior and state transitions. It could mention the return value (e.g., campaign ID) but is otherwise complete for selection and invocation.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the significance of scheduled_at (draft vs scheduled) and referencing get_phone_numbers for phone_number_ids, providing context beyond the schema.

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

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

The description clearly states the tool's purpose: 'Create a new outbound calling campaign.' It specifies prerequisites (agent and audience) and distinguishes from sibling tools like start_campaign. The verb+resource combination is specific and unambiguous.

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

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

The description provides clear usage context: it requires an agent and audience, explains draft vs scheduled status, and explicitly directs to start_campaign for beginning dialing. It lacks explicit when-not-to-use guidance but effectively informs the agent.

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

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

Discloses that this creates a new webhook, events are optional and can attach in same call, headers have limits. Lacks mention of error behavior (e.g., duplicate endpoint) but is otherwise transparent. No annotations to contradict.

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: purpose, usage condition, events detail, caution. No filler, well-structured and front-loaded.

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

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

Covers parameters and usage well, but there is no output schema and description does not explain what is returned (e.g., created webhook object). This omission, given complexity and no output schema, makes it slightly incomplete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds significant value: explains events' optionality and attachment, headers limits and examples, endpoint format. Extra context raises 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?

Explicitly states 'Register a NEW webhook endpoint' with a specific verb and resource. Distinguishes from siblings like get_webhooks and attach_agent_webhook by specifying the condition for use.

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

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

Provides clear when-to-use (only for new URLs) and when-not-to (already registered, use get_webhooks then attach_agent_webhook). Also gives explicit guidance on events: never guess/default, ask user if unspecified.

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?

No annotations provided, but description details return fields and confirms read-only nature by listing no side effects. However, does not disclose any authorization needs 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?

Two sentences, no fluff, front-loaded with purpose and 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?

Given low parameter count, no output schema, and no nested objects, the description is complete: it lists what is returned and conditions of use.

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 parameter with full schema coverage; description adds example format and context beyond schema definition.

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?

Description uses specific verb 'Get detailed info' and resource 'single call', clearly distinguishing from siblings like 'list_calls'.

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

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

Explicitly states use cases (debugging, status check) and that it works for any call state. Does not mention alternatives but context from siblings 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?

Discloses key traits: soft-delete, agent becomes inactive, unarchiving not supported. Despite no annotations, reveals constraints and irreversible nature. Lacks mention of permissions or side effects, but sufficient for this simple 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?

Three concise, front-loaded sentences. Every sentence adds value: action, constraint, limitation and alternative. No unnecessary words.

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

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

Given no output schema and simple single-parameter tool, description provides all necessary context: what it does, constraints, and alternative for restoration. Agent can correctly decide when to invoke.

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 covers parameter fully (100% coverage), description simply restates agent ID context. Description adds no new semantic meaning beyond the schema, meeting baseline expectation.

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

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

Clearly states the action (archive/soft-delete), the resource (agent by ID), and the effect (inactive). Distinguishes from sibling tools like delete_audience and delete_campaign by focusing on agents.

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 mentions when to use (to archive an agent), when not to use (cannot archive agents with active campaigns), and alternative for restoration (use app.smallest.ai). No ambiguity.

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?

No annotations are provided, so the description carries full burden. It discloses one behavioral constraint (cannot delete if linked to campaign) but does not mention whether deletion is permanent or irreversible. More context would improve transparency.

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, each serving a distinct purpose: first states the operation, second adds a critical usage constraint. No redundancy or fluff.

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

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

For a simple delete tool with one parameter, the description covers the core action and a key precondition. However, it lacks output details (e.g., success response) which could be inferred but are not explicitly stated. Still sufficient for safe invocation.

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

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

Schema coverage is 100% and the schema already describes the audience_id parameter accurately. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Delete an audience by ID') and the resource ('audience'), making it distinct from sibling tools like delete_audience_members or delete_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?

It provides explicit guidance on a precondition: cannot delete if linked to a campaign, and suggests removing or deleting the campaign first. This helps the agent avoid errors and choose the correct sequence.

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?

No annotations provided, so description carries full burden. It discloses the primary behavior (removing members) and warns that removing all members may delete the audience. While it doesn't explicitly label the operation as destructive, the warning suffices.

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 concise sentences, no fluff. First sentence states purpose, second gives usage hint, third warns of side effect. Front-loaded and efficient.

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

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

Given low complexity (2 params, no output schema), description covers purpose, parameter usage, and a key side effect. It could mention return value (e.g., success or count), but not strictly necessary.

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

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

Schema covers both parameters. Description adds value by explaining how to obtain member IDs (via get_audience_members or search_audience_members), which is not in the schema. For audience_id, no extra info is added beyond 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?

Description clearly states the verb (remove), resource (specific members from an audience), and method (by member IDs). It distinguishes from sibling tools like add_audience_members and get_audience_members.

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

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

Provides guidance to first find member IDs using get_audience_members or search_audience_members, and warns about potential audience deletion if all members are removed. However, it does not explicitly state when not to use or alternative tools for removing entire audience.

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

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

With no annotations, the description bears full responsibility. It discloses that deletion removes revisions and open draft, and that default/live branches are protected. However, it does not state if deletion is irreversible, permissions needed, or what the response indicates.

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 efficiently convey purpose, constraints, and a helpful hint. No unnecessary words. Front-loaded with action and 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?

Given no output schema, the description does not explain return values or success confirmation. It covers behavioral context adequately but lacks completeness for a destructive tool with side effects.

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% (both parameters have descriptions). The description adds context that branch_id comes from list_branches, but the schema already says 'from list_branches'. No additional parameter-level meaning beyond the schema.

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

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

The description clearly states 'Delete (archive) a branch, along with its revisions and open draft.' It specifies the action and scope, distinguishing it from sibling tools like rename_branch or make_branch_live.

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

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

The description provides clear context: 'The default branch cannot be deleted, and the live branch cannot be deleted — make another branch live first. Use list_branches to find branch IDs.' It advises when not to use and directs to a prerequisite tool, but does not explicitly mention alternatives for other operations.

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?

Without annotations, the description carries full burden. It discloses that deletion is permanent and removes execution data, but omits details like required permissions, impact on running campaigns, or error conditions.

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, no redundancy. The core action is front-loaded.

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

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

For a simple delete with one parameter and no output schema, the description covers purpose and effect. Missing details on safe usage (e.g., active campaigns) but adequate for basic understanding.

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 covers 100% of parameters with clear description. The tool description adds context about permanence but does not enhance parameter understanding beyond the schema.

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

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

The description clearly states the action ('Delete') and resource ('campaign'), and specifies the permanent nature including removal of execution data. This distinguishes it from sibling tools like pause_campaign or start_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?

No guidance on when to use this tool versus alternatives (e.g., pause_campaign or archive). No prerequisites or warnings about active campaigns are provided.

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

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

Without annotations, the description fully discloses key side effects: deletion cascades to subscriptions and detaches from all agents, which is critical for an irreversible operation.

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

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

Two sentences, front-loaded with the action, and no extraneous words. Every sentence adds value.

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

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

For a simple 1-parameter delete tool with no output schema, the description covers the main effects. Minor omission: no mention of return value or prerequisites like webhook existence.

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

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

Schema coverage is 100% with a description for webhook_id. The tool description adds no additional parameter meaning beyond what the schema already provides.

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

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

The description clearly states the action (delete a webhook) and its scope (all subscriptions and detach from agents), distinguishing it from other webhook tools like update_webhook or detach_agent_webhooks.

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

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

The description implies when to use (to permanently remove a webhook) but does not explicitly contrast with alternatives like detach_agent_webhooks, which only detaches without deleting.

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

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

With no annotations, the description carries the burden. It discloses that all subscriptions are removed, that deliveries stop until re-attached, and that the endpoint itself is not deleted. This is good but lacks details on auth requirements 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?

Two sentences, no fluff. The action is front-loaded, and every sentence adds value (what it does, consequence, what it doesn't do).

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

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

For a simple tool with one parameter and no output schema, the description covers the action, effect, and non-effect. It references the related sibling tool for re-attaching, providing complete context.

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

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

The only parameter (agent_id) is fully described in the schema (100% coverage). The description adds no new semantic information beyond the schema's description, so a baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Remove ALL of an agent's webhook subscriptions.' It specifies the effect (stop receiving deliveries) and distinguishes from the sibling tool 'attach_agent_webhook' by clarifying what it does not do (delete the endpoint).

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

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

The description provides clear context on when to use the tool (to stop deliveries) and mentions the re-attachment alternative. However, it does not explicitly state when not to use it or list any 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?

No annotations are provided, so the description must fully disclose behavioral traits. It explains that the tool compares configs and returns changes with old/new values. However, it does not explicitly state that the tool is read-only or mention any authentication requirements or rate limits. The description is adequate but not exhaustive.

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

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

The description is two sentences long, front-loaded with the purpose, and contains zero wasted words. Every sentence adds necessary context.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description covers the core functionality and parameter usage with an example. However, it does not explicitly describe the structure of the return value, though the phrase 'field paths with old/new values' gives a reasonable expectation.

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

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

The input schema has 100% coverage for all 3 parameters, but the description adds value by explaining the format of 'a' and 'b' (revision_id or branch:draft) and providing a concrete usage example. This goes beyond the schema's descriptions, which only say 'Left side: a revision_id, or...'.

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

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

The description clearly states the tool compares two agent configs and shows changes section by section with field paths and old/new values. It uniquely identifies this tool among siblings, as no other sibling tool performs diff operations on configs.

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

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

The description provides clear context for when to use the tool, including an example of diffing a branch's draft against live head to preview a publish. It does not explicitly state when not to use it, but the context is sufficient and no sibling tool offers similar functionality.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It confirms the tool creates a new agent but omits important details such as whether all configurations are copied (including sub-resources), any potential side effects (e.g., duplication of dependencies), rate limits, or security requirements. The description is too sparse to allow an agent to fully understand the implications of using this tool.

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

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

The description is exceptionally concise: two short sentences that first state the action and result, then provide usage context. Every word is purposeful, with no redundancy or filler. The information is front-loaded, allowing an agent to quickly grasp the tool's purpose.

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

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

For a simple tool with only two parameters and no output schema, the description covers the essential information: what it does, the default behavior, and a typical use case. It could be slightly improved by explicitly differentiating from 'create_agent' or noting any limitations (e.g., inability to duplicate an agent with certain associated resources), but overall it is adequate for its 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?

The input schema already describes both parameters with 100% coverage. The description adds value by explaining the overall purpose ('duplicate creating a new agent with the same configuration') and clarifying default behavior for the optional parameter ('If omitted, duplicates into your own organization'). This goes beyond the schema to provide operational context.

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

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

The description clearly states the action ('Duplicate an existing agent') and the resource ('agent'), with added context about creating a copy with the same configuration. It distinguishes from siblings like 'create_agent' by specifying it's for copying, and mentions use cases (testing, A/B comparisons), making the purpose explicit and unambiguous.

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

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

The description explains when to use the tool (to create identical agent copies for testing) and mentions the target organization default, providing context for usage. However, it does not explicitly state when not to use it or contrast with alternatives like 'create_agent' or 'update_agent_config', so it misses clear exclusions.

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

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

With no annotations, the description explains the output but does not disclose side effects (e.g., whether it's read-only) or any restrictions.

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

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

Two concise sentences that front-load the purpose and detail the output, with no superfluous content.

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

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

Given no output schema, the description covers the return fields well, but lacks info on pagination or limits.

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

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

Schema coverage is 100%, so the description adds minimal value beyond the schema; it mentions output grouping but not how parameters affect it.

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

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

The description clearly states the tool exports call logs for a campaign and lists the detailed return fields (status, duration, recording URL, etc.), which distinguishes it from sibling tools like list_calls.

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 explicit guidance on when to use this tool versus alternatives like list_calls; usage is implied but not clarified.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'full details' with a list of included fields, but does not mention error handling, permission requirements, or behavior on invalid IDs. The description adds some value beyond the schema but lacks complete transparency.

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

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

The description is a single, well-structured sentence of 23 words. It front-loads the primary action ('Get full details for a single agent by ID') and then lists the included fields. No unnecessary words 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 simple read tool with one parameter and no output schema, the description provides a sufficient overview of the returned data. It lists major categories, enabling an agent to determine usefulness. However, it could add error behavior details to be fully complete.

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

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

There is only one parameter (agent_id) with a schema description already explaining its purpose ('The agent ID to retrieve'). The tool description adds minimal additional meaning beyond 'by ID', so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: retrieving full details for a single agent by ID. It lists specific return fields (voice config, model, prompt, language, call behavior, workflow type), distinguishing it from sibling tools like get_agents (which retrieves multiple agents) or get_agent_performance.

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

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

The description implies usage when an agent ID is available, but does not explicitly state when to use this tool vs alternatives like get_agents or get_agent_prompt. No guidance on prerequisites or when not to use it.

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

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

No annotations exist, so the description must fully disclose behavior. It does not mention whether the tool is read-only, if results are aggregated, paginated, or sorted, nor any permission or data freshness requirements. The description assumes a read operation but fails to confirm it.

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

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

The description is two sentences, starting with the core purpose. It is concise and front-loaded, wasting no words.

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

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

The tool has 5 optional parameters and no output schema. The description could be more complete by explaining expected output structure, sorting behavior, or limitations (e.g., time range constraints). As a performance comparison tool, missing details about aggregation and ranking reduce completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema provides (e.g., filtering logic, defaults).

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

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

The description clearly states the tool shows agent performance metrics (calls, duration, completion rate, cost). It implies comparison and identifies the resource (agent performance). While it distinguishes from general agent listing tools, it does not explicitly differentiate from other performance-related siblings like get_hourly_performance.

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 phrase 'Use to find top and bottom performers' gives a concrete use case. However, no guidance is provided on when not to use this tool (e.g., for individual agent details) or alternatives among siblings.

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

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

Without annotations, the description carries the full burden. It accurately indicates a read operation (non-destructive) and specifies the return content (prompt text and tools). However, it does not mention idempotency, authorization requirements, or rate limits, which would add safety information.

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

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

The description is a single sentence that concisely states the purpose and return value. It is front-loaded with the verb 'Read', making it immediately clear what action the tool performs.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description completely covers what the tool does and returns. It provides sufficient context for an agent to understand the tool's capabilities.

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

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

The schema already covers 100% of the parameter (agent_id) with a clear description. The tool description does not add additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool reads the system prompt for an agent and returns the prompt text and configured tools. It distinguishes itself from sibling tools like update_agent_prompt (which writes) and get_agent (which returns agent metadata).

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

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

The description provides no guidance on when to use this tool versus alternatives. Among many sibling get_* tools, there is no explicit context for when reading the prompt is appropriate or what alternatives (like get_agent) offer different data.

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?

No annotations are provided, so the description carries full burden. It states it lists agents and supports pagination/filtering/sorting, but does not explicitly declare read-only behavior, auth requirements, rate limits, or potential network latency. The description is clear but lacks deeper behavioral context.

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

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

The description is concise (two sentences) and front-loaded with the primary action. Every sentence adds value without redundancy or fluff.

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 listing tool with 7 optional parameters and no output schema, the description covers the key capabilities and return fields. It lacks details on empty results, error handling, or rate limits, but given the complexity and sibling context, it is fairly 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 100%, so each parameter is described in the schema. The description adds a high-level statement about supporting pagination, filtering, and sorting, but does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists AI agents and returns configuration details including voice, LLM model, language settings, and call statistics. It specifies support for pagination, filtering, and sorting, which distinguishes it from sibling tools like get_agent (single agent) and get_agent_performance.

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

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

The description implies usage for listing agents but does not provide explicit guidance on when to use this tool versus alternatives like get_agent for a single agent. No when-not-to-use scenarios are mentioned, but the context of sibling tools makes it somewhat clear.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It indicates a read operation ('list') but does not mention authentication needs, rate limits, or what happens if the agent has no subscriptions. The description lacks depth beyond the basic action.

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

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

The description is a single clear sentence that directly states the purpose and provides specific event types. It is concise and front-loaded with no unnecessary words.

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

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

Given no output schema, the description does not explain return values or structure. For a list tool, it would be helpful to mention that the response contains an array of subscriptions with webhook IDs and events. The description is adequate but 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?

With 100% schema description coverage, baseline is 3. The description adds value by specifying the events (pre-conversation, etc.) and clarifying that it lists 'current' subscriptions, which goes beyond the schema's simple 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?

The description clearly states 'List an agent's current webhook subscriptions' specifying the verb 'list' and resource 'webhook subscriptions'. It also mentions the events (pre-conversation, post-conversation, analytics-completed), distinguishing it from sibling tools like 'get_webhooks' and 'get_webhook_events'.

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

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

The description implies usage for retrieving subscriptions for a specific agent but does not provide explicit guidance on when to use versus alternatives like 'get_webhooks' or when not to use. No exclusions or alternative references are given.

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

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

No annotations are provided, so the description carries the full burden. It states the tool shows data but doesn't disclose side effects, authentication needs, or rate limits. As a read operation, it's safe, but more transparency would be beneficial.

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

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

The description is two sentences, front-loading the purpose with no extraneous words. It is concise and well-structured.

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

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

With no output schema, the description adequately explains the return value (volume and success rate by attempt number). Parameters are optional and clearly described in the schema. The tool is simple and the description is sufficient.

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%, fulfilling the baseline. The description does not add parameter-specific meaning beyond the schema; it focuses on output. No additional semantic value is provided for the parameters.

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

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

The description clearly identifies the tool as getting an attempt cohort analysis, specifying it shows volume and success rate by attempt number. It distinguishes itself from sibling tools, none of which focus on cohort analysis.

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 states it's useful for optimizing retry strategies, giving clear context for use. It does not explicitly mention when not to use or alternatives, but the purpose is clear enough for appropriate 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?

No annotations provided, so description carries the burden. It only states 'Get details', implying a read-only operation but does not explicitly declare idempotency, side effects, or permissions. For a simple read tool, it is minimally sufficient but could be more transparent.

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?

Single sentence with 17 words, front-loading the action and key output fields. Every word earns its place with no redundancy. Highly concise and well-structured.

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

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

Given no output schema, the description hints at return fields (name, description, phone number column name), which helps the agent understand what to expect. However, it does not mention error handling, empty results, or full output structure. For a simple tool, this is mostly 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 has 100% coverage with one parameter (audience_id) described as 'The audience ID'. Description adds 'by ID' but no extra semantics about format, source, or constraints. Baseline score 3 is appropriate since schema already describes the parameter adequately.

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

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

The description clearly states the tool retrieves details for a specific audience by ID, listing specific fields like name, description, and phone number column name. This distinguishes it from siblings like get_audiences (list) and get_audience_members (list members).

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 explicit guidance on when to use this tool versus alternatives. The name and description imply it's for single audience details, but it does not mention get_audiences for listing or when not to use it. Adequate but lacks explicit 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?

With no annotations, the description provides relevant behavioral context: it returns a list of members with pagination and details the data object structure (phone number and other fields). It does not cover rate limits or auth, but for a read operation, the disclosure is adequate.

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

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

Two short sentences: the first delivers the core purpose and pagination, the second adds detail on return structure. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the essential aspects: purpose, pagination, and member data shape. Lacks details on edge cases (e.g., empty audience), but overall adequate.

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

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

Schema coverage is 100% with full descriptions for all three parameters (audience_id, page, page_size). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'members (contacts) in an audience', and mentions pagination. This distinguishes it from sibling tools like search_audience_members, which implies filtering.

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

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

The description implies usage for listing all members with pagination. It does not explicitly state when to use this vs. search_audience_members, but the context of sibling tools makes the distinction clear.

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

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

No annotations are provided, so the description carries the full burden. It states the tool lists data, implying a read-only operation, but does not explicitly confirm no side effects, mention authentication, rate limits, or pagination. The term 'list' suggests safety, but lacks explicit behavioral guarantees.

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 efficient sentences. The first front-loads the action and output, and the second provides context on what audiences are. No wasted words.

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

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

For a simple list-all tool with no parameters and no output schema, the description covers the essential purpose and output. It could mention pagination or limits, but the context is generally complete given the low 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?

The tool has zero parameters, so schema coverage is 100%. The description adds value by explaining the output fields, which is sufficient for a parameterless tool. Baseline for 0 params is 4, and the description meets it.

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

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

The description clearly states the tool lists all audiences in the organization and specifies the exact fields returned (name, member count, linked campaigns, phone number column). It distinguishes itself from sibling tools like 'get_audience' and 'get_audience_members' by focusing on listing all audiences.

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 use when you need a list of all audiences but does not explicitly compare with alternative tools like 'get_audience' for a specific audience. No guidance on when not to use or 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?

With no annotations, the description carries the full burden. It explains what auto-reload does (automatically adds credits when balance drops below a threshold), providing behavioral context beyond a simple 'get configuration'. However, it does not disclose permissions or output format.

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

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

Two sentences with no wasted words. The first sentence states the purpose, and the second adds useful context about auto-reload functionality.

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

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

For a zero-parameter read operation without an output schema, the description is sufficiently complete. It explains the feature and its purpose. Minor omission: does not hint at the returned configuration structure, but it is adequate.

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

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

The tool has zero parameters and 100% schema coverage (empty schema). Per guidelines, baseline is 4. The description adds no parameter info, which is acceptable as none exist.

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

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

The description clearly states it retrieves the auto-reload configuration for the organization, using the verb 'get' and specifying the resource. It distinguishes from siblings like get_billing_alerts by focusing on auto-reload's credit-add behavior.

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 use for reading auto-reload settings but does not explicitly state when or when not to use it, nor does it mention alternatives or prerequisites. The context is clear but lacks exclusion 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?

No annotations are provided, but the description accurately indicates a read-only operation. It could be improved by stating that it does not modify state, but for a simple get with no parameters, this is adequate.

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

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

Two concise sentences that front-load the action and provide context with no unnecessary words.

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

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

Given no parameters and no output schema, the description is mostly complete. It explains the tool's purpose and the concept of billing alerts. It could mention the expected return structure, but it's not critical.

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 schema coverage is 100%. The description adds no parameter info, but that is acceptable as there are none to describe.

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

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

The description clearly states 'Get the current billing alert configuration for your organization' with a specific verb and resource. It distinguishes from siblings like update_billing_alerts.

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

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

The description explains what billing alerts are, implying when to use this tool (to view thresholds). However, it doesn't explicitly contrast with alternatives like get_credit_balance, though the purpose is distinct enough.

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

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

Without annotations, the description carries full burden. It reveals that each branch has at most one open draft and that the tool returns the latest draft revision and edit history. This is transparent for a read operation, though it could explicitly state it is read-only.

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

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

Two sentences pack all necessary information without waste. The first sentence defines the tool; the second provides context and a usage tip. Every word earns its place.

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

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

For a simple tool with 2 parameters and no output schema, the description covers the what, the input hints, and a key constraint (max one draft). It could mention the output structure more, but the mention of 'edit history' suffices.

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

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

The description adds significant meaning beyond the schema: for branch_id, it explains where to get the value (from list_branches), that omitting it gives the live branch, and behavior with multiple branches. This is exemplary.

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

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

The description clearly states the verb 'Get', the resource 'a branch's pending (unpublished) draft', and specifies what is included ('latest draft revision and edit history'). It also distinguishes from siblings like list_branches and other branch operations.

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

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

It explicitly tells when to use this tool and points to list_branches as an alternative to check for drafts. It could be improved by stating when not to use it, but the guidance is clear and contextually helpful.

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?

No annotations provided, so description must disclose behavior. It only states it returns a histogram, but does not mention it is read-only, whether results are limited, or how missing data is handled.

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 key purpose. No fluff, but could include slightly more detail without harming conciseness.

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

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

With 5 parameters and no required fields, the description does not explain how aggregation works, date handling, or output list structure. Lacks completeness for a tool with moderate complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.

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

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

The description clearly states the tool gets call count per day as a histogram with day-count pairs. It uses a specific verb and resource, but does not differentiate from similar sibling tools like get_call_volume or get_daily_summary.

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

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

No guidance on when to use this tool versus alternatives. No explicit context, prerequisites, or exclusions provided.

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

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

No annotations provided, so description carries the burden. It mentions daily breakdown and totals, indicating a read-like operation, but lacks details on auth needs, rate limits, or behavior with no data. Adequate but not comprehensive.

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?

Single sentence, front-loaded with action, no wasted words. Efficiently conveys purpose and output nature.

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

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

Given 5 optional parameters and no output schema, description explains return (daily breakdown of categories plus totals) but omits defaults (e.g., date range defaults) and output structure. Adequate but could be more complete.

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

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

Schema coverage is 100% with clear parameter descriptions. The description does not add extra meaning beyond the schema, such as explaining defaults or relationships. 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?

Description clearly states the tool provides call outcome distribution over time with specific categories (completed, failed, no-answer) plus totals. It uses a specific verb 'Get' and resource 'call outcome distribution', distinguishing it from siblings like get_call_counts_by_day.

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?

Description implies usage for analyzing call outcomes over time but does not explicitly state when to use or not, nor mention alternatives among siblings. Usage is implied but no exclusions or context provided.

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

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

No annotations are provided, so the description carries the full burden. It correctly implies a read operation but does not disclose any behavioral traits such as authentication requirements, rate limits, or whether the data is live or cached. For a simple aggregation, the description is adequate but minimal.

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

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

The description consists of two sentences with no redundancy. The verb and resource are front-loaded, and every word contributes to understanding. It is appropriately sized for the tool's simplicity.

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

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

Given the tool's low complexity (2 parameters, no output schema), the description is complete. It explains the input (date), optional filter (agent_id), output format (hourly counts), and use case. No additional details are needed for an AI agent to invoke this tool correctly.

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

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

Schema coverage is 100% with both parameters described in the schema. The description adds value by explaining the output format ('each hour (0-23)') and reinforcing the date parameter's role. This goes beyond the baseline of 3 by providing additional context not in the schema.

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

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

The description uses a specific verb ('Get') and resource ('call start distribution') with clear scope ('by hour for a specific date'). It explicitly states the output ('how many calls started in each hour (0-23)'), which distinguishes it from sibling tools like get_call_counts_by_day or get_call_volume that aggregate differently.

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

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

The description provides a usage hint ('Useful for scheduling and capacity planning') but does not explicitly state when not to use this tool or compare it to alternatives. This is implied usage guidance, not explicit exclusion or context for tool 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?

With no annotations, the description carries full burden. It discloses that output is a daily timeseries but omits details about response structure, aggregation behavior, permissions, or rate limits. It is adequate but not thorough.

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

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

The description is concise at two sentences, front-loading the core purpose. It could be slightly more efficient but avoids unnecessary detail.

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

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

Given the lack of an output schema and the presence of five optional filters, the description should explain the return format (e.g., array of objects) and aggregation behavior. It mentions 'daily timeseries' but is insufficiently detailed for complete understanding.

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 all parameters are well-described there. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a daily timeseries of call volume, specifying the verb 'Get' and resource 'call volume over time as a daily timeseries'. However, it does not differentiate from the sibling tool 'get_call_counts_by_day', which likely serves a similar purpose.

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

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

No guidance is provided on when to use this tool versus alternatives like 'get_call_counts_by_day' or other analytics tools. The description implies usage for daily volume trends but lacks explicit context or exclusions.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It implies a read-only operation but does not explicitly state non-destructiveness, auth requirements, 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?

Single sentence with front-loaded purpose, no redundant words, and efficiently structured.

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

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

Given the tool has only one parameter and no output schema, the description sufficiently explains what data is returned, making it complete for its complexity level.

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% for the single parameter, but the description adds no further semantic value beyond the schema's basic 'campaign ID' description. Baseline score is appropriate.

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

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

The description clearly states the tool retrieves detailed information about a specific campaign, listing specific elements like status, execution progress, events timeline, and metrics. This distinguishes it from other 'get_*' tools for different resources.

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

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

The description implies usage when detailed information on a single campaign is needed, but lacks explicit guidance on when not to use it or mention of alternatives among siblings.

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

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

No annotations provided, so description carries the full burden. It mentions the fields returned (status, progress, agent used, etc.) and implies a list operation with pagination via schema. However, it doesn't state that it's read-only or disclose any potential side effects.

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

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

Two efficient sentences: first states the purpose, second lists the data fields returned. No wasted words; every sentence adds value.

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

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

Given 6 parameters, no output schema, and no annotations, the description adequately covers the tool's purpose and output fields. It lacks mention of pagination behavior but the schema covers that. Overall sufficient for a list tool.

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

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

Schema coverage is 100% with detailed descriptions for all 6 parameters. The description adds no additional parameter information beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states 'List outbound calling campaigns' (verb+resource) and enumerates the data fields shown (status, progress, agent used, audience, etc.). It distinguishes from sibling get_campaign (singular) by implying this returns multiple campaigns.

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

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

No explicit guidance on when to use this tool versus alternatives like get_campaign (singular) or other get_* tools. The description does not mention filtering, sorting, or when to avoid using 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?

No annotations are provided, so the description carries full burden. It clearly indicates it's a read operation returning concurrency data, with no mention of destructive behavior. The description adds value by specifying the type of data 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?

The description is two concise sentences, front-loaded with the core purpose, and contains no fluff. Every part adds value.

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

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

For a tool with two parameters and no output schema, the description explains the output (minute-by-minute concurrency, per-agent max) adequately. It could be improved by mentioning output format, but it's fairly complete.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description adds context about output but does not add new semantic meaning beyond the schema's parameter descriptions.

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

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

The description clearly states the tool retrieves concurrent call counts for a specific date, with minute-by-minute and per-agent max concurrency. It distinguishes itself from siblings like get_call_counts_by_day by focusing on concurrency.

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

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

The description implies usage for querying concurrency but does not explicitly specify when to use this tool versus alternatives such as get_call_volume or get_call_counts_by_day.

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?

No annotations are provided, so the description carries full behavioral burden. It indicates a read operation and outlines returned data (balance, plan, enterprise status), but does not disclose authentication requirements, rate limits, or potential side effects. For a simple getter, this is adequate but not rich.

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

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

A single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word is meaningful with no redundancy.

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

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

Given the tool's simplicity and lack of output schema, the description sufficiently covers the main return values. Minor gaps (e.g., currency, real-time nature) are not critical for this getter 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?

The tool has no parameters, and schema description coverage is 100%. The description adds value by specifying the output includes balance, plan info, and enterprise status. This exceeds the baseline for zero-parameter tools.

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

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

The description clearly states the tool retrieves the current credit balance, plan information, and enterprise status for the organization. It uses a specific verb and resource, distinguishing it from siblings like get_credit_ledger and get_credit_usage.

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

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

The description implies the tool is for checking the organization's current credit balance, but it does not explicitly differentiate when to use this versus related billing tools. No exclusions or alternatives are provided.

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

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

No annotations exist, so the description carries the burden. It states 'Get' implying read-only, but doesn't confirm auth needs, rate limits, or pagination behavior beyond parameters. Lacks explicit safety guarantees, but adequately describes what the tool returns.

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

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

Two sentences efficiently convey purpose and key features. Front-loaded with the primary action (Get credit transaction history) and then details. No unnecessary words, though slight structure improvement could combine ideas.

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?

Despite 6 parameters and no output schema, the description omits return format, default sorting, pagination details, and any behavioral caveats. Given sibling diversity, more context (e.g., response structure) is needed for robust usage.

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

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

Schema description coverage is 100%, so the schema already documents each parameter well. The description adds only a high-level mention of filtering, not deeper meaning. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves credit transaction history (ledger) and lists specific transaction types (purchases, usage deductions, etc.), which distinguishes it from sibling tools like get_credit_balance and get_credit_usage.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_credit_balance, get_credit_usage). It doesn't mention prerequisites or scenarios where this tool is preferred, leaving the agent to infer 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?

No annotations are provided, so the description bears full responsibility. It discloses the tool returns daily credits consumed and totals, but does not mention that it is read-only, any authentication requirements, or potential rate limits. It adequately conveys behavior for a simple data retrieval tool.

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

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

The description is concise: two sentences with no filler. The first sentence states the purpose and output, the second adds context on usage. Every word earns its place.

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

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

Given no output schema, the description includes the key output details (daily credits consumed and total). Parameter coverage is complete. It could be more precise about the output format, but for a straightforward time-series tool, it is largely sufficient.

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

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

Schema coverage is 100% with both parameters documented with descriptions. The description does not add extra meaning beyond what the schema already provides (ISO 8601 format, defaults). Baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool retrieves daily credit/cost usage over time, specifying per-day and total values. It distinguishes from many sibling tools by focusing on usage rather than balance or alerts, though it could explicitly differentiate from get_credit_balance or get_credit_ledger.

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 states it is useful for billing and budget tracking, implying when to use. However, it does not specify when not to use it or mention alternatives such as get_credit_balance for current balance or get_billing_alerts for alerts.

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?

No annotations provided, so description carries burden. It correctly indicates a read operation (Get summary statistics) and lists metrics, but lacks disclosure on authentication needs, rate limits, or whether data is aggregated across all users.

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?

Single concise sentence with a clear list of metrics. No wasted words, front-loaded with purpose.

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

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

For a simple summary tool with 2 parameters and no output schema, the description is fairly complete: it lists all returned metrics and implies a read-only operation. Could mention date format expectations but schema already specifies that.

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. Description does not add meaning beyond schema; it only restates that the tool retrieves for a specific date. No elaboration on agent_id filtering.

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?

Description clearly states the verb 'Get' and resource 'summary statistics for a specific date', lists all returned metrics (total calls, completed, etc.), distinguishing it from sibling tools like get_call_counts_by_day or get_duration_stats.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_call_volume, get_hourly_performance). Does not mention context such as required permissions or date constraints.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. It does not disclose whether the operation is read-only, its performance implications (aggregation may be slow), required permissions, or response size. The description only lists contents, not behaviors.

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

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

The description is a single sentence that front-loads the main purpose and efficiently lists included content. Every part earns its place; no redundant or filler language.

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

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

Given the tool's complexity (aggregating multiple metrics) and the lack of an output schema, the description adequately indicates what the tool returns. However, it omits default behavior for optional parameters (e.g., date range defaults) and does not mention pagination or response structure; a bit more detail would increase completeness.

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

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

Schema coverage is 100%, so the description adds no additional meaning beyond what the schema already provides. It lists the output categories but does not explain parameter usage or defaults. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('full analytics dashboard') and lists the included metrics, clearly distinguishing it from sibling tools that focus on individual metrics. 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?

The description implies through its wording ('in a single call') that this is for a consolidated view, but it does not explicitly state when to use this versus individual tools like get_call_volume or get_duration_stats. Some guidance on trade-offs would improve clarity.

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?

No annotations are provided, placing full burden on the description. It states what statistics are returned but fails to disclose behavioral traits such as being a read-only operation, data freshness, side effects, or any constraints. The description offers minimal transparency beyond the output values.

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

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

The description is two sentences long and front-loaded with key information. The second sentence is slightly redundant ('Shows how long calls typically last' is implied by the first), but overall it is efficient and not verbose.

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

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

With 5 parameters, no output schema, and no annotations, the description adequately explains the returned statistics but omits details like default behavior of date parameters, time zone handling, and output format. It is sufficient for basic use but lacks completeness for an agent to fully understand invocation context.

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

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

Schema description coverage is 100%, so each parameter is documented. The description adds context about the statistics but does not provide additional meaning for the parameters themselves (e.g., format requirements or behavioral implications). Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'call duration statistics', listing specific metrics (average, median, min, max, p95) and providing a concise summary. It effectively differentiates from sibling tools like 'get_call_volume' which focuses on counts rather than duration.

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

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

The description implies usage for understanding call length but does not provide explicit guidance on when to use this tool versus alternatives like 'get_daily_summary' or 'get_call_outcomes'. It lacks 'when-to-use' and 'when-not-to-use' instructions.

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?

No annotations are provided, so the description must fully convey behavior. It lists the returned metrics but does not disclose details like timezone handling, whether optional filters affect scope, or if results are sorted by hour. The description is adequate but not thorough.

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

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

The description is two sentences, front-loading the core purpose and key outputs. Every word is relevant, with no wasted content.

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

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

Given the tool has 5 optional parameters and no output schema, the description provides basic context but omits details like timezone, data ordering, or whether empty hours are returned. It is minimally complete for a simple aggregation 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?

The input schema covers 100% of parameters with descriptions (e.g., start_date, end_date, agent_name). The description does not add extra meaning beyond the schema, so baseline score of 3 applies.

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

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

The description explicitly states 'Get performance metrics by hour of day (0-23)' and lists the metrics shown (call count, average duration, cost per hour). It distinguishes from sibling tools that aggregate daily or weekly, such as 'get_daily_summary' and 'get_weekly_trends'.

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 includes 'Useful for identifying peak hours,' which implies the tool is for analyzing hourly patterns. However, it does not explicitly state when not to use it or provide alternative tools for different aggregations.

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?

No annotations provided. The description implies a read-only listing but does not disclose behavioral traits such as pagination, data freshness, or any limitations on the number of invoices returned. It adds some context by mentioning Stripe as the source but lacks details about side effects or 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 concise sentences that front-load the purpose. No fluff, every word earns its place.

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

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

For a simple list tool with no parameters and no output schema, the description covers the key aspects: what it does (list invoices) and what it shows (details). Could optionally mention ordering or date range, but completeness is adequate 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?

No parameters in the schema, which is expected for a simple list-all tool. The description adds meaning by specifying the source (Stripe) and the type of details shown (amounts, status, dates). Per guidelines, baseline for 0 parameters is 4, and the description meets this adequately.

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

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

Description clearly states it lists all invoices from Stripe with details like amounts, status, dates. The verb 'List' and resource 'invoices' are specific, and it distinguishes from sibling tools like get_billing_alerts or get_payment_methods by focusing on invoices.

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

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

No guidance on when to use this tool versus alternatives like get_billing_alerts or get_credit_balance. The description does not mention when to use or not use it, nor any prerequisites or exclusions.

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

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

With no annotations, the description carries full burden. It discloses that the tool is read-only (list), shows specific fields, and indicates the default card. No mention of authentication or rate limits, but given zero parameters, the behavioral disclosure is adequate.

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

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

The description is a single, concise sentence that front-loads the action and resource. No unnecessary words.

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

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

For a zero-parameter list tool with no output schema, the description covers purpose, scope, and output fields completely. No gaps remain.

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 schema coverage is 100%. The description adds no parameter info because none exist. Baseline 4 is appropriate.

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

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

The description clearly states the tool lists all payment methods (cards) for the organization, with specific fields (brand, last 4 digits, expiry, default). This verb+resource+scope is distinct from sibling tools like get_invoices or get_billing_alerts.

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 explicit when-to-use or when-not-to-use guidance is provided. While the tool's purpose is clear, an explicit statement about when it's appropriate versus alternatives would improve usability.

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?

No annotations are provided, so the description carries full burden for disclosing behavior. While the verb 'List' suggests a read-only operation, the description does not explicitly state it is safe, has no side effects, or require specific permissions. This is inadequate for transparency.

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

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

Two sentences with no extraneous words. The first sentence states the purpose, the second provides useful detail. Perfectly sized and front-loaded.

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

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

Given no parameters and no output schema, the description covers what the tool returns and even cross-references another tool (make_call). This is complete 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?

The tool has no parameters and 100% schema description coverage. The description adds value by listing the returned fields (product ID, number, country, provider, assigned agent), which clarifies the output beyond 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 clearly states 'List phone numbers acquired by your organization,' specifying a clear verb and resource. It distinguishes itself from sibling tools like get_phone_number_trends by focusing on listing acquired numbers, and adds unique context by noting the product ID is needed for make_call's from_product_id.

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

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

The description implies usage for viewing available phone numbers and their attributes, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or 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?

No annotations provided; description carries full burden. It omits behavioral details such as whether trends are aggregated across all numbers, pagination, data freshness, or output structure.

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?

Single sentence, no filler, front-loaded with purpose and key metrics. Every word contributes.

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

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

No output schema; description does not specify return structure (e.g., array of objects, keys). Missing details on how per-number granularity is represented, leaving the agent uncertain about using the tool for specific queries.

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

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

Schema coverage is 100% with descriptions for all 5 parameters. The description adds overall context but does not enhance parameter understanding 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?

Description states specific verb 'Get' and resource 'per-phone-number daily trends', listing metrics (calls, pickup rate, average duration). This clearly distinguishes from sibling tools like get_call_counts_by_day or get_daily_summary.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_daily_summary or get_call_volume). Lacks explicit context or exclusions.

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

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

Since no annotations are provided, the description bears full responsibility. It accurately conveys the read-only nature of the tool and what it returns. It does not mention authorization or rate limits, but for a simple query tool, the description is sufficiently transparent.

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

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

The description is concise: two sentences with no wasted words. It front-loads the main purpose and includes the key output fields, making it easy to scan quickly.

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

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

The tool has 5 optional parameters and no output schema, so the description should cover return structure. It lists the returned metrics (total calls, answered calls, pickup rate) and implies a per-phone-number list. Some additional detail about response format would be helpful, but it is fairly complete given the simplicity of the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific information beyond what is already in the schema. It mentions 'by phone number' but the parameters are about dates, agent, campaign, and call type, without explaining how they affect results.

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

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

The description clearly states it gets pickup rate by phone number, listing the returned metrics (total calls, answered calls, pickup rate) and the use case for optimizing caller IDs. This is specific and distinguishes it from many sibling tools that focus on agents, campaigns, or versions.

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

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

The description provides clear context by stating it is useful for optimizing caller IDs, but does not explicitly mention when not to use it or compare with alternative tools like get_phone_number_trends. The guidance is implied but lacks exclusions.

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

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

No annotations are provided, so the description carries the full burden. It clearly explains the two modes of operation (list all plans vs. get features for a specific plan) and implies a read-only behavior without stating destructive actions. Additional details on authentication or rate limits are not needed for this simple tool.

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

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

The description is two sentences with no extraneous information. The first sentence states the core functionality, and the second provides usage guidance. Every word earns its place.

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

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

Given the tool's simplicity (one optional parameter, no output schema, no nested objects), the description fully explains both modes of operation and the intended use. It is complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with a clear description for plan_id. The description adds value by explaining the effect of providing the parameter ('also returns the features for this specific plan'), which goes beyond the schema's description.

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

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

The description states a specific verb ('List') and resource ('available plans') and also clarifies the conditional behavior when a plan is specified. It clearly distinguishes from sibling tools that deal with other entities.

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

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

The description explicitly states the use case ('to understand plan pricing, included features, and credit rates'), providing clear context. It does not explicitly state when not to use it or list alternatives, but for a simple listing tool this is acceptable.

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

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

No annotations provided, so description carries full burden. It discloses read-only nature, the logic for selecting draft vs head, and that passing specific parameters returns more detail. No side effects or permissions mentioned, but overall transparent.

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?

Single paragraph of 3-4 sentences, front-loaded with main purpose and components. Efficient but could be slightly more structured with bullet points for 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?

Given no output schema and no annotations, the description adequately explains return content (config components) and parameter behaviors. Does not describe return format or errors, but sufficient for an AI agent to select and invoke correctly.

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

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

Schema coverage is 100% with descriptions. The description adds extra context: branch_id explains behavior when omitted and draft stacking; playbook_id says it returns full config. This adds meaningful value beyond the schema.

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

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

Description clearly states the tool reads a multi_agents agent's Playbooks config, listing specific components (intent router, shared auth tools, SOP list). It distinguishes from sibling tools by focusing on reading config, and uses a specific verb 'Read' with clear resource scope.

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 context on when to use variants (with playbook_id for full detail, branch_id for targeting a branch) but does not explicitly mention when not to use or compare to alternatives like get_branch_draft. The branch draft vs head logic gives clear guidance on expected behavior.

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

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

No annotations provided, but the description clearly indicates this is a read operation (retrieving committed revision). It doesn't disclose potential access requirements or rate limits, but for a simple get operation this is adequate.

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

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

Two concise sentences: first states the core functionality, second provides usage guidance. No unnecessary words or filler.

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

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

For a tool that retrieves a specific revision, the description is complete: it specifies what is returned (metadata, config) and tells the agent how to obtain the required revision ID. No output schema is present, but the description compensates by describing the output.

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 parameters are already well-documented. The description adds the context that the result includes metadata and config, but doesn't provide additional per-parameter meaning beyond the schema.

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

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

Description clearly states the tool retrieves a single committed revision with its metadata and fully resolved config. It distinguishes from siblings like list_revisions (which lists IDs) and diff (which compares revisions).

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 to use list_revisions to find revision IDs, providing clear when-to-use guidance and naming the alternative.

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?

No annotations are provided, so the description bears full responsibility for behavioral context. It states the tool returns a breakdown and scopes it to 'your organization,' but does not disclose permissions, rate limits, or behavior when data is absent. This is adequate but not rich.

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

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

Two concise sentences front-load the core purpose and add specific service examples. No unnecessary words or repetitions.

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

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

With no parameters, no output schema, and no annotations, the description adequately conveys the tool's purpose and what it returns. It could mention output format or pagination, but it's sufficiently complete for a simple read 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?

The tool has zero parameters, so schema coverage is trivially 100%. Per guidelines, baseline is 4. The description does not add parameter semantics because there are none to explain.

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

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

The description clearly identifies the tool's function: get a breakdown of credit usage by feature and product scope. It explicitly mentions services (voice AI, voice models, platform), making it distinct from siblings like get_credit_balance or get_credit_usage, which are likely simpler totals.

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

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

The description implies usage for detailed breakdowns but does not explicitly state when to use this tool versus alternatives like get_credit_usage or get_usage_stats. No direct comparison or exclusions provided.

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

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

With no annotations provided, the description carries the full burden of transparency. It describes the returned metrics and period comparisons, but does not disclose any behavioral traits such as data freshness, permission requirements, or rate limits. It is adequate but minimal.

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

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

The description is two sentences long, front-loaded with the core purpose, and contains no filler. Every word adds value, making it an example of concise and well-structured documentation.

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

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

The description lists the metrics returned but lacks details on the output structure or example. With no output schema, a bit more detail would improve completeness. However, for a simple statistics tool, the current level is average.

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

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

The input schema covers all 5 parameters with descriptions, achieving 100% coverage. The description adds no additional meaning beyond the schema, only repeating the date range implicitly. A baseline score of 3 is appropriate since the schema already provides sufficient documentation.

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

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

The description clearly states the tool returns call usage statistics including total calls, pickup rate, duration, costs, and unique users. It also specifies that metrics include current period, previous period, and percent change, making the purpose unambiguous and distinct from related tools like get_call_counts_by_day or get_pickup_rates.

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 says 'Useful for understanding usage patterns and costs,' which implies when to use it but does not explicitly state when not to use it or how it differs from alternatives like get_usage_breakdown or get_daily_summary. No exclusions or conditions are provided.

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