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

With no annotations, the description carries the full burden, and it does disclose two useful behaviors: address_type is constrained to 'tel'/'email' with a 400 rejection, and is_primary changes the primary address of its type. It says nothing about auth/permissions, duplicate handling, or other error modes, so meaningful gaps remain 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?

Purpose is front-loaded in one line followed by a clean per-argument block with no filler. The 'Args:' enumeration is mechanical but every line documents a distinct parameter, so nothing is wasted.

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

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

An output schema exists, so return values need not be described, and all six parameters plus the address_type validation are documented. The remaining gap is mutation-side behavior (permissions, duplicate/conflict handling) that an unannotated write tool should ideally state.

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

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

Schema description coverage is 0%, so the description must compensate fully and it does: it gives the UUID nature of contact_id, the string constraint on address_type, the E.164 vs email format of target, and the meaning of the optional name, detail, and is_primary fields. This is richer than the bare schema titles.

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 verb 'Add' and the resource are clear once the Args block is read, but the headline sentence 'Add a way to reach a contact' describes the concept obliquely rather than saying 'contact address'. It distinguishes itself from delete_contact_address/update_contact_address only by implication of the verb, not by explicit sibling reference.

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 versus update_contact_address or delete_contact_address, no prerequisites, no mention of what happens when the same address already exists. The agent must infer the create-vs-update distinction from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states a mutation ('Attach') but does not describe idempotency, what happens if the tag is already attached, required permissions, or error behavior. For a mutating tool with zero annotation coverage, this is a significant gap.

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 and an Args list, front-loaded with the core action. Every element earns its place, with no redundancy or filler. It is appropriately sized for a simple two-parameter tool.

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

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

An output schema exists, so return values need not be explained. However, the description omits usage guidance and behavioral details for a mutation tool with no annotations. For a simple attach operation the parameter documentation is adequate, but the context is 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 description coverage is 0%, so the description must compensate. It documents both parameters by name and meaning: contact_id as the UUID of the contact and tag_id as the UUID of the tag to attach. This adds clear semantic value beyond the bare schema titles, though it does not provide format examples or validation 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 states a specific verb and resource: 'Attach a tag to a contact.' This clearly distinguishes it from the sibling delete_contact_tag by the verb 'attach'. However, it does not explicitly name any alternative tool or explain the relationship to add_contact_address or update_contact.

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

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

There is no guidance on when to use this tool versus alternatives such as delete_contact_tag or update_contact. No prerequisites, side effects, or context for invocation are provided. The description only states what the tool does, leaving the agent to infer usage.

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 and does so well: it warns that unsupported engine_model/tts_type/stt_type values surface as an opaque 500 with no field indication, that engine_key is stored and transmitted verbatim, that environment-variable references are not expanded (so '$OPENAI_API_KEY' is sent literally), and that the key is returned in API responses and server logs. It also clarifies that the 'parameter' field is not engine tuning and reaches the model as prose in the system prompt. This is rich, non-obvious behavioral disclosure.

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 long, but it is front-loaded with purpose and safety guidance and every line carries unique information, especially the engine_key and parameter warnings that cannot be inferred. Minor redundancy in the provider example lists, but no filler sentences.

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

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

For a 10-parameter mutation tool with an output schema, the description covers what is created, the accepted value formats, the failure mode, and the security implications of the credential field. With return values handled by the output schema, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate entirely, and it documents all ten parameters: engine_model format '<vendor>.<model>' with the vendor-prefix validation rule, engine_key semantics and exposure, tts_voice_id format example, stt_language BCP-47 default, and an extended explanation correcting the misleading 'parameter' name. This far exceeds what the bare schema provides.

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

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

The first line states a specific verb and resource: 'Create a new AI voice agent.' This clearly separates it from the read-only siblings list_ais and get_ai. It does not explicitly name alternatives, but the create-vs-list/get distinction is unambiguous from the name and opening sentence.

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

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

Usage is implied (this is the creation counterpart to list_ais/get_ai) but never stated as when-to-use vs alternatives. The description does give operational routing guidance — treat a 500 as a rejected argument rather than a transient fault, and do not retry unchanged — which is useful but sits closer to behavioral handling than 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 the full burden, and it offers genuine behavioral insight: it explains that unlisted type values may still be accepted but are 'not meaningful here,' and that flow_id executes only once the call connects. It omits permissions, billing/side effects, failure behavior, and rate limits, so it is partial rather than complete.

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

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

Front-loads the one-line purpose, then structured per-argument docs with no filler. The destination_type entry just cross-references source_type, which is efficient, though the long parenthetical type list is slightly verbose for the value it adds.

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?

An output schema exists, so return values need not be described, and all five parameters are documented despite zero schema coverage. Missing prerequisites and post-creation behavior are minor gaps given the tool's straightforward scope.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning, and it does: it enumerates meaningful types for source and destination, gives concrete format examples ('+14155551234' for tel, UUID for agent), and clarifies that flow_id is optional and triggered on connect. This significantly exceeds what the bare schema conveys.

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

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

States a specific verb+resource ('Create a new outbound call') and the direction of the call, which distinguishes it from hangup_call and the read-only call siblings (list_calls, get_call). It does not explicitly name an alternative or state when creating a call is the right choice over, say, reusing an existing flow.

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

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

There is no when-to-use/when-not guidance, no prerequisites (e.g. a provisioned number or agent must exist as source), and no mention of what to do next after creating the call. The entire body is parameter documentation rather than usage guidance.

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

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

No annotations exist, so the description bears the full burden, and it discloses non-obvious failure modes: omitting outplan_id/outdial_id still returns success but the campaign never dials; queue_id silently enables a pacing gate; next_campaign_id is validated but never acted upon. This is exactly the kind of context that prevents silent misconfiguration.

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

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

Purpose is front-loaded and the structure (prose caveats, then an Args block) is easy to scan. It is long for a tool description and repeats the 'never dials' point in both the prose and the Args section, so a little trimming is possible, but the length is largely justified by a 10-param tool with undocumented schema fields.

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 annotations, 10 params at 0% schema coverage, and a non-obvious pacing formula, the description supplies everything an agent needs to invoke it correctly. An output schema exists, so return values correctly need not be explained.

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

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

With 0% schema description coverage, the description must carry the full load, and it does: every one of the 10 params is documented, including enums absent from the schema (campaign_type: call|flow; end_handle: stop|continue), the 0-100 range and default for service_level, and the integer-division pacing formula tied to queue_id.

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

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

States a specific verb and resource ('Create a new outbound campaign') in the first line, which cleanly separates it from update_campaign, delete_campaign, and create_call in the sibling list. No ambiguity about what the tool produces.

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

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

Gives explicit preconditions ('Create or look up those resources first and pass their UUIDs') and conditional behavior for queue_id vs. omitting it. It even tells the agent how to work around a non-functional field ('Chain campaigns yourself instead of relying on this field'), which is actionable when-to/when-not guidance.

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

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

With no annotations, the description carries the full burden and does so richly: conference_type is unvalidated and falls back to connect behavior; timeout is in seconds, 0 disables auto-deletion, and values below 60 are replaced with 86400; post_flow_id is stored but never executed while pre_flow_id is genuinely run. These are exactly the non-obvious behaviors an agent needs.

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

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

The summary sentence is front-loaded, then each parameter note is compact and earns its place by disclosing a quirk or default. The Args list is slightly list-heavy but contains almost no filler.

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

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

An output schema exists, so return values need not be described. For a six-parameter mutation tool with no annotations, the description gives strong behavioral and parameter coverage. It lacks only usage context and any mention of permissions or name-collision behavior.

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

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

Schema description coverage is 0%, so the description is the only parameter documentation. It defines all six parameters and adds critical semantics for conference_type, timeout, pre_flow_id, and post_flow_id. Only name and detail get terse one-line glosses, but they are self-explanatory.

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

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

States a specific verb and resource: 'Create a new conference.' This clearly distinguishes it from the list/get/delete conference siblings and from other create_* tools. It stops short of explicitly contrasting with alternatives, so a 4 rather than 5.

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

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

There is no statement of when to use this tool versus alternatives or any prerequisite/auth context. The Args section covers parameter behavior, not usage conditions, so an agent gets no guidance on when creating a conference is appropriate.

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 and does so richly: gateway 400 vs. contact-manager silently skipping invalid address types, best-effort address/tag writes that still return success, duplicate-address behavior, and the unvalidated source field. These are exactly the failure modes an agent must know before calling.

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

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

Front-loaded with the one-line purpose, then dense but relevant detail; nothing is padding. There is modest redundancy in that addresses, phone_numbers and emails are described both in the address-format block and again in the Args list.

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

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

For a 12-parameter creation tool with no annotations and an output schema (so return values need not be explained), the description covers every input's semantics, defaults, and pitfall behavior, leaving nothing an agent needs to call it correctly uncovered.

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

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

Schema coverage is 0%, so the description must compensate and it does: it documents every parameter, gives the exact accepted keys (type/target/name/detail/is_primary) with requiredness and enum-style values for type, spells out source's accepted values and lack of validation, and marks phone_numbers/emails as removed in 0.2.0.

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

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

States a specific verb and resource ('Create a new contact') and clarifies the address model that distinguishes it from the address-manipulation siblings. It does not name update_contact or delete_contact as alternatives, but the creation scope 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?

Explicitly routes the agent to add_contact_address when guaranteed address persistence is required, and explains why (best-effort writes here). It also flags the removed phone_numbers/emails parameters and the default source value, giving clear call-time guidance without an explicit 'do not use when' clause.

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

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

With no annotations, the description carries the full burden and does well: it discloses that unsupported action types are rejected with a 400 naming the action, that 'transfer' is rejected here, and that a ~40-type option schema exists externally. It omits auth/permission requirements and idempotency behavior, so not a 5.

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

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

Front-loaded with the core purpose, then constraints, then a compact example, then the Args block. Every element earns its place, though the id/next_id/type/option prose is dense enough that it could be trimmed slightly.

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 create tool with a nested-array parameter, an output schema (so return values needn't be explained), and no annotations, this is nearly complete: it covers the payload shape, failure modes, and an example. Missing only permission and post-creation state semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It does so for the complex 'actions' parameter by explaining each action's id/next_id/type/option structure and giving a worked example; the trivial name/detail params are touched only lightly, leaving a small gap.

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

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

States a specific verb+resource ('Create a new flow with a sequence of actions') and defines the scope precisely. The clarification that 'transfer' is a flow type rather than an action type actively differentiates this tool's domain from related flow/campaign tools.

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

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

The description gives rich guidance about what the actions parameter accepts and how unsupported types are rejected, but never states when to use create_flow versus siblings like update_flow or create_campaign. Usage is implied by the create semantics rather than routed explicitly.

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 for behavioral disclosure. It only says 'Delete a campaign' without indicating irreversibility, permissions, side effects, or return value. This is a tautology of the tool name and provides no extra 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 very concise and front-loaded with the action. The Args block is minimal but structured. No unnecessary words are used, though it could be enhanced without becoming verbose.

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

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

For a deletion tool with no annotations and no other context, the description is notably incomplete. It fails to communicate that deletion is likely permanent or what consequences may follow. While an output schema exists and could explain return values, the description itself lacks essential context for safe 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?

Although the schema only shows campaign_id as a string with title 'Campaign Id', the description adds meaningful semantics by stating it is 'The UUID of the campaign.' This clarifies the format and purpose beyond the schema, compensating for the 0% schema description coverage.

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

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

The description clearly states 'Delete a campaign' with a specific verb and resource. This distinguishes it from sibling tools like delete_contact and delete_flow, as the resource type is explicitly named.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply restates the action without any context about prerequisites, conditions, or exclusions. There is no mention of when not to use it or which sibling might be preferable.

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, and the description simply restates the operation without disclosing consequences such as permanence, reversibility, or permissions. 'Delete' implies destructiveness, but the description adds no behavioral context beyond the name.

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

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

The description is two short sentences, front-loaded with the primary action and immediately explaining the sole parameter. 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 single-parameter delete operation, the description is minimally viable. However, it lacks any detail about side effects, error cases, or requirements, making it less complete than ideal for an unattended agent.

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

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

The schema provides only 'string' and 'Conference Id', but the description clarifies that conference_id is the UUID of the conference to delete, adding meaningful type and role information. This compensates for the bare 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 states the action ('Delete') and the specific resource ('conference'), distinguishing it from sibling delete tools like delete_contact and delete_flow. It is concise 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?

No guidance is provided on when to use this tool, prerequisites, or alternatives. The description does not mention anything like 'permanently removes' or 'use get_conference first to verify existence.'

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 only repeats the tool's name and does not mention consequences such as permanence, cascading effects, or required permissions, leaving the agent unaware of the destructiveness.

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

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

The description is extremely concise, consisting of a single sentence and a clear 'Args' section. Every word earns its place, with no fluff 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 one-parameter delete tool, the description is functional and provides the necessary parameter information. However, it lacks behavioral warnings about irreversibility or error handling. The presence of an output schema reduces the need to explain return values, but the destructive nature should be highlighted.

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 explains that contact_id is the UUID of the contact to delete, which adds meaning beyond the schema's bare type declaration. This is especially valuable given the schema description coverage is 0%. However, it is minimal and could be more explicit about format restrictions.

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 and resource: 'Delete a contact.' This distinguishes it from sibling tools like create_contact, update_contact, and get_contact, which have different verbs.

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, any prerequisites, or alternatives. It simply states the action without offering context about the deletion scenario or distinguishing between similar delete tools.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says 'Remove'. It does not disclose whether deletion is permanent/irreversible, what permissions are required, what happens on a missing address, or any cascading 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?

Front-loaded with the action in the first sentence, followed by a tight two-item Args list. No wasted text, though the Args block is boilerplate rather than genuinely informative.

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?

An output schema exists so return values need not be explained, and both params are documented. However, for a destructive mutation with zero annotations, the description should say something about irreversibility or permission requirements to be considered 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 0% (properties only have titles), but the description compensates by naming both parameters and explaining each: contact_id is the contact's UUID, address_id is the address to remove. That is enough to invoke correctly, though it adds no format or constraint detail.

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

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

States a specific verb (remove) and resource (one of a contact's addresses), scoping the deletion to a single address. This clearly separates it from the sibling add_contact_address and update_contact_address tools.

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

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

No guidance on when to use this versus update_contact_address or how it relates to delete_contact. The name and verb imply a delete operation, but nothing in the description states prerequisites or alternatives.

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

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

With no annotations, the description carries the full behavioral burden, yet it only implies a removal. It doesn't state whether the operation is idempotent, whether it errors if the tag isn't attached, whether it requires any permissions, or whether the deletion is recoverable.

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 action is front-loaded in the first sentence, followed by a compact Args block. It is appropriately short, though the docstring-style parameter listing is more boilerplate than earned prose.

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

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

For a mutating delete tool with zero annotations, the definition is thin. The output schema covers return values, but nothing is said about failure modes, permissions, or side effects, which an agent needs before invoking a destructive operation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does identify both parameters. However, the added value is thin: 'The UUID of the contact' and 'The UUID of the tag to detach' mostly restate the parameter names, adding only the UUID format hint.

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

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

The description names a specific verb and resource ('Detach a tag from a contact'), which is unambiguous and implicitly distinguishes it from the sibling add_contact_tag. It does not, however, explicitly reference any sibling or scope boundary.

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

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

There is no when-to-use guidance, no prerequisites (e.g. tag must already be attached), and no mention of the add_contact_tag alternative for the inverse operation. The agent must infer the usage entirely from the verb.

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 disclose behavioral traits, but it only restates the action and argument. It does not mention idempotency, error behavior, cascading effects, or permission requirements, which are critical for a delete 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?

The description is extremely concise: a two-sentence action statement followed by a clear Args block. It is front-loaded and contains no unnecessary words, making it easy to scan.

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

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

For a simple one-parameter delete tool, the description covers the core action and argument. However, it lacks usage guidance and behavioral details that would help an agent use it correctly, such as whether the flow must exist or if deletion is permanent. The presence of an output schema does not compensate for these gaps.

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

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

The description adds that flow_id is 'The UUID of the flow to delete', specifying the format as UUID, which is a slight improvement over the schema's bare 'string' type. However, it largely restates the parameter's purpose without additional constraints or 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 'Delete a flow' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_flow, update_flow, and get_flow. It precisely states the tool's function.

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 about when to use this tool versus alternatives or about preconditions. It does not mention whether the flow must exist or that deletion is irreversible, leaving the invocation context unclear.

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 must carry the full burden of behavioral disclosure. It only states the action and does not mention side effects, permissions, error behavior, or return format, leaving significant gaps for a tool that could potentially fail or behave unexpectedly.

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 highly concise, consisting of a single sentence and an Args block with one parameter. Every word serves a purpose, and the structure is clean and front-loaded with the primary 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 tool's simplicity (one parameter, output schema present), the description covers the essential purpose and parameter semantics. It does not need to explain return values due to the output schema, but lacks usage context and alternative tool mentions that would make it 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?

The schema has no parameter descriptions (0% coverage), so the description compensates by explaining activeflow_id as 'The UUID of the active flow.' This adds useful semantic information beyond the schema's plain string type, though it could be even more detailed.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Get details of a running active flow.' This distinguishes it from related tools like get_flow and list_activeflows by focusing on 'active' flows, though it doesn't explicitly name alternatives.

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

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

No guidance is given on when to use this tool versus alternatives such as get_flow or list_activeflows. The description lacks any contextual direction for tool selection, making it inadequate for an agent deciding between sibling tools.

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

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

With no annotations, the description carries full behavioral disclosure burden. It states only 'Get details' but does not mention side-effect-free behavior, error conditions, or required permissions. The ambiguity of 'details' adds no behavioral context.

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

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

The description is extremely concise, with a clear front-loaded verb and a structured Args block. Every word earns its place, with no filler or redundancy.

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

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

The output schema exists, so return values are covered. However, the description lacks usage context (e.g., when to use vs alternatives) and does not elaborate on 'details', leaving gaps that are more than expected for a simple get 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 schema provides only 'type: string' with no description. The Args section clarifies agent_id is 'The UUID of the agent', adding critical format and meaning beyond the schema. This compensates for the 0% schema coverage.

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

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

The description 'Get details of a specific agent' uses a specific verb ('Get') and resource ('agent'), clearly distinguishing it from sibling tools like list_agents. It leaves no ambiguity about the tool's core function.

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

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

No guidance is given on when to use this tool versus alternatives. There is no mention of using list_agents to find agent IDs or any exclusions, leaving the agent without clear 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?

No annotations are provided, so the description carries the full burden. It only says 'Get details,' which is the operation itself, with no mention of side effects, error handling, permissions, or response behavior. Minimal transparency 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?

Extremely concise and front-loaded: one sentence for purpose, one line for the parameter. No wasted words, and the structure is clear.

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

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

For a simple one-parameter retrieval tool with an output schema, the description is mostly adequate. However, it lacks any context about missing IDs, permissions, or potential errors, which would be helpful for an agent to handle edge cases. It is minimally viable but not complete.

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

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

The description adds meaningful context for ai_id by specifying it is 'The UUID of the AI agent,' which is more informative than the schema's generic string type. With only one parameter and 0% schema coverage, this sufficiently clarifies the parameter's purpose.

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 that this tool retrieves details for a specific AI voice agent, using the verb 'Get' and identifying the resource. It is unambiguous, though it doesn't explicitly differentiate between sibling tools like get_agent or list_ais.

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

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

Usage context is implied: use this when you need details for one AI voice agent by its UUID. No explicit when-to-use, alternatives, or exclusions are provided, which is acceptable for a simple getter but leaves some 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 present, so the description carries the full burden of behavioral disclosure. It merely states 'get details', which is implicit in the tool name, and does not disclose behavior on missing records, authorization requirements, or any side effects beyond the read-only nature of 'get'.

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

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

The description is concise and front-loaded: a clear one-sentence purpose followed by a single parameter definition. Every word contributes to understanding the tool, 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?

A simple get tool with an output schema, so return values are covered. Yet the description lacks usage context (when to use vs list_billings) and error/edge-case behavior. It is minimally viable but leaves gaps for an agent.

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

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

The schema only defines billing_id as a string with no description, so the description's addition of 'The UUID of the billing record' adds semantic meaning. However, this is minimal and does not explain why the parameter is needed or how to obtain 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 uses the verb 'Get' with a specific resource ('details of a specific billing record'), distinguishing it from the sibling tool 'list_billings'. This clearly defines what the tool does.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_billings. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.

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

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

With no annotations, the description carries the full burden. It explicitly lists the return fields (status, source, destination, direction, recording IDs, timestamps, current action), giving the agent insight into what to expect. It does not mention error behavior or permissions, but for a read-like 'get' tool, this is sufficient and adds value beyond the bare 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 three sentences, front-loaded with the purpose, and includes an Args section for the parameter. Every sentence earns its place without redundant text. It is well-structured and easily scannable.

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

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

Given the tool's simplicity (1 parameter) and the presence of an output schema, the description is adequate. It states the purpose, lists return fields (even though output schema could handle that), and explains the parameter. It does not over-explain, and it covers the essential aspects for a 'get' operation.

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

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

The schema has only call_id with no description, so the schema coverage is 0%. The description compensates by explaining 'call_id: The UUID of the call to retrieve,' adding semantic detail that the schema alone does not provide. This goes beyond simply restating the parameter name.

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

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

The description clearly states the tool's function: 'Get detailed information about a specific call.' This distinguishes it from list_calls (which lists calls) and other retrieval tools like get_conversation or get_flow by focusing on a single call and its specific attributes.

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 a specific call but does not explicitly state when to use this tool over alternatives. No exclusions or alternatives are mentioned. The context is clear enough, but it lacks direct guidance like 'use this instead of list_calls when you need call details.'

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

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

Annotations are absent, so the description must disclose behavioral traits. It only says 'Get details' and provides no information about read-only behavior, error handling, permissions, or response format. For a mutation-ambiguous tool this would be a serious gap; for a 'get' tool it is still thin.

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, with a clear first line and a simple parameter listing. No redundant text or fluff, and it is immediately readable.

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 output schema exists, so the description need not explain return values. However, it provides no context about error conditions, suggested prerequisites, or differences from related get_* tools. For a simple one-parameter getter, this is adequate but leaves room for more helpful 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 description explicitly identifies campaign_id as a UUID, adding semantic meaning beyond the schema's generic string type. This helps the agent format the parameter correctly. Despite the schema's 0% description coverage, the description compensates for the single parameter.

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

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

The description clearly states 'Get details of a specific campaign' with a specific verb and resource. It distinguishes itself from list_campaigns by targeting a single campaign, and from create/update/delete by being a read operation.

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

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

Usage is implied from the name and the campaign_id argument, but there is no explicit guidance on when to use this tool versus alternatives like list_campaigns or get_* tools. No exclusions or conditional use cases are mentioned.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Get details' without addressing error behavior (e.g., not found), permissions, or confirming it is a read-only operation. This leaves the agent with insufficient safety or edge-case 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 concise and well-structured with an Args block. It front-loads the main action and adds no redundant information.

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

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

The tool has one parameter, an output schema, and a straightforward purpose, so the description covers the core function. However, it omits guidance on error handling or how to obtain the conference ID (e.g., via list_conferences), leaving an agent to infer important workflow 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 schema only describes conference_id as a string, but the description's Args block adds meaningful semantics by specifying it is a UUID. This helps the agent understand the expected format and 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 uses the specific verb 'Get' and clearly identifies the resource as 'details of a specific conference.' This distinguishes it from sibling tools like list_conferences (which retrieves multiple) and other get_* tools.

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

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

The description implies that this tool is for retrieving a single conference by ID, but it does not explicitly state when to use it versus list_conferences or provide any exclusion criteria. The context is clear but not fully articulated.

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

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

The verb 'Get' implies a read-only operation, which is a basic behavioral trait, but the description does not disclose error behavior, required permissions, or the exact content of 'details'. With no annotations, the description carries full burden and could be more explicit about side effects and edge cases.

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

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

The description is extremely concise: one sentence for the purpose and a compact Args section for the single parameter. Every word earns its place, and it is front-loaded with the main 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?

The tool is simple and has an output schema, so return values are covered, but the description lacks usage context (e.g., when to use vs list_contacts) and doesn't mention error handling. It is minimally adequate but leaves gaps.

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

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

The schema only provides the property name and type, while the description adds that contact_id is 'The UUID of the contact', clarifying the format and purpose. This goes beyond the schema's minimal 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 uses a specific verb 'Get' and resource 'contact', clarifying it retrieves details for a specific contact by UUID. This distinguishes it from list_contacts, delete_contact, and other contact tools.

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

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

There is no guidance on when to use this tool versus alternatives like list_contacts or get_contact variants. No explicit context, prerequisites, or exclusions are provided.

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

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

Annotations are not provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get details', with no mention of side effects, error behavior (e.g., 404 on not found), authentication, or rate limits. For a getter, the lack of any behavioral context is a significant gap.

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

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

The description is concise and front-loaded with the primary purpose. It includes a simple Args section with the parameter. Every word earns its place, but it may be too terse, lacking any elaboration for the parameter. Still, it is well-structured and not bloated.

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 is a simple getter with an output schema (not shown but present), the description is minimally sufficient for invocation. However, it does not provide guidance on when to use it versus list_conversations, nor any behavioral notes. It is adequate for a basic tool but not fully complete in 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 schema provides only a string type for conversation_id, and the description adds that it is a 'UUID of the conversation', giving some meaning beyond the schema. However, it doesn't explain the format beyond UUID or how to obtain the ID, nor any constraints. With 0% schema coverage, the description compensates minimally.

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 details of a specific conversation', which is a specific verb ('Get details') and resource ('specific conversation'). It distinguishes itself from sibling tools like list_conversations (listing all) and get_message (messages vs conversations).

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

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

Usage is implied: when you have a conversation_id and need its details. However, there is no explicit guidance about when to use this over alternatives, nor any exclusions or prerequisites. The parameter name makes the use case obvious, but the description offers no direct comparison.

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 explicitly states that the tool returns account details including name, billing info, and webhook configuration, giving clear behavioral expectations. The 'Get' verb implies a safe read operation, and the description adds context about the return content beyond what a bare name would provide.

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

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

The description is two concise sentences with no filler. The first sentence states the core purpose, and the second adds useful detail about return fields. 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 parameterless getter, the description adequately covers the main purpose and return content. Output schema exists, so detailed return structure is not required. It lacks explicit mention of error conditions or authentication, but these are reasonable gaps given the tool's simplicity.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. As per rubric, 0 params yields a baseline of 4; the description need not explain any parameters since 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 starts with 'Get your VoIPbin customer account information', which clearly states the verb (get) and resource (customer account). It also enumerates specific returned fields (name, billing info, webhook configuration), making the tool's purpose unambiguous and distinguishing it from sibling tools like get_billing or get_number.

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 customer account details are needed, but it does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives. Given the sibling get_billing, there is no differentiation, so an agent might lack clarity on when to choose this over related tools.

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

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

With no annotations provided, the description must disclose behavioral traits. It only states 'Get details' with no mention of side effects, error behavior (e.g., what happens if the email_id is not found), authentication requirements, or rate limits. While the operation is inherently read-only, this is not explicitly stated.

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

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

The description is extremely concise and front-loaded, with no superfluous wording. It fits the minimal nature of the tool, though it could include an additional sentence about error cases without losing conciseness.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the primary purpose and argument. However, the lack of annotations means the description should also state read-only behavior and potential errors, which it does not, leaving some gaps for a 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?

The schema provides only the type 'string' for email_id, and the description adds 'The UUID of the email,' clarifying the format and meaning. This partially compensates for the 0% schema description coverage, but it lacks examples, constraints, or referring context (e.g., how to obtain a list of email IDs).

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 and resource ('Get details of a specific email'), clearly distinguishing it from sibling tools like list_emails (which lists multiple) and send_email (which creates an outgoing email). The word 'specific' plus the email_id parameter makes the singular retrieval purpose 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?

Usage is implied rather than stated: the description suggests this tool is for when you need details of one specific email by ID. However, it does not explicitly contrast with list_emails or mention any exclusions, such as not being able to fetch emails from threads or requiring certain permissions.

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 present, so the description must carry the full burden. It only says 'get details' without disclosing behavior such as error handling, not-found responses, permissions, or output format. The description is minimal and does not reveal any non-obvious traits.

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

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

The description is two sentences and front-loaded with the main purpose. The Args section is concise and adds the UUID detail without redundancy. Every sentence earns its place, making it highly efficient.

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

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

The tool is simple with one parameter and an output schema present, so return values need not be explained. However, the lack of usage guidelines and behavioral transparency creates gaps, making the description only marginally adequate for full 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 schema provides only a type and title for extension_id with 0% description coverage. The description adds that it is 'The UUID of the extension,' giving semantic meaning beyond the schema. This compensates for the gap, though it doesn't elaborate on accepted UUID formats.

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 details of a specific extension,' identifying the action (get) and resource (extension). The word 'specific' distinguishes it from the sibling tool list_extensions, making its purpose 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?

No guidance is provided on when to use this tool versus alternatives like list_extensions. There is no mention of context, prerequisites, or scenarios where this tool is appropriate, leaving the agent without decision support.

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?

There are no annotations, so the description carries the full burden. It does add a useful behavioral detail—'including its full action sequence'—which indicates the return content. However, it does not disclose error handling, authentication requirements, or any potential side effects, even though reads are typically safe.

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

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

The description is extremely concise, consisting of a short purpose statement and a single parameter definition. Every sentence adds value, and the Args formatting is clean and easy to parse.

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

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

For a simple get-by-ID tool with an output schema, the description is mostly complete. It tells the user what the tool does and what it returns. However, it lacks guidance on when to choose this over related getters or how to handle not-found cases, leaving a minor gap in 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 description includes an Args section clarifying that flow_id is 'The UUID of the flow', which adds semantic meaning beyond the schema's generic 'string' type. With only one parameter, this provides sufficient context, though it could be more detailed about the expected format.

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

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

The description 'Get a flow by its ID, including its full action sequence' clearly states the specific action (get), the resource (flow), and the key differentiator (by ID, full action sequence). It distinguishes itself from sibling tools like list_flows and get_activeflow.

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. It does not mention that list_flows should be used to enumerate flows, or that get_activeflow is for active flows. The context is implied by the word 'get', but no explicit when/why is provided.

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

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

With no annotations provided, the description carries the full transparency burden. It only states the basic purpose and the message_id argument, without disclosing error behavior, return format, authentication needs, or any side effects. This is a minimal disclosure for a read 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?

The description is extremely concise: one sentence for purpose and one for the argument. There is no redundant or irrelevant content, and the structure is clear for a single-parameter getter.

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 getter with an output schema and a single parameter, the description is functionally sufficient. However, it lacks any mention of related tools (e.g., list_messages) or the context in which this tool should be invoked, so it is adequate but not complete.

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

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

The description adds that message_id is 'The UUID of the message', which provides semantic meaning beyond the schema's 'Message Id' title. However, it does not provide format validation, examples, or clarify if the UUID must be an existing message, leaving marginal 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 'Get details of a specific message' provides a specific verb and resource, distinguishing it from list_messages and send_message. It clearly states the action of retrieving one message, though it does not detail what 'details' entails.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It only implies selection of a single message via 'specific', but does not mention sibling tools like list_messages for enumerating messages, nor any 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?

With no annotations available, the description carries the full burden for behavioral disclosure. It only states 'Get details,' which implies a read operation, but doesn't disclose output format, error behavior, permissions, or any side effects. This is a minimal disclosure.

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

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

The description is extremely concise, consisting of a single sentence and a brief parameter note. Every word earns its place; there is no redundancy 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 simple get-by-ID tool with an output schema, the description is minimally sufficient. It lacks usage context and behavioral details, but the core invocation intent is clear. More context about similar tools or edge cases would improve completeness.

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

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

The schema provides no description for number_id beyond 'string,' but the description adds meaning by stating 'The UUID of the number.' This clarifies the expected value, compensating for the schema's lack of detail.

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 details of a specific phone number' with a specific verb and resource. It distinguishes itself from list_numbers (listing all numbers) and other get_* siblings, though it doesn't explicitly name alternatives.

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

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

No guidance is provided on when to use this tool versus alternatives. It only implies usage when you have a number_id, but there is no explicit context, 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?

No annotations are provided, so the description carries the full burden. It only states the action and parameter without disclosing behavioral details such as read-only nature, error handling, or prerequisites. The tool name implies a read operation, but the description adds no extra 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 highly concise, with a clear purpose statement followed by a single parameter explanation. Every word earns its place, and the structure is front-loaded with the main action.

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

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

For a simple one-parameter get operation, the description is adequate. It provides essential information about the tool's purpose and parameter. Since an output schema exists, return value details are not needed. However, it lacks guidance on related operations or error scenarios, which would improve completeness.

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

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

The description documents queue_id as 'The UUID of the queue', adding semantic meaning beyond the schema's plain string type. With 0% schema description coverage, this compensation is valuable and clarifies the expected format.

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

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

The description clearly states 'Get details of a specific queue', which identifies the action (get) and resource (queue details). It distinguishes from sibling list_queues by specifying 'specific queue' rather than listing all queues.

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 a single queue identified by queue_id but does not explicitly mention when to use this tool over alternatives like list_queues. It lacks explicit exclusions or alternative tool references.

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 clearly discloses the authorization requirement, the likely error (403 PERMISSION_DENIED), and the distinction between platform-level routes and customer access keys. This is exactly the kind of behavioral context an agent needs to avoid failed calls.

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

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

Very concise: three short paragraphs. Front-loaded with purpose, then permission constraints, then parameter detail. No wasted words. Efficient structure.

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 an output schema, so return values needn't be described. The description covers purpose, authorization, error behavior, and the single parameter's format, leaving nothing critical unstated for an agent to call it correctly.

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

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

Schema coverage is 0%—the only parameter, route_id, is undocumented in the schema. The description provides a brief hint: 'The UUID of the route.' This does add meaning by specifying format (UUID), but it's minimal for a parameter heavily exposed to calls. Baseline 3 is appropriate given the schema provides no 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?

Clear verb and resource: 'Get details of a specific route.' This distinguishes it from list_routes by scope (single vs. list), and route_id confirms it retrieves one entity. Sibling differentiation comes from the name and the specificity of the resource, though it doesn't explicitly contrast with list_routes.

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 explicit prerequisite: 'Requires project superadmin permission' and 'A customer access key cannot read them.' This tells the agent exactly when the tool will fail and under what conditions it can be used. Strong guidance on when to use and when not to use.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly implies a read-only operation via 'Get details', but does not state what happens if the tag does not exist, whether authentication is required, or any side effects. For a simple get tool, 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?

The description is exceptionally concise, consisting of two sentences that cover the purpose and the sole parameter. It is front-loaded with the main verb, and the Args section is a standard, clear structure. Every word earns its place with no redundancy.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description is adequate. It does not explain return values, but that is unnecessary with an output schema available. The description could theoretically include usage context, but for a single-resource get, the provided information 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 schema provides only the parameter name and type (string), with no description. The description adds crucial meaning by stating tag_id is 'The UUID of the tag', clarifying both its format and semantic role. This goes beyond what the schema offers, helping the agent understand what value to supply.

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 ('Get') and the resource ('specific tag'), which distinguishes it from sibling tools like list_tags (listing tags) and other get_* tools. The phrase 'specific tag' implies retrieval by unique identifier, setting expectations for a single-resource read operation.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, suitable contexts, or mention that for listing tags one should use list_tags. The intent is implicitly conveyed by the tool's naming convention, but there is no direct advisory.

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 disclosure burden. It states the action ('hang up') but does not reveal side effects such as irreversibility, required permissions, or what happens if the call is already hung up. For a mutating operation, this is a significant gap.

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 succinct with two clear sentences, front-loading the purpose and briefly documenting the parameter. No unnecessary words, and the Args format is clear.

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

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

For a simple single-parameter tool with an output schema, the description is nearly adequate. However, the lack of behavioral details (e.g., error conditions, prerequisites) and absence of annotations reduce completeness. It would benefit from mentioning that the call must be active.

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

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

Since schema description coverage is 0%, the description compensates by explaining that call_id is 'The UUID of the call to hang up.' This adds meaningful context beyond the schema's generic title 'Call Id', although it does not specify where to obtain the UUID.

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 'Hang up an active call' uses a clear verb and object, distinguishing it from sibling tools like get_call or create_call. It 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 implies usage when an active call needs to be terminated, but it does not explicitly mention when not to use it or mention alternatives. It lacks guidance on prerequisites like whether the call must be owned by the user or in a certain state.

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 burden. It discloses pagination behavior (page_token as cursor, default page_size) and clarifies the resource scope. It does not explicitly state read-only behavior, but 'list' implies it. The description adds value beyond the schema by explaining what active flows are.

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 highly concise and well-structured. It front-loads the purpose, provides a clear definition, and lists arguments succinctly. Every sentence earns its place 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 and the presence of an output schema, the description covers the key contextual aspects: what is listed, what constitutes an active flow, and pagination parameters. It lacks explicit usage guidance vs alternatives, but overall the context is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds clear meaning beyond the raw schema type definitions.

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

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

The description clearly states the tool's purpose: 'List all currently running active flows.' It uses a specific verb (list) and resource (active flows), and further clarifies that active flows are flow instances executing on calls, distinguishing it from flow definitions.

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 the tool by defining active flows as 'currently executing on calls,' but it does not explicitly mention alternatives or exclusions. Siblings like list_flows and get_activeflow exist, but no direct comparison or guidance is provided.

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

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

No annotations are provided, so the description carries the burden. It correctly implies a read-only operation and documents pagination semantics (page_token as a cursor from a previous response), but it doesn't disclose rate limits, auth requirements, or ordering/filtering behavior.

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

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

The description is compact, with a two-sentence introduction and a brief Args list. No sentences are wasted; every element serves a purpose.

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

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

The tool is a simple paginated list operation, and the description covers its core purpose, entity definition, and parameter semantics. An output schema exists, so the lack of return-value explanation is acceptable; it's fully 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?

Schema description coverage is 0%, so the description's Args section is essential. It explains page_size as the number of results and page_token as a pagination cursor, adding meaning beyond the schema's type and default fields. This fully compensates for the lack of schema 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 states 'List all agents in your VoIPbin account' with a specific verb and resource, and clarifies agents as users handling interactions. This distinguishes it from sibling list tools like list_contacts or list_numbers.

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 agents are but gives no explicit guidance on when to use this tool versus alternatives such as get_agent for a single agent. Usage is implied by the name and primary statement, but lacks clear exclusions or named alternatives.

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

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

Since no annotations are provided, the description carries the behavioral disclosure burden. It does mention pagination behavior (page_size, page_token), indicating that results are paged and that page_token comes from a previous response. However, it does not disclose ordering, filtering, or whether deleted or inactive agents are included.

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

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

The description is very concise: a single statement of purpose followed by a compact parameter list. Every sentence earns its place and the main 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 list tool with two optional pagination parameters and an output schema, the description covers the essentials. It explains pagination and the purpose, though it could be more complete with a note about iterating pages or clarifying the difference from 'list_agents'.

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

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

The schema only provides parameter names and defaults (0% coverage), so the description must compensate. It clearly explains page_size ('Number of results per page') and page_token ('Pagination cursor from a previous response'), adding meaningful 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 action ('List all AI voice agents') with a specific scope ('in your VoIPbin account'). It is specific but does not differentiate from the sibling tool 'list_agents', which could be confusing.

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 regarding when to use this tool versus alternatives like 'list_agents'. There are no exclusions, prerequisites, or context about when this listing is appropriate.

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 burden. It discloses the basic listing behavior and implicitly suggests pagination through the presence of 'page_size' and 'page_token' args, but it does not describe the output format, sorting, authentication requirements, or any potential side effects. This is minimal but acceptable for a simple read-style list tool.

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

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

The description is concise: a one-sentence purpose followed by a clean parameter list. It is front-loaded with the core operation, contains no fluff, and every sentence serves a purpose.

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

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

For a simple paginated list tool, the description covers the essential purpose and parameter semantics. An output schema is available, so return-value details are presumably covered there. However, it lacks usage context and any mention of filters or limits, which would make it more complete for an agent selecting among many sibling tools.

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 0% schema description coverage, the description's 'Args' section compensates by explaining both parameters: 'Number of results per page (default 10)' and 'Pagination cursor from a previous response'. This adds meaningful context beyond the bare schema types and defaults, though it could be more detailed (e.g., max page size, token format).

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

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

The description clearly states 'List all billing records in your VoIPbin account', which uses a specific verb and resource, and distinguishes this tool from siblings like 'get_billing' and other 'list_' tools. The scope is 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 provides no guidance on when to use this tool versus alternatives such as 'get_billing' or other list tools. It does not mention any prerequisites, excluded scenarios, or suggest when pagination is needed, leaving usage decisions entirely to 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the result is paginated and lists specific fields returned (status, source/destination numbers, direction, timestamps). However, it does not mention authentication requirements, rate limits, or ordering semantics, which are relevant for a list operation. This is 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?

The description is concise and well-structured: two sentences for purpose and return fields, followed by an Args list. It front-loads the primary purpose and keeps every sentence informative. There is no fluff 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?

The description covers the essential aspects for a simple paginated list tool: what it lists, the return fields, and the parameters. Since an output schema exists, the return format is documented elsewhere. The only minor gap is the absence of any mention of authentication or the relationship to other call-related tools, but overall it is sufficiently complete.

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

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

The schema has zero description coverage for its parameters, but the description provides clear, concise explanations in the Args section. It explains that page_size sets the number of results per page with a default of 10, and page_token acts as a pagination cursor from a previous response. This adds meaningful semantic context beyond the schema's bare type and default values.

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: 'List all calls in your VoIPbin account.' This uses a specific verb ('List') and resource ('calls'), and the distinction from siblings like get_call, create_call, and hangup_call is clear. The clarification that it returns a paginated list further refines the purpose.

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

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

The description clearly implies when to use the tool (to list all calls), but it does not explicitly mention when not to use it or suggest alternatives like get_call for a single call. There is no exclusionary guidance, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it describe pagination behavior (beyond parameter names), sorting, or whether archived/inactive campaigns are included. The description is minimal and relies on the implied safety of a 'list' 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?

The description is concise and front-loaded: the first sentence states the purpose, followed by a brief context sentence and a straightforward Args list. Every sentence earns its place 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?

The description covers the core purpose and parameters, and an output schema exists so return values are presumably documented. However, it lacks explicit details about pagination flow (e.g., how to retrieve subsequent pages), filtering behavior, or any edge cases like empty results or permission requirements. For a simple list tool this is adequate but not complete.

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

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

The description includes an Args section that explains both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds meaning beyond the bare schema, which only provides types and defaults, and is especially valuable given 0% schema description coverage.

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

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

The description clearly states 'List all outbound campaigns' with a specific verb and resource, and adds context about what campaigns are (automate outbound calling, SMS, or email). This distinguishes it from sibling tools like list_calls or list_flows.

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 campaigns but provides no explicit guidance on when to choose this over related tools (e.g., get_campaign for a single campaign). No alternatives or exclusions are mentioned, leaving the choice based on the tool name alone.

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

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

With no annotations, the description carries the transparency burden. It discloses pagination through the page_size and page_token parameters and indicates all conferences are listed, but it does not detail return format, ordering, or potential pagination limits. This is adequate for a simple list operation but not deeply 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: a leading purpose sentence followed by a clear args list. Every sentence adds value, and there is no redundant or filler content.

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

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

For a simple list tool with an output schema, the description covers the essential purpose and pagination parameters. It lacks explicit usage alternatives but is otherwise sufficient given the tool's low complexity and available output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It explains page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response,' adding meaningful context beyond the raw schema types and 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 'List all conferences in your VoIPbin account,' using a specific verb and resource. This distinguishes it from sibling tools like get_conference, create_conference, and delete_conference by focusing on the listing action.

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

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

The description implies usage as a listing tool but does not explicitly mention when to use it over alternatives like get_conference. There are no exclusions or alternative recommendations, so guidance is only implied by the tool's name and purpose.

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 disclose behavior. It states the tool lists all contacts and explains the pagination parameters, implying a read-only operation. However, it doesn't explicitly confirm non-destructiveness, mention ordering, or clarify that results are returned in pages despite saying 'all'. Adding a note like 'This is a read-only operation' 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?

The description is two sentences plus a focused Args block; the main purpose is stated first, and parameter documentation is structured and free of redundancy. 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?

The tool is simple with two optional params and an output schema, and the description covers the pagination semantics adequately. It might benefit from mentioning that the result is a paginated list of contacts and how to iterate, but given the output schema exists and the description is clear about args, it's reasonably complete.

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

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

Schema descriptions are entirely absent (0% coverage), so the description's Args section provides essential meaning: page_size defines page size with a default, and page_token is explained as a pagination cursor from a previous response. This compensates well for the schema gap, though it could elaborate on how page_token is obtained (e.g., from the response).

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 ('List') with a clear resource ('contacts') and scope ('in your VoIPbin account'), distinguishing it from sibling contact tools like get_contact or delete_contact.

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 choose list_contacts over alternatives; it doesn't reference get_contact for single-contact lookup or mention pagination as a reason to use this tool. The description simply states what it does without 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 present, so the description carries the full burden. It discloses pagination behavior via the args but does not explicitly state read-only nature, error handling, ordering, or other edge-case behaviors. The conceptual grouping note adds useful context but is 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 concise, front-loaded with the primary action, and includes only essential information: a clear purpose statement, a brief conceptual note, and parameter explanations. 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 low complexity (simple paginated list with two parameters) and the existence of an output schema, the description adequately covers purpose and parameters without needing to explain return values. It is sufficient for an agent to select and invoke the tool correctly.

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

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

The Args section explains both page_size and page_token with meaningful descriptions ('Number of results per page' and 'Pagination cursor from a previous response'), fully compensating for the 0% schema description coverage.

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

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

The description explicitly states 'List all conversations in your VoIPbin account' using a specific verb and resource, and further clarifies what conversations group. This clearly differentiates it from sibling tools like list_calls and list_contacts.

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 list conversations) but does not explicitly compare it to alternatives like get_conversation or mention exclusions. It is straightforward and unambiguous, but lacks explicit alternative 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?

With no annotations, the description carries the burden of behavioral disclosure. It does mention pagination via the args (page_size, page_token), which hints at the response being paged. However, it does not explicitly state whether the operation is read-only, how 'all emails' interacts with pagination, or any other behavioral characteristics like ordering or limits.

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

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

The description is brief and front-loaded with the purpose, followed by a clear Args section. Every sentence/line earns its place with no fluff or repetition of schema fields beyond what is necessary for clarity.

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

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

Given the simplicity of the tool (2 optional params, output schema exists) and adequate parameter documentation, the description covers the essentials. However, it lacks usage guidelines and any broader context about when to choose this over sibling list tools, which keeps it from being 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?

Though schema description coverage is 0%, the description fully compensates by explaining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response.' This adds meaningful semantics beyond the schema's titles and 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 'List all emails in your VoIPbin account.' with a specific verb (list) and resource (emails). It is distinct from sibling tools like list_messages or get_email by resource type, though it does not explicitly differentiate itself.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_messages or get_email. The description simply defines the action without context or exclusions, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses pagination behavior through the Args section (page_size, page_token) and states the scope ('all extensions in your VoIPbin account'). It does not discuss auth, rate limits, or potential side effects, but for a read-only list 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?

The description is brief and front-loaded with the purpose, followed by a helpful clarification of what an extension is, and then a clean Args block. No wasted words or redundant information.

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

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

Given a simple list tool with an output schema present, the description covers purpose, parameter semantics, and pagination. It might optionally mention ordering or max page size, but overall it is complete 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 provides only types and defaults, with 0% description coverage. The description compensates by explaining page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response', adding meaning beyond the structured 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 states a specific verb ('List') and resource ('extensions') with the scope 'in your VoIPbin account'. It additionally clarifies what extensions are ('internal phone lines assigned to agents'), which effectively distinguishes this tool from sibling tools like list_numbers or list_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?

The description implies usage: use this to list all extensions in the account, and the extension definition hints at the concept. However, it does not explicitly state when to prefer this over other list tools or how it relates to get_extension. No exclusions or alternative tools are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It clearly states the tool lists flows, which implies a read-only operation, and explains what flows are. However, it does not disclose any additional behavioral traits such as pagination semantics (how to detect the last page), ordering, or whether any filters or side effects exist. The description adds domain context but not beyond what is obvious from the tool name.

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

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

The description is concise and well-structured: it starts with the primary purpose, adds a brief explanatory sentence about flows, and ends with parameter documentation. There is no redundant content; every section serves a clear purpose and the main 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 list tool with two optional parameters and an output schema, the description is complete. It names the resource, explains the params, and does not need to describe return values because the output schema covers them. No critical information appears to be missing for correct invocation.

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

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

The input schema has 0% description coverage, but the description compensates by explicitly defining both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response'. This adds meaningful semantics beyond the literal schema types and 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 first sentence, 'List all flows in your VoIPbin account', clearly states the action (list), the resource (flows), and the scope (VoIPbin account). This distinguishes it from sibling tools like get_flow (retrieve a single flow) or create_flow/update_flow/delete_flow (mutations), and from list_activeflows which likely lists only active flows.

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: to list all flows in the account. However, it does not explicitly mention when to use this tool over alternatives (e.g., get_flow for a specific flow, or list_activeflows for active flows), nor does it provide any exclusions or prerequisites. This is adequate but lacks proactive 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?

With no annotations, the description carries the full burden. It discloses pagination behavior via page_size and page_token, and it's read-only by nature. However, it does not mention ordering, filtering, or other potential edge cases, leaving some behavioral details unspecified.

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

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

The description is concise and front-loaded with the purpose. The args section is minimal, with no filler or redundancy. Every sentence serves a clear function.

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 operation with an output schema, the description is largely sufficient. It covers pagination parameters and gives a clear scope. It could add more context about result ordering or typical use cases, but the given information is adequate for a low-complexity 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 has zero descriptions, so the description fully compensates by explaining page_size as 'Number of results per page' and page_token as 'Pagination cursor from a previous response.' This adds meaning beyond the bare schema fields.

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 action and resource: 'List all SMS messages in your VoIPbin account.' This distinguishes it from sibling tools like list_emails or list_numbers, which target different resource types.

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

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

The description implies usage by stating it lists SMS messages, but it does not explicitly explain when to choose it over alternatives like get_message or list_conversations. It provides no exclusions or comparison context, though the action is straightforward.

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 carry the burden of behavioral disclosure. It mentions pagination via page_size and page_token, which is useful, and implies read-only behavior with 'List'. However, it does not discuss rate limits, sorting, or any side effects beyond what is obvious.

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, leading with the main purpose and then clearly listing parameters. Every sentence adds value, with no fluff or repetition.

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

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

For a simple list endpoint with an output schema present, the description covers the action and both parameters adequately. It lacks explicit mention of the return structure, but that is provided by the output schema. It could mention potential use cases or limitations, but overall it is sufficient for the tool's simplicity.

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

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

The schema has no descriptions for its parameters, so the description compensates by explaining page_size as 'Number of results per page' and page_token as a 'Pagination cursor from a previous response.' This adds meaningful semantic context beyond the raw 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 and resource ('List all phone numbers'), clearly distinguishing it from sibling tools like get_number, list_contacts, etc. It also scopes to the user's VoIPbin account, making the intent unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives such as get_number for retrieving a single number. The description implies usage for browsing the full list, but does not explicitly state exclusions or alternatives.

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

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

With no annotations, the description bears the full burden of behavioral disclosure. It adds useful pagination context (page_size default 10, page_token as a cursor), but does not explicitly state that the operation is read-only or mention any permissions, rate limits, or side effects. 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?

The description is concise, with the purpose stated first, a brief explanatory sentence for context, and a clean Args section. Every sentence contributes value without redundancy or unnecessary 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?

Given the low complexity of a simple list operation with an output schema, the description fully covers the core functionality, pagination parameters, and background on what a queue is. There is no critical missing information for an agent to select and 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?

The input schema has no parameter descriptions, but the description compensates fully via an Args section. It explains page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response,' providing complete semantic meaning for both parameters.

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

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

The description clearly states 'List all call queues in your VoIPbin account,' specifying the exact resource and scope. It also explains what queues are, distinguishing this from sibling tools like get_queue by emphasizing 'all call queues.'

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 usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives like get_queue. It lacks exclusionary or comparative statements to help an agent choose between similar list_* tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the permission requirement, platform-level resource scope, and 403 error behavior. It does not explicitly state read-only semantics or describe pagination beyond the parameter definitions, but covers the key access constraint well.

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

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

The description is front-loaded with purpose and permission requirements, then lists arguments compactly. It is slightly repetitive, repeating the superadmin permission requirement across two sentences, but otherwise every sentence earns its place.

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

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

Given the simple two-parameter list operation, the presence of an output schema, and no annotations, the description covers what an agent needs: purpose, required permission, failure behavior, and both parameters. Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It defines both parameters: page_size as results per page (default 10) and page_token as a pagination cursor from a previous response. This adds meaningful semantics beyond the bare schema titles and 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 states a clear verb and resource: 'List provider routing rules.' It is distinguishable from most siblings, but does not explicitly name or contrast with the closest sibling, get_route, so it falls just short of full sibling differentiation.

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

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

It gives important usage context: requires project superadmin permission and will return 403 PERMISSION_DENIED without it. This is a clear when-to-use condition and an exclusion, but it names no alternative tool for users who lack the required key.

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 burden of behavioral disclosure. It discloses the read-only nature ('List all tags') and explains pagination parameters, but lacks details such as authentication requirements, potential rate limits, ordering, or edge cases. The description adds some context but not rich behavioral insight.

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

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

The description is concise and well-structured, with a clear opening sentence, a brief domain note, and an 'Args' section. It avoids unnecessary verbosity and every sentence adds value, though a slightly cleaner separation of purpose and parameters could improve 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 the simple nature of this list tool with only two optional parameters and an existing output schema, the description is largely complete. It covers pagination and the scope of results, and since an output schema exists, it need not describe return values. It lacks only minor details like sorting or filtering options, but these are not essential for basic 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 0%, so the description must compensate. It explicitly explains both parameters: page_size as 'Number of results per page (default 10)' and page_token as 'Pagination cursor from a previous response'. This adds meaningful semantics beyond the bare schema types and titles.

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 all tags in your VoIPbin account' with a specific verb and resource, distinguishing it from the sibling 'get_tag' which retrieves a single tag. The additional context that tags can be applied to contacts, calls, and resources further clarifies the tool's domain.

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

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

The description implies usage for listing all tags, but it does not explicitly state when to use this tool versus alternatives like 'get_tag'. There are no exclusions or prerequisite conditions mentioned, leaving usage guidance purely implied.

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

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

With no annotations provided, the description carries the full behavioral burden and largely meets it: it discloses billing for call/STT/TTS, the exact return shape on failure (no_answer, call_failed with hangup_reason, session_limit, events_unavailable), auto-termination conditions, and the hard 3600s cap. It stops short of stating required permissions or what happens to the callee on failure, so it is strong 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?

Front-loaded with purpose and cost, then workflow, then return contract, then args — a sensible order. It is long, and the paragraph explaining the one-hour platform cap partly restates the max_duration_seconds ceiling, which is the one place a sentence could be trimmed.

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

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

For a 7-parameter, side-effectful tool with no annotations, this covers purpose, cost, lifecycle, concurrency limits, failure reasons and parameter formats, and an output schema exists to carry return structure. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the Args block does all the work: it documents all 7 parameters with E.164 formatting for source_number, the tel/sip/extension enum values for destination_type, BCP-47 language semantics shared by recognition and synthesis, default-voice behavior for voice_id, and numeric ranges/defaults for both timeout fields.

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

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

States a specific verb+resource ('Start a live phone conversation: place a call') and immediately scopes it with 'that YOU will speak on and listen to', which separates it from dispatch-style siblings like create_call and from the one-way phone_say/phone_listen tools. An agent can identify the tool's role without opening the schema.

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

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

Gives an explicit conditional workflow: if status is 'answered', converse via phone_say_and_listen (one turn per call) and terminate with phone_hangup. It also states operational limits that affect when this tool is viable — 5-minute idle auto-hangup, 4 concurrent calls max, one-hour platform cap.

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 and does meaningful work: it discloses the side effects (speech stops, call ends, billing stops) and the concurrency behavior (safe even while another phone tool waits on the same call). It omits permission/auth requirements, but the core behavioral profile is covered.

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

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

Front-loaded with the action and its consequences, followed by a short usage note and an Args section. Tight and well-ordered, though the docstring-style Args block is slightly formulaic for a single self-evident parameter.

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?

Output schema exists, so return values need not be described. For a one-parameter tool, the description covers purpose, effects, and parameter provenance adequately; the remaining gap is the unaddressed overlap with the hangup_call sibling.

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

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

Schema coverage is 0%, so the description must compensate, and it does by explaining the provenance of call_id ('from phone_call_start or phone_wait_incoming'). That tells the agent where to obtain the required value, which the bare string schema does not.

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

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

States a specific verb and resource (end/hang up a live call) and adds the concrete consequences of stopping speech and ending billing. It is clear what the tool does, but it never distinguishes itself from the sibling hangup_call, leaving an ambiguity an agent must resolve elsewhere.

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 usable timing context ('Works at any time, including while another phone tool is waiting on the same call'), which tells the agent when this call is safe. It stops short of stating when to prefer this over alternatives such as hangup_call or how it relates to phone_call_start's lifecycle.

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 behavioral burden and does so richly: billing applies to answered calls (call, STT, TTS), the existing call flow is REPLACED and its id persisted on the replacement, only one MCP process may wait per number at a time, and deletion of the replacement flow on release. This is exactly the non-obvious operational context an agent needs.

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