TextKit

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds concrete real-world context: activation starts runs from tracked events, and with a live number it texts real people. That is valuable behavioral disclosure beyond the annotations, though it does not address permissions or error 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?

Two short sentences are front-loaded with the action and consequence. Every phrase earns its place: the first states what it does, and the second flags the real-world side effect. There is no filler.

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

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

For a one-parameter activation tool with rich annotations, the description covers the action and its main consequence. It could say more about the return value or error conditions, since there is no output schema, but the essential behavioral context is present. This is nearly 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 coverage is 100% and the only parameter is 'id' with its own description. The tool description does not add any meaning about the id beyond what the schema already provides. Baseline 3 is appropriate when the schema fully documents 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 gives a specific verb and resource: 'Turn an automation on.' It also clarifies the immediate effect: tracked events start runs. It does not explicitly distinguish itself from sibling tools such as pause_automation or create_automation, so it falls short of a 5.

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

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

The description implies when to use it by stating the effect of activation, but it does not explicitly compare alternatives like pause_automation or update_automation. It also gives no prerequisites or conditions for when not to use it. This is implied usage rather than explicit guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuine context beyond them — the 1,000-item batch cap and the requirement that phone numbers resolve to existing contacts — but says nothing about duplicate handling or partial-failure behavior, which matters for a non-idempotent mutation.

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

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

One sentence, front-loaded with the action and resource, with the constraints packed into a parenthetical. No filler and nothing that could be trimmed without losing meaning.

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

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

With no output schema, the description should ideally say what a successful add returns or what happens to already-present contacts. Annotations carry the safety profile and the schema carries the field types, so what remains missing is duplicate/partial-success semantics — a real gap for a bulk mutation but not a crippling one.

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

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

Schema description coverage is only 33% (only `id` is documented), so the description must compensate, and it does: it establishes that contact_ids and phone_numbers are both optional, mutually combinable selectors, and that the batch is capped at 1,000. It leaves ambiguity about whether the 1,000 limit applies per array or combined, and never documents `id` itself.

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

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

States a specific verb and resource ("Add contacts to a list") and immediately names the two input channels, so an agent can distinguish it from create_list, update_list, and remove_from_list by name alone. It stops short of explicitly contrasting with the closest sibling (remove_from_list).

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

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

Gives a real prerequisite ("numbers must already be contacts") that determines whether the call will succeed, plus the fact that contact_ids and phone_numbers are combinable. It does not state what to do when a contact is already on the list or point at alternatives, so it falls short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the side-effect scope: messages and usage travel with the number, which the schema does not express. It still omits what happens to a prior customer's attribution and whether the operation can fail partway.

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

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

A single compact sentence with no filler, and the primary action is front-loaded ahead of the unassign case. The leading 'Platforms:' qualifier is slightly cryptic and spends words without clear payoff.

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

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

For a two-parameter mutation with full schema coverage, no output schema, and annotations that already flag destructiveness and non-idempotency, the description covers both operating modes. Only the edge-case behavior around reassignment of an already-assigned number is left unstated.

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

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

Schema description coverage is 100% and both parameters are documented, including 'null to unassign'. The description only restates the null-unassign behavior already present in the schema and adds nothing about the E.164 format or ownership constraints, so the schema carries the load and baseline 3 applies.

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

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

States a specific verb and resource: attribute a phone number, along with its messages and usage, to a customer, or clear the assignment. This is unambiguous about what the tool does. It does not name or distinguish itself from adjacent siblings such as bulk_update_numbers, link_number_to_registration, or update_customer, so it stops short of a 5.

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

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

The description implicitly tells the agent to use customer_id=null when unassigning, which covers one usage branch. However, it gives no guidance on when to prefer this tool over bulk_update_numbers, link_number_to_registration, or update_customer, and states no prerequisites such as ownership or 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?

Adds a genuinely useful trait beyond the annotations: 'Live numbers are billed monthly each' warns of recurring cost, which matters for a destructive, open-world purchase. It still omits what happens if fewer than the requested quantity are available, whether the call is partial-success, and what permissions are needed — though annotations already flag destructiveHint=true.

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

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

Two sentences, zero filler, with the bulk/area-code scope front-loaded and the billing caveat second. Nothing could be removed without losing information.

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

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

For a destructive, open-world purchase tool with no output schema and 40% param coverage, key gaps remain: which numbers were actually purchased in the response, behavior when inventory is insufficient, and the 1–50 quantity bound. The cost warning is a good start but the definition is not fully self-sufficient.

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

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

Schema coverage is only 40%, so the description must compensate. It clarifies the semantics of area_code (single area code for the whole batch) and quantity (multiple numbers), and its 'sender pool' example hints at pool_id, but tags and the 50-cap are left to the schema and pool_id is only echoed implicitly.

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 (buy several numbers) with a scope qualifier (in one area code, at once), which implicitly distinguishes it from the single-number sibling purchase_number. It never names that sibling, so the differentiation is inferential rather than explicit.

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

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

The parenthetical '(e.g. for a sender pool)' gives one concrete context, implying bulk provisioning use. It does not say when to prefer purchase_number instead, nor that inventory should come from search_available_numbers first, nor any prerequisite about registration/verification.

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

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

The annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is carried by structured data and the description does not contradict it. The description adds only that the operation spans many contacts by id; it omits whether deletes are irreversible, how partial failures across a batch are handled, and any confirmation requirements.

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

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

A single front-loaded sentence that enumerates the three actions with zero filler. It is terse to the point of leaving information gaps, but nothing in it is redundant.

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

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

There is no output schema and no nested objects, so the return-value burden is low, but this is a destructive bulk mutation over up to 500 records and the description says nothing about irreversibility, partial-success semantics, or rate/scale constraints. Annotations cover the safety hint, leaving the description 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?

Schema coverage is low at 33% (only 'tags' is documented), so the description should compensate but does not. It does map its three verbs onto the action enum and states that ids are the targeting mechanism, but it never mentions the 500-id maximum, the 40-character tag limit, or that tags is mandatory for the two tag actions beyond what the schema already says.

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 set (add tags, remove tags, delete) against a specific resource (contacts) with a stated scale ('many... by id'), so an agent can tell it apart from the single-record siblings update_contact and delete_contact. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

'many contacts by id' implies this is the bulk alternative to delete_contact/update_contact, which is useful implied guidance. However, there is no explicit statement of when to prefer this tool, no warning that the 'delete' action is permanent and cannot be undone, and no guidance on batching limits or failure handling.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description reinforces this usefully with 'Releasing cannot be undone.' However, for a bulk mutation it omits genuinely valuable context not covered by annotations: whether a batch is atomic or partially applied, whether the confirm parameter is mandatory for release, and what happens on failure mid-batch.

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

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

Two short sentences, front-loaded with the capability and closing with the irreversible-operation warning. Efficient, with the only cost being the inaccurate operation enumeration rather than verbosity.

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

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

This is a destructive, non-idempotent bulk mutation with six parameters, no output schema, and only partial schema descriptions. The description adds nothing about partial-failure behavior, the required confirm value for release, or what the caller gets back, leaving key gaps for an agent to guess at.

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

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

With 67% schema coverage, the description should sharpen the remaining gaps, but its operation list conflicts with the enum ('assign to a customer' is not an action) and skips add_to_pool/remove_from_pool/set_label, which are exactly the parameters the schema documents thinly. The 1000-id cap and the confirm semantics are left entirely to 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 names the resource (numbers) and the batch scope, and lists example operations: tag, untag, assign to a customer, release. However, 'assign to a customer' does not exist in the schema's action enum (which offers add_to_pool, remove_from_pool, add_tags, remove_tags, set_label, release) and pool/label operations are never mentioned. The stated purpose is recognizable but the operation list is misaligned with what the tool actually does, so an agent could mis-select it.

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

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

'Act on many numbers at once' implicitly contrasts with the single-resource siblings (assign_number_to_customer, release_number), but no alternative is named and no when-not condition is given. The only explicit guidance is the warning that releasing is irreversible.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the meaningful constraint that only in-progress runs are cancellable, but says nothing about the effect on messages already queued or sent, or whether cancellation is immediate or graceful.

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

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

A single six-word sentence with the action and the state constraint front-loaded. There is no filler, though the brevity is close to the point of under-specification.

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

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

For a destructive, idempotent mutation with a fully documented two-parameter schema and no output schema, the essentials are covered. The remaining gap is what cancellation actually does to in-flight or already-sent messages, which an agent may need to set expectations before calling.

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

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

Schema coverage is 100% with both parameters (id, run_id) documented as automation id and run id. The description adds no additional meaning about the relationship between the two identifiers, so it sits at the baseline where the schema does the work.

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

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

States a specific verb and resource (cancel a run) with a scoping qualifier (in progress). It does not distinguish itself from the similarly named siblings cancel_batch, cancel_scheduled_message, or pause_automation, so an agent must infer that this targets an automation run rather than a batch or a scheduled message.

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?

'In progress' implies the precondition that the run must still be active, which is the main trigger condition. However, there is no explicit statement of when to prefer this over pause_automation or how to handle a run that has already finished, so usage is only implied.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds one genuinely useful fact beyond that — that already-sent messages are unaffected — but says nothing about what happens to queued or in-flight messages, or whether the cancel can be undone.

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

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

Two short sentences with zero waste; the core action is front-loaded and the caveat follows immediately. Nothing is padded or repeated from the name or annotations.

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

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

For a single-parameter mutation tool with destructive annotations and no output schema, the description covers the essential scope caveat but omits the boundary with pause_batch and the fate of unsent queued messages. An agent can call it, but cannot confidently predict the outcome for a partially sent batch.

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

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

There is a single parameter whose schema description ('Batch id') is fully covered, so the schema does the work. The description adds no meaning about the id, such as format or where to obtain it; baseline 3 applies for a fully documented 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 states a specific verb and resource ('Cancel a batch'), which is unambiguous on its own. It does not differentiate from close siblings like pause_batch or retry_batch, whose semantics differ in ways an agent must infer.

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 cancel versus pause or resume a batch, and no prerequisites or exclusions. The second sentence describes a consequence, not a usage condition, so the agent gets no routing guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description's only added behavioral context is the 'before it sends' constraint, which does usefully imply the call fails once a message is dispatched, but it does not say what happens to the record or what error/handling to expect.

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

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

One short sentence, zero filler, with the scope constraint placed where it is read first. Appropriate size for a single-parameter cancellation 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?

Simple tool with one fully documented parameter, rich annotations, and no output schema, so little is required. The description covers purpose and timing; only the post-send failure behavior and return shape are absent, which are minor given the annotation coverage.

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

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

Schema description coverage is 100% with a single required parameter documented as 'Scheduled message id', so the schema carries the semantics. The description adds nothing about id format or where to obtain it, which is the correct baseline when coverage is high.

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 (cancel a scheduled message) and adds the scope qualifier 'before it sends', which distinguishes it from delete_message and get_scheduled_message. It does not explicitly name a sibling or contrast with delete_schedule, so it falls short of full 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?

'Before it sends' implies the timing window in which this tool is the right choice, but the description never states what to do after a message has sent (e.g., use redact_message) or how it compares to delete_schedule. Usage must be inferred.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds genuinely non-obvious context the schema lacks: the exact return shape {verified, status, channel, charged} and the billing rule that the call is only charged when verified is true. It stops short of explaining what a repeated check does or what a failed/invalid code yields, which matters given destructiveHint=true.

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

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

Two short sentences with zero filler, front-loaded with the action and immediately followed by the payoff model. Every clause earns its place.

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

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

With no output schema, the description usefully covers return fields and billing, so an agent knows what it gets back. It is thin on failure semantics (invalid code, expired code, repeat checks) and on how it relates to the sibling verification tools, which is the main remaining gap.

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

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

Schema description coverage is 100% and the schema itself documents the phone/email fallback rule and the 409 invalid_state case in depth. The description only restates the phone-or-email targeting at a high level, adding no format, precedence, or length semantics beyond what the schema provides.

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

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

The description names a specific verb ('Check') and resource ('a verification code submitted by a user') and identifies the lookup dimension (phone or email the code went to). An agent can distinguish it from send_verification (which sends) and get_verification (which appears to fetch state) reasonably well, though those highly similar siblings are never named explicitly.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no mention of the confusable siblings get_verification, fallback_verification, or send_verification. The only routing hint ('After a fallback, check by email') lives in the schema, not the description, so an agent must infer the workflow position on its own.

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

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

The description says 'copy', which implies a non-destructive read-and-create operation, but annotations declare destructiveHint=true. This is a direct contradiction. The description also fails to explain what is copied (e.g., settings, numbers, metadata) or any side effects.

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

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

One sentence, front-loaded with the action and resource, with zero waste. It communicates the essential purpose immediately.

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 clone operation, an agent needs to know what gets duplicated (all settings? numbers? relationships?), whether the operation is synchronous, and potential side effects. The description provides none of this, and the annotation contradiction further undermines confidence.

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 50% (id has 'Pool id' description; name has none). The description adds meaning for the name parameter ('under a new name'), but the id parameter remains ambiguous—it could be the source pool id, but the description doesn't clarify. Marginal benefit over 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 (copy) and resource (sender pool) plus the key mechanism (under a new name). It clearly distinguishes from siblings like create_number_pool, update_number_pool, and delete_number_pool.

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, no prerequisites, and no exclusions. The description only implies usage by the word 'copy' but offers no explicit criteria.

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

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

Goes meaningfully beyond the annotations by disclosing the 6-hour sync cadence and, importantly, that credentials are validated with one read, sealed, and never returned — a real trust and security fact an agent cannot infer. It does not address the destructiveHint=true implications (e.g., whether reconnecting an existing provider duplicates contacts or overwrites the list), which is the main gap 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?

Front-loaded with the effect and cadence, then the provider list, then consent/phone semantics, then credential handling — a logical order. The parenthetical provider credentials make the single paragraph dense but every clause carries information; slight tightening could improve scanability.

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 21-parameter, non-idempotent, destructive, open-world tool with no output schema, the description covers the essentials: what gets created, the sync cadence, consent and phone sourcing, and credential safety. Missing pieces are the failure/re-connect behavior and what the created list looks like, which matter for 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?

With 90% schema coverage the baseline is 3, but the description adds genuine cross-parameter structure the flat schema cannot express: which credentials belong to Mixpanel (projectId, username, secret as service account) versus Amplitude (apiKey, secretKey) versus HubSpot (accessToken), and how consentEvent/consentField and phoneField interact with consent and phone capture. The per-provider mapping is the key value-add over 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?

Names a specific verb and resource ('connect a tool') and adds the concrete effect: people sync in as contacts, into a dedicated list, every 6 hours. It enumerates the supported providers and the credential shape per provider, which makes the tool unmistakable. It does not explicitly distinguish itself from near-siblings such as update_integration, sync_integration, or disconnect_integration, so it stops short of a 5.

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

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

The description implies when to use it (setting up a new provider connection) and the mode parameter explains pull vs. push behavior, which is helpful context. However, there is no explicit 'use this instead of X' routing to update_integration, sync_integration, or list_integrations, and no stated preconditions for an already-connected provider.

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

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

Annotations only declare the safety profile (destructive, non-idempotent, non-open-world). The description adds real behavioral context beyond that: the key inherits the connection's test/live mode, scopes are optional limits, the secret is returned only once, and the account owner is emailed. Those are exactly the kinds of facts an agent needs before mutating state.

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

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

Three tight sentences, front-loaded with the core action and use case, then behavior, then the critical one-time-return caveat. No wasted phrasing.

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

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

No output schema exists, and the description compensates by stating what comes back (the secret, only once) and the side effect (owner emailed). Combined with mode inheritance and scope behavior, an agent has enough to call it correctly; only the absence of explicit sibling routing keeps it from a 5.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, setting the baseline at 3. The description adds only a light gloss on scopes ('optional scopes limit it') and does not elaborate on the mode implication or what omitting scopes means 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?

States a specific verb and resource ('Create an API key') plus the concrete use case (store in app environment so the app can send texts). It implicitly distinguishes itself from siblings like list_api_keys and revoke_api_key by being the creation path, but never names those siblings explicitly.

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

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

Provides the scenario for use ('an app you are building... so the app can send texts itself'), which is genuinely helpful context. But it gives no explicit when-not guidance or reference to the related siblings (list_api_keys, revoke_api_key) an agent would need to reason about alternatives.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, so the bar is lower, and the description adds genuinely useful behavior: creation yields an inert draft that sends nothing until activation. That materially softens the safety picture. It does not address permissions, validation failures, or what happens when a step references a non-existent goto id.

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

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

Three front-loaded sentences: purpose and draft status first, mechanics second, concrete example third. The example earns its place by making the trigger/step/branch model tangible. Minimal waste, though the step-type list partially duplicates the schema's steps description.

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

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

For a nested, 5-parameter creation tool with no output schema, the conceptual model (trigger → steps → branches) is well covered, but the description never says what is returned — notably the new automation id the agent would need to call activate_automation. Error and validation behavior is also unaddressed.

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

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

Schema description coverage is only 40%, so compensation matters. The description explains trigger.event firing semantics and lists the step vocabulary, and the worked example anchors 'wait 3600s' and a condition check, but it says nothing about 'from', 'name', 'topic_id', or trigger.filters.

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 ('Create a triggered text flow') and immediately scopes it as '(as a draft)', plus enumerates the step types the automation can contain. It doesn't name siblings like update_automation or activate_automation directly, though 'until activated' gestures at the latter.

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 establishes clear usage context: automations are built as drafts and do nothing until activated, which implicitly routes the agent to activate_automation afterward. It gives a concrete worked scenario (cart_abandoned → wait → conditional reminder), but no explicit exclusions versus update_automation or create_schedule.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it doesn't say what happens on duplicate names, that a retry may create a second customer, or what state the account ends up in after creation.

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

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

A single sentence with no filler. The audience qualifier is front-loaded ahead of the action, which is slightly inverted for scanning but keeps the discriminating condition visible.

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

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

This is a mutation tool with no output schema, yet the description never indicates what is returned (presumably a customer id needed for assign_number_to_customer and get_customer_usage) or that all three parameters are optional, meaning a bare customer can be created. Those are material gaps for a create call that other tools depend on.

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

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

Schema description coverage is 67% (external_id and metadata documented; name not), so the schema does most of the work. The description adds no parameter-level meaning at all — it doesn't clarify what a 'customer' name represents versus the account name, or how metadata is used for attribution. Middle baseline is fair.

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 customer') plus the actual function: attributing numbers, messages and usage. It also scopes the audience ('Platforms sending for other businesses'), which no sibling name conveys. It stops short of distinguishing itself from lookalikes such as create_contact or upsert_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?

The 'platforms sending for other businesses' clause implies the account type that needs this tool, which is useful conditional context. But it never says when not to use it, nor does it point to update_customer for existing customers or create_contact for end recipients, leaving the agent to infer routing among ~100 siblings.

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

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

With annotations already declaring readOnlyHint=false and destructiveHint=true, the description still adds real context: the tool returns two DNS records (CNAME and TXT) that the user must add at their DNS host before verification. It does not explain why a create operation is flagged destructive (e.g. does it block short-link creation until verified?) or whether repeat calls on an existing domain fail — a gap given idempotentHint=false.

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

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

Three short sentences, front-loaded with the action and example, then the DNS/verify follow-up, then the rationale. Nothing is redundant and no sentence could be dropped without losing information.

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

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

For a one-parameter tool with no output schema, the description usefully discloses the return payload (CNAME + TXT records) and the required next step. Missing only edge-case behavior — duplicate domains, failure modes, and the reason for the destructive flag — which an agent would want before calling.

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

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

Schema description coverage is 0% for the single 'domain' parameter, so the description must carry the meaning — it does partly by showing the expected format ('links.example.com') and constraining it to the user's own subdomain. It leaves open whether a bare root domain is accepted and whether the subdomain prefix must be included.

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

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

States a specific verb and resource ('Add a subdomain of the user's own ... for short links') and grounds it with a concrete example (links.example.com). An agent can immediately distinguish this from get_link_domain, list_link_domains, delete_link_domain, and verify_link_domain, the last of which is explicitly named as the follow-up step.

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 sequences the workflow ('Returns two DNS records ... then verify the domain') and gives a rationale for using one's own subdomain rather than a shared one ('carriers filter those'). It stops short of explicit exclusions, e.g. when to use verify_link_domain vs check_verification, but the intended context is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true, so safety is covered. The description adds domain framing but says nothing about duplicate-name behavior, limits, or what the call returns, which is the meaningful gap left for a create 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?

Two tight sentences with the core definition front-loaded and the disambiguation second. Every clause earns its place, including the parenthetical location hint.

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 conceptual model is complete, but for a mutation with no output schema and zero parameter documentation, the description omits post-call behavior (created list identifier, how contacts get added afterward) and duplicate handling. Adequate to choose the tool, thin on how to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries full burden, yet it never mentions the two parameters (name, description) or their constraints. Notably, neither parameter is required in the schema, and the description gives no clue that a name is effectively needed, leaving the agent to infer 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?

States a specific verb and resource ('Create a list') and immediately defines the domain concept ('a fixed group of contacts, Audience → Lists'). It also explicitly contrasts with the sibling concept create_segment, so an agent can pick between them without opening schemas.

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

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

Gives a concrete when-to-use rule with a quoted user utterance ('add these people to VIPs') and names the alternative (segment) for rule-based membership. It stops short of covering closely related siblings such as add_to_list or what to do when a list with the same name already exists.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered; the description adds only the ownership precondition. Critically, it never explains which numbers end up in the pool — the schema has no numbers parameter at all — so the core behavior of the call is left ambiguous.

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

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

A single short sentence with no filler, which is well front-loaded, but the brevity comes at the cost of substance rather than being earned conciseness.

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

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

For a mutating, destructive-flagged creation tool with no output schema and only one-third parameter coverage, the description leaves key questions unanswered: how numbers are associated with the pool, what happens to a number already in another pool, and what is returned.

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 33%: only `routing` is documented, and its enum description is thorough. `name` and `description` have no explanation in schema or description, and the description mentions no parameters at all, so it does not compensate for the coverage gap.

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

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

The description gives a specific verb and resource ("Create a sender pool") and adds the constraint that the pool is built from owned numbers, which separates it from clone_number_pool and update_number_pool. It doesn't explicitly name those siblings, but the intent is unambiguous.

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

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

There is no statement of when to use this versus clone_number_pool or update_number_pool, no prerequisite about needing purchased numbers first, and no note that numbers must later be attached. The only implied guidance is "numbers you own," which is a precondition rather than a usage rule.

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

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

Annotations already flag the operation as non-read-only, destructive, open-world, and non-idempotent, so the safety profile is covered. The one genuinely additive line is 'Every occurrence runs the usual send checks,' which tells the agent that compliance checks repeat per firing; nothing is said about cost, how to stop a live schedule, or what happens on failures. No contradiction with annotations.

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

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

Two tight sentences, zero filler, with the core behavior front-loaded before the compliance note. Its brevity is appropriate to the format, though it leaves substantial ground uncovered for a ten-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?

Considering the schema already documents the recurrence fields, quiet_hours, idempotency, and date bounds in detail, and there is no output schema to explain, the description covers the essential 'what and why' adequately. It is thin on lifecycle questions (pausing, cancelling, what a created schedule returns) relative to a destructive recurring-send tool.

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

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

Schema coverage is high (70%) and the nested repeat object is fully documented in-schema, so the baseline is 3. The description contributes two useful clarifications, 'one number' (to is a single recipient, not a list) and 'at a local time' (the time is wall-clock in the given timezone), but says nothing about start_date, end_date, max_occurrences, or quiet_hours behavior.

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: send the same text to one number on a daily, weekly, or monthly cadence at a local time. That implicitly separates it from send_message (one-off) and update_schedule/delete_schedule, though it never names a sibling outright. 'One number' also fixes the cardinality of the target, which the bare name does not.

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?

Beyond the parenthetical 'e.g. a weekly reminder' there is no statement of when to choose a schedule over send_message, a scheduled message, or create_automation, all of which sit nearby in the sibling list. No exclusions, prerequisites, or limits (e.g. per-account schedule caps) are given, so an agent must infer the fit 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?

Adds real behavior beyond the annotations: live re-evaluation on every use ('a batch or list sent to it reaches whoever matches then'), the 10-rule ceiling, and the 20,000-event search window. It omits the persistence/irreversibility angle that destructiveHint=true implies, and does not mention that name is optional, but the dynamic-membership disclosure is exactly the non-obvious fact 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?

Three sentences, purpose front-loaded, and the long middle sentence is a dense but scannable enumeration with clear 'Attributes:' / 'Behaviour:' labels. Some fillers ('a segment, a cohort') and the run-on rule listing could be tightened without losing information.

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

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

For a tool with no output schema, the description never says what comes back (segment id? object?) or whether the name must be unique, and it does not touch the optional name/description params despite required-parameters being 0. Rule construction, the highest-complexity part, is covered adequately, so the gaps are moderate rather than disqualifying.

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 the rule vocabulary well: 'field = "field", key = the name', batch key = batch id with its five values, time values as ISO dates or windows like 7d, and 'all (or any) of up to 10 rules' maps to match and rules. However, the top-level name and description parameters are never addressed, and the per-field semantics largely duplicate what the nested schema descriptions already say.

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

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

Opens with a concrete verb and resource ('Save an audience (a segment, a cohort)') and states where it surfaces (Audience → Segments) and what consumes it (broadcasts). It never names the nearest siblings (create_list, query_audience, preview_segment), so differentiation is implied by the 'one rule' vs 'rules' framing rather than stated.

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

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

Usage is only implied: 'broadcasts can be sent to it' and 'evaluated live each time it is used' suggest when a saved segment is preferable to a one-off query. There is no explicit when-to-use / when-not guidance, and the alternatives an agent would hesitate between (create_list, query_audience, preview_segment) are never mentioned.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, which are non-obvious for a create operation and are never explained or reconciled in the description. The merge-tag syntax is useful content guidance but says nothing about whether repeated calls create duplicate templates, whether the name must be unique, or what the call returns. The description neither contradicts nor meaningfully augments the annotation profile.

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

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

Two short sentences, purpose front-loaded, no filler. The trailing 'per-recipient variables' is an undefined term that adds ambiguity rather than precision, which keeps it from a 5.

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

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

There is no output schema, so the description is the only source for return behavior, yet it never says whether the created template's ID is returned or whether the template is immediately usable in send_message/create_automation. For a mutation tool with a surprising destructive hint, key facts an agent needs before calling are 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 schema documents only types and max lengths. The description compensates partially by explaining the merge-tag syntax that is valid inside `body`, but it says nothing about `name` semantics (uniqueness, reuse across templates, effect on lookup). Partial compensation for a two-parameter tool.

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

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

The verb 'Save' plus the resource 'message template' make the operation unambiguous, and the name create_template aligns. It does not explicitly contrast with update_template or state whether it creates a new template versus overwriting an existing one, but an agent can identify the operation 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?

There is no guidance on when to use this tool rather than update_template (the obvious sibling for modifying an existing template) or when a template is the right choice over send_message with inline content. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true, so the mutating/non-idempotent profile is covered structurally. The description adds domain context about what a topic is but says nothing about duplicate-name behavior, permissions, or what happens on retry — the key consequences for a non-idempotent create.

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

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

One sentence, front-loaded with the action and resource, with the explanatory clause immediately after. No filler.

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

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

For a simple two-parameter create with annotations and no output schema, the description conveys the concept adequately, but it omits the parameter meaning and name-collision semantics an agent needs to call it correctly the first time.

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

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

Schema description coverage is 0% for both parameters, so the schema alone gives an agent only types and maxLength. The description does not explain what 'name' should be (label? slug? unique key?) or what 'description' is for, leaving both parameters under-specified.

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 subscription topic') plus the domain intent (per-message-type opt-out). It is distinguishable from update_topic/delete_topic/list_topics by the verb, though it never names those siblings explicitly.

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

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

The 'so people can opt out of one kind of message' clause implies when a topic is the right model, but there is no guidance on when to create vs. update an existing topic, whether names must be unique, or what to do if the topic already exists. Usage is inferred from the verb only.

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

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

Annotations already flag non-idempotent, destructive, open-world writes, so the safety bar is lower; the description adds the valuable, non-obvious behavior that the signing secret is returned only once and must therefore be captured. It does not explain why the operation is marked destructive or whether existing endpoints are affected.

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

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

Two tight sentences with no filler; the core purpose leads and the critical return-value caveat comes second.

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 4-parameter, no-output-schema mutation tool, the description covers the essential thing an agent cannot infer elsewhere: the one-time signing secret. Remaining gaps (filtering semantics, effects on other endpoints) are largely covered by the schema or annotations.

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

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

Schema coverage is only 50%, and the description only indirectly supports the `events` parameter through its event-name examples. It adds nothing about `numbers` filtering or the `description` label, leaving those to 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?

States a specific verb+resource (register an endpoint to receive named events) and enumerates concrete event types, which makes the intent unambiguous. It does not name or differentiate from siblings like update_webhook, test_webhook, or rotate_webhook_secret, so it stops short of a 5.

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

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

Usage is only implied: the examples of destinations (your app, a CRM, an automation tool) hint at when you would register a webhook, but there is no explicit when-to-use vs. update_webhook/test_webhook guidance and no prerequisites or exclusions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered elsewhere; the description adds nothing on top. It does not say whether deletion is permanent, what happens to in-flight runs and historical run data, or what the response contains. With annotations carrying the weight, this is a pass, not a help.

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

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

One short sentence with zero waste, but its brevity comes from under-specification rather than tight writing — the sentence conveys nothing an agent could not infer from the tool name alone.

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

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

For a destructive mutation with no output schema and no annotation-level detail about side effects, the description should explain permanence, cascade effects on automation runs, and any required state. None of that is present, leaving the agent to guess at consequences.

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?

A single parameter with 100% schema description coverage already documents 'id'. The description provides no additional meaning (no id format, no indication of where to obtain the id), so the baseline 3 applies.

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

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

The sentence gives a verb ('Delete') and a resource ('automation'), but it is a verbatim restatement of the title and tool name, adding no scope detail. Because ~10 sibling benchmarks are also delete_<resource>, the resource word is what distinguishes it, so an agent can pick it out, but only barely.

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

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

There is no guidance on when to use this versus alternatives such as pause_automation or update_automation, nor on prerequisites (e.g., whether an active automation must be paused or cancelled first). No mention of confirmation or irreversibility steps either.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds the genuinely non-obvious semantics that messages, consent records and topic preferences survive the delete. It doesn't say whether the delete is reversible or what happens when the id doesn't exist.

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

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

Two short sentences, action first and the non-obvious retention caveat second. Nothing wasted, nothing buried.

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

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

For a single-id destructive tool with full annotation coverage and no output schema, the description supplies the one piece of behavior annotations can't express (data retention). Minor gaps remain around failure behavior and reversibility.

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

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

Schema description coverage is 100% for the single required parameter ('id': 'Contact id'), so the schema carries the parameter burden. The description adds no format or sourcing detail beyond it, which is the baseline case.

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 ('Delete a contact'), which cleanly separates it from delete_message, delete_list, delete_customer and the other delete_* siblings. It stops short of naming any sibling explicitly, so it is clear but not differentiating in prose.

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 this instead of X' guidance: an agent must infer from sibling names whether delete_contact or forget_identity is the right call for removing a number's data. Only the retention sentence hints at a use case (keeping history while removing the contact).

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds nothing beyond that — it doesn't state whether deletion is soft or hard, whether related data (contacts, lists, messages) is cascade-deleted, or whether it's reversible. For a destructive operation, this leaves meaningful gaps.

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

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

It is a single, front-loaded sentence with no waste, but its brevity stems from under-specification rather than efficiency. There is nothing to trim, yet nothing substantive is communicated.

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

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

For a destructive mutation with no output schema, the description should clarify consequences (permanence, cascading effects, response). It provides none of this, leaving the agent reliant solely on annotations for a high-stakes 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 100% with a single required 'id' parameter documented in the schema, so the description need not carry this burden. Baseline 3 applies since the schema fully specifies the 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 'Delete a customer' simply restates the tool name and title verbatim, adding no distinguishing detail. It does not differentiate from the many other delete_* siblings (delete_contact, delete_topic, delete_segment, etc.) beyond the resource noun embedded in the name 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what conditions must hold before deleting a customer. The agent must infer everything from the name alone.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's job is to add consequence detail — which it does well: 'Every short link already sent on it stops working' tells the agent this breaks live traffic, not just config. It stops short of stating irreversibility or whether recovery is possible.

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

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

Two sentences, zero filler, with the destructive consequence front-loaded right after the action. Nothing to trim and nothing buried.

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

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

For a single-param destructive tool with no output schema, the description plus annotations cover what an agent needs: the action, the target, and the downstream impact. Only the permanence/reversibility question is left unaddressed.

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

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

Only one parameter with 100% schema description coverage ('Link domain id'), so the schema carries the semantics. The description adds no meaning about the id's format or source, which is acceptable at this coverage level.

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 ('Remove a branded link domain') and immediately clarifies the blast radius. It is distinguishable from siblings like delete_contact or delete_webhook by naming the exact resource, though it never explicitly contrasts with get_link_domain/list_link_domains.

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 keeping or verifying the domain, and no prerequisites or alternatives (e.g., verify_link_domain, list_link_domains) are named. The warning about links breaking implies caution but is not a usage rule.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered by structured data. The description adds genuinely non-obvious behavioral context beyond that: deletion is non-cascading, contacts survive. It stops short of stating whether the delete 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?

One short sentence with the most important caveat parenthetically front-loaded right after the verb. Nothing is wasted and nothing important is buried.

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

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

For a one-parameter destructive tool with full annotation coverage and no output schema, the essentials are present: what is deleted, what survives, and the safety hints from annotations. Only recoverability and permission requirements are unstated, a minor gap.

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

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

Single required 'id' parameter with 100% schema description coverage, so the schema already defines it. The description adds nothing about id format or where to obtain the list id, which meets the baseline-3 threshold rather than exceeding 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?

States a specific verb and resource ('Delete a list') and adds the key consequence that contacts are not removed, which distinguishes it from a cascading delete. It does not explicitly name the sibling it differs from, but the parenthetical does the disambiguation work.

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 alternatives such as delete_segment or remove_from_list, and no prerequisites or warnings about irreversibility. The agent must infer 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the description earns credit for going further: it says every copy of the message text is deleted, that opt-out records and billing are retained, and that the action cannot be undone. The retained-data detail is exactly the kind of context annotations cannot carry.

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

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

Three short sentences, no filler, with the destructive scope front-loaded and the retention caveat immediately after. Every clause carries information an agent needs.

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

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

For a single-param destructive tool with annotations and no output schema, this covers eligibility, blast radius, retention and irreversibility. It stops short of saying what happens to in-flight or scheduled messages, which matters given cancel_scheduled_message exists as a 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?

Single required parameter with 100% schema description coverage ('Message id (msg_...)'), so the schema already carries the load. The description adds no additional meaning about the id or which message states are valid inputs beyond the finished-state scope already noted.

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

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

States a specific verb (Delete) plus the resource and, crucially, the eligible states: 'finished message (delivered, failed or received)'. That scope qualifier distinguishes it from queued/scheduled deletion, though it never names a sibling like redirect_to redact_message or cancel_scheduled_message.

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?

'for a privacy request' gives the intent context for using it, so the when-to-use is implied rather than stated. There is no explicit exclusion ('not for scheduled messages') and no pointer to redact_message or forget_identity, which an agent facing a privacy request would plausibly weigh.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered. The description earns credit for adding the non-obvious consequence that the pool's numbers survive the deletion — the single most important fact an agent needs before calling this. It stops short of stating whether the delete is recoverable or what the response contains.

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

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

Two sentences, zero waste, with the outcome-defining fact about retained numbers placed immediately after the action. Nothing is padded or repeated from the name.

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 destructive tool with full annotation coverage and no output schema, the description covers what the tool does and the key side effect. Missing only whether the deletion is reversible and what happens to numbers' pool associations, which would round it out.

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

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

Schema description coverage is 100% for the single `id` parameter ("Pool id"), so the structured field carries the load. The description adds nothing about the id's format or how to obtain it (e.g., from list_number_pools), which is the baseline-3 case.

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

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

States a specific verb ("Delete") and resource ("sender pool"), which is unambiguous against siblings like get_number_pool, update_number_pool, or clone_number_pool. It uses "sender pool" where the tool name and schema say "number pool," a minor terminology drift, but the intent is still clear.

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: nothing says to prefer update_number_pool for edits, to reassign numbers first, or what prerequisite state a pool must be in. The agent must infer the context entirely from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond repeating the verb: it does not say whether deletion is permanent, what happens to pending scheduled messages, or whether the schedule must be paused first.

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

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

A single short sentence with zero waste and the verb front-loaded. It is not padded, though the extreme brevity leaves the burden of detail entirely to the schema and annotations.

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

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

For a destructive mutation with no output schema, the description should say what is destroyed (the recurring schedule only, or queued sends as well) and whether the action is recoverable. Neither is addressed, leaving the agent to infer consequences from annotations alone.

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

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

With one parameter at 100% schema description coverage, the schema already documents 'id' as 'Schedule id'. The description adds no format, source, or lookup guidance (e.g., where to obtain the id), so the baseline of 3 applies.

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

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

States a specific verb (Delete) and resource (recurring schedule), which distinguishes it clearly from get_schedule, update_schedule, and list_schedules. It does not explicitly name a sibling or clarify scope beyond 'recurring', but the action is unambiguous.

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

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

There is no guidance on when to use this versus update_schedule or how it relates to scheduled messages already queued. Usage is only implied by the verb 'delete' — no prerequisites, exclusions, or alternatives are mentioned.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried structurally. The description adds a genuinely new fact not in any structured field: contacts are not affected by the deletion. It stops short of saying whether the deletion is permanent or what happens to automations/schedules referencing the segment.

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

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

Two short sentences, zero filler, with the destructive action stated first and the notable side-effect caveat immediately after. Nothing to trim.

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

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

For a single-parameter delete, the combination of a destructive/idempotent annotation set, a fully described id, and the contacts-not-affected note covers what an agent needs to invoke it. Missing only whether deletion is reversible and whether dependent automations break.

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

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

There is one parameter and schema coverage is 100% ('Segment id'), so the schema fully documents it. The description adds no format, prefix, or lookup guidance beyond that, making the 3 baseline appropriate.

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

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

Specific verb + resource: 'Delete a segment.' The second sentence preempts a likely misreading (that contacts in the segment are removed), which sharpens the scope. It does not explicitly contrast with update_segment or get_segment, but the resource distinction is unambiguous against the delete_* siblings.

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

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

No indication of when to use this versus update_segment or list_segments, and no prerequisites or confirmation guidance. The only cue is the implicit 'you need the segment id', which the schema already supplies.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally; the description adds nothing on top — no statement about permanence, whether templates in use can be deleted, or what happens to linked automations/messages. No contradiction, but zero added context for a destructive 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?

It is a single short sentence with no waste, but this is under-specification rather than conciseness — the entire description could be deleted without losing information, since it merely echoes the title.

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

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

For a destructive, non-readonly tool with no output schema, the description should convey consequences (hard vs soft delete, cascading effects) and any preconditions. Annotations cover the safety flags, but an agent still cannot predict the effect of calling it correctly.

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

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

Schema description coverage is 100% and the single `id` parameter is documented as 'Template id' in the schema, so the baseline of 3 applies. The description adds no format hints (e.g., where to obtain the id) beyond what the schema provides.

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

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

The description restates the tool name and title ('Delete a template') without adding scope, and it does not distinguish this from the many sibling delete_* tools (delete_segment, delete_list, delete_webhook, etc.). An agent learns nothing beyond the verb+resource already encoded in the name.

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

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

No guidance on when to use this versus update_template, get_template, or list_templates, and no prerequisites or exclusions stated. The agent must infer entirely from the name that this is the removal path for templates.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations by clarifying that only user-created topics are deletable and built-in topics are protected.

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

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

The description is a single front-loaded sentence with zero waste. It communicates the action and the key constraint immediately.

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 operation with annotations covering destructive/idempotent behavior and full schema coverage, the description is nearly complete. It does not describe the return or error behavior, but no output schema exists and the essential call conditions are covered.

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

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

Schema description coverage is 100% with a single parameter, id, fully documented as "Topic id." The description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description gives a specific verb and resource ("Delete a topic") and adds an important scope constraint: only topics the caller created, while built-in topics remain. It is clearly distinguishable from sibling tools like update_topic or get_topic, though it does not explicitly name alternatives.

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

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

It states when deletion applies (topics you created) and implicitly when it does not (built-in topics stay). It lacks explicit guidance on alternatives such as update_topic or list_topics, but the core usage boundary is clear.

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

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

The annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=false, so the key safety profile is covered externally. The description adds no behavioral context beyond the purpose, such as permanence, auth requirements, or effect on webhook deliveries, but it also does not contradict the annotations.

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

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

The description is a single short, front-loaded sentence with no wasted words. Its conciseness is appropriate, though it borders on under-specification for a destructive operation.

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

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

For a one-parameter delete tool with rich annotations and full schema coverage, the minimum needed to invoke is present. However, the description does not clarify permanence, error behavior for unknown IDs, or side effects on webhook deliveries, leaving meaningful gaps for 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?

The schema has 100% description coverage for the single required parameter, 'id', documented as 'Webhook endpoint id.' The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Delete a webhook endpoint.' It is clear what object is affected, but it does not differentiate this tool from siblings such as update_webhook, get_webhook, or test_webhook beyond the operation name.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The deletion intent is implied by the verb, but the agent gets no routing help.

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

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

The annotations already flag destructiveHint=true and idempotentHint=true, and the description adds genuinely new information: exactly what is destroyed (credentials and the list) and what survives (contacts, subject to consent). That is useful blast-radius detail beyond the structured fields, though it doesn't address whether the disconnect is reversible or what happens to automations tied to the integration.

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

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

A single compact sentence that front-loads the action and then the data consequences; every clause carries distinct information and nothing is padding.

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

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

For a destructive one-parameter mutation with no output schema, the description covers the most important question an agent has: what is lost versus retained. Gaps remain around reversibility (can the integration be reconnected) and side effects on related automations, so it is strong but not exhaustive.

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 only one parameter at 100% schema description coverage, the schema already defines "id" as the Integration id, so the baseline is 3. The description refers to "a tool" rather than confirming the identifier is an integration id, adding no format or sourcing guidance 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 names a specific verb and resource ("Disconnect a tool") and immediately states the consequences for credentials, the integration-owned list, and contacts, which makes it distinguishable from connect_integration, sync_integration, and update_integration. It does not explicitly name or contrast those siblings, which keeps it just short of a 5.

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

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

Usage is only implied through the effect statement; there is no explicit "use this when" guidance, no precondition such as the integration needing to be connected first, and no pointer to sync_integration or update_integration as the non-destructive alternatives. The agent can infer the situation, but nothing is spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds that the output is CSV text and that ledger mode includes opt-in proof, which is useful behavioral context. It does not cover auth requirements or rate limits, but the annotation coverage lowers the bar.

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

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

The description is a single, front-loaded sentence fragment with no wasted words. It is very concise, though the lack of an explicit verb slightly reduces clarity.

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

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

For a simple read-only export tool, the description covers the output format and the two data options, which is enough to invoke it. However, it does not disambiguate from the sibling export_csv tool, leaving an agent to infer which export to use when both are available.

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 both enum values by describing what each mode returns (suppression list vs. consent ledger with opt-in proof), effectively documenting the single 'type' parameter even though it does not restate the default.

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

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

The description names the data being exported (suppression list or consent ledger) and the output format (CSV text), so the resource is clear. However, it is a noun phrase without an explicit verb and does not differentiate this tool from siblings like export_csv or list_opt_outs.

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

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

There is no guidance on when to choose export_consent over export_csv, list_opt_outs, or get_consent. The two modes are implied by the description, but no context or exclusions are provided for selecting this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds two genuinely new facts beyond structured data: the output format is CSV text and there is a hard 50,000-row ceiling, which is exactly the kind of constraint an agent must know before choosing a date range.

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

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

Two sentences, front-loaded with the core action and the dataset list, then the constraint. The dataset enumeration is long but functional; nothing is wasted, though the list dominates the payload.

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 22-parameter, kind-switched export tool, the description covers the essential decision inputs: what kinds exist, that output is CSV text, and the row limit. With no output schema, stating the CSV return format matters and is present; per-parameter semantics are fully handled by the schema, so no major gap remains.

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

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

Schema description coverage is 100% and each of the 22 parameters already documents which kind it applies to, so the schema does the heavy lifting. The description only restates the purpose of from/to for date narrowing, adding no syntax or kind-specific semantics the schema lacks. Baseline 3 applies.

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

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

The description gives a specific verb+resource (export as CSV text) and enumerates the nine exportable datasets, which is more informative than the title alone. It stops short of differentiating from siblings like export_consent, export_numbers, or the parallel list_messages/list_events tools, which share the same data domains.

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?

"for analysis" implies the intended use and the 50,000-row cap with "narrow the date range with from and to" gives practical guidance. However there is no explicit statement of when to prefer this over list_messages/list_events for the same data, nor when to use export_consent or export_numbers instead.

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

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

Annotations declare read-only, idempotent, non-destructive behavior, so the description need not repeat that. However, it adds only 'CSV text' about the return format and says nothing about pagination, scope (e.g., all numbers vs. filtered), or what data is 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 single sentence is front-loaded but drastically under-specified for a tool with four parameters. It is too terse to be useful, rather than efficiently concise.

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

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

With no output schema and zero parameter descriptions, the description should explain the return format and filter options. It only says 'CSV text' and leaves major gaps for an agent to call the tool correctly.

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

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

The input schema has 4 parameters with 0% description coverage, and the description provides no information about what q, tag, mode, or pool mean. The description fails to compensate for the missing schema documentation entirely.

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 restates the name and title with only the added detail 'as CSV text'. It does not distinguish the tool from siblings such as export_csv or export_consent, leaving ambiguity about whether 'numbers' means phone numbers or something else.

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

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

No guidance on when to use this tool instead of export_csv, export_consent, or list_numbers. There is no context about prerequisites, filtering, or appropriate scenarios.

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

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

Beyond the annotations, the description explains that the emailed code replaces the texted one, is checked against the email address rather than the phone, and is limited to once per verification. These details make the destructive and non-idempotent behavior concrete.

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 tight sentences with no filler. The triggering condition is front-loaded, followed by the replacement behavior and the usage limit.

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

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

For a destructive mutation with no output schema, the description covers the key behavioral facts an agent needs: replacement of the texted code, email-based proof, one charge, and once-per-verification limit. It does not describe the response or error cases, which is a minor remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for the id and email parameters: it clarifies that the same pending verification is reused, that the email address is what the code proves, and that there is one charge. It does not explain the optional user_ip parameter, but the schema already covers 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 states a specific action, 'email a new code,' on a specific resource, 'the same pending verification.' It also distinguishes this fallback path from the normal texted-code path by noting that the text did not arrive and that the emailed code replaces the texted one.

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 opening condition 'The text did not arrive' clearly signals when to use this tool, and 'Once per verification' provides an important usage constraint. It does not explicitly name alternatives such as check_verification or send_verification, so it stops short of full when/when-not guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the destruction signal is carried structurally. The description adds real value beyond that by naming the blast radius: events remain tracked but stop reaching automations. It does not say whether the erasure is reversible or what is retained, which leaves a gap for a destructive privacy 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?

A single sentence with purpose and effect front-loaded and no filler. Every clause earns its place.

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

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

For a one-parameter, no-output-schema tool with annotations covering safety, the description gives enough to invoke it correctly. The main omission is what happens to events already recorded and whether errors occur for unknown user_ids.

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

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

Schema coverage is 100%, so baseline is 3. The description goes slightly beyond by explaining that the user_id is the lookup key for the phone number being forgotten, which disambiguates the schema's thin 'Your user id' hint. It still does not state whether user_id must be an existing, previously-seen identity.

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 (forget/erase the phone number linked to a user_id) plus the downstream effect. This is clearly distinguishable from delete_contact or redact_message in intent, though no sibling is named explicitly. An agent can tell what the tool does without opening the schema.

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

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

The 'Privacy erasure' framing and the consequence (tracked events stop reaching automations) imply the use case: honoring an erasure request. However, no explicit when-to-use/when-not, no prerequisites (e.g., does the user need to exist?), and no named alternative such as delete_contact for full record removal.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds something the annotations cannot: that the response is composed of the automation plus its trigger and steps, which is valuable given there is no output schema.

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

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

One short sentence, front-loaded with the action verb, with no filler or restatement of the title. Every clause carries information.

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

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

For a single-parameter read tool with rich annotations and no output schema, the description is nearly sufficient: it identifies the record and the components returned. Only minor gaps remain, such as not-found behavior or a pointer to the list/run siblings.

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

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

Schema coverage is 100% and the sole parameter 'id' is documented in the schema as 'Automation id'. The description adds no format, prefix, or sourcing detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb ('Retrieve') and a specific resource ('an automation'), and names the payload shape (trigger and steps). It does not distinguish itself from nearby siblings such as list_automations or get_automation_run, so an agent must infer the single-vs-list distinction from the name alone.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The singular 'an automation' weakly implies a single-record fetch by id, but alternatives (list_automations for enumeration, get_automation_run for execution state) are never referenced.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral detail beyond that — the response includes a step-by-step timeline — but says nothing about what happens for an unknown or expired run_id.

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

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

A single front-loaded sentence with zero filler; the resource and the notable return characteristic (timeline) are both stated immediately.

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 two-parameter read tool with complete annotations, the description is adequate but thin. With no output schema, it could do more to characterize the returned run (status, timestamps, step data) and to point at list_automation_runs for discovering run_ids.

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

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

Schema description coverage is 100%, so both parameters are documented as 'Automation id' and 'Run id'; baseline 3 applies. The description does not disambiguate the relationship between the two IDs (e.g. whether run_id alone would suffice) or note that both are required.

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 ('Retrieve one run') and adds scope detail ('with its step-by-step timeline'). It is implicitly distinct from list_automation_runs (many runs) and get_automation (the automation itself), though neither sibling is named.

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

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

Usage is only implied: the agent must already hold a run_id, which suggests reading a known run rather than discovering runs. There is no explicit instruction to call list_automation_runs first to obtain the run_id, and no stated exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that auto-recharge configuration is part of the read, but it says nothing about the shape of the response or whether auto-recharge is a nested object.

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

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

It is a single short fragment with no padding, which suits a trivial zero-arg getter, but the absence of a leading verb makes it read like a field label rather than an instruction. Brief but under-specified rather than efficiently expressed.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it only partially does so in a noun phrase. For a simple read-only getter it is close to adequate, but an agent still cannot tell the response structure or how it differs from get_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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The schema is fully self-describing at 100% 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 fragment names the two pieces of data returned (prepaid credit balance, auto-recharge setting), so the resource is identifiable, but there is no verb and no differentiation from related siblings such as get_usage, get_spend_limit or get_customer_usage. An agent can guess the purpose but must infer the framing.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the near-identical siblings (get_usage, get_spend_limit) that could easily be confused with this one. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description contributes only the hint that progress counts are included, which is thin given there is no output schema to describe the response shape.

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

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

A single front-loaded sentence with no filler or repetition. Brevity here reflects under-specification rather than waste, but nothing needs to be cut.

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 read tool with full annotation coverage, the essentials are present. However, with no output schema, the description should say more about what 'progress counts' includes or how this differs from get_batch_results; that gap is a real one for an agent assembling a batch-status workflow.

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

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

Schema description coverage is 100% (single required 'id' documented as 'Batch id'), so the schema already carries parameter meaning. The description adds nothing about format, source of the id, or behavior when the id is unknown, so baseline 3 applies.

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

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

Specific verb (retrieve) and resource (a batch), plus a phrase naming the payload ('progress counts') that goes slightly beyond the title 'Get batch'. It does not differentiate itself from close siblings such as get_batch_results, list_batches, or list_batch_recipients, which an agent must otherwise infer.

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

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

No when-to-use guidance and no mention of alternatives. With get_batch_results, list_batches, and list_batch_recipients all in the sibling set, the agent gets no help deciding which returns per-recipient results versus aggregate progress.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description contributes real value beyond that by enumerating exactly what categories of outcome data come back, which matters because there is no output schema — though it says nothing about pagination or freshness/completeness of in-flight batches.

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

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

A single sentence with zero filler, front-loading the resource and then listing the returned metrics in a compact grouping. Nothing could be removed without losing information.

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

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

For a simple read-only, single-parameter query with full annotation coverage, the description supplies the one thing missing elsewhere: what the response contains, in place of an output schema. Minor gap in not clarifying batch-state preconditions or whether results are partial for running batches.

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

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

Only one parameter (id) with 100% schema description coverage, so the schema fully documents the input and the description does not need to compensate. It adds nothing about the id's format or where to obtain it, which is acceptable but minimal.

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

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

The description names a specific resource (batch results) and enumerates the metrics returned — delivered, failed, pending, replies, opt-outs, spend, failures by reason — which is far more specific than the title's restatement. It does not explicitly contrast with get_batch or list_batch_recipients, so an agent must infer that this is the aggregate/summary view rather than per-recipient detail.

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 call this versus the closely related get_batch (metadata) or list_batch_recipients (per-recipient detail), and no prerequisites such as batch state or permissions. Usage is only inferable from the noun phrase 'Results of a batch'.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds that results include full consent history and proof (useful return context), but says nothing about auth requirements, behavior for unregistered or unknown numbers, or rate limits.

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

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

A single front-loaded sentence with no filler; the core answer (opt-in/out) comes first and the enrichments (history, proof) follow.

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 read tool with rich annotations and no output schema, this is nearly sufficient: it describes both the primary answer and the accompanying history/proof payload. Only edge-case behavior (unknown number, no registration) is left unstated.

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

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

With a single parameter at 100% schema coverage ('E.164 number'), the schema already carries the burden, so baseline 3 applies. The phrase 'per registration' adds a small amount of semantic nuance about result scoping, but the description does not elaborate on the phone parameter itself.

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

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

States a specific resource and scope: consent status (opted in/out) for a number, per registration, including history and proof. That is enough to distinguish it from set_consent (a write) and list_opt_outs (a listing), though it never names those siblings explicitly.

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

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

Usage is only implied by the purpose statement — an agent can infer 'check one number's consent status before messaging.' There is no explicit when-to-use, when-not, or pointer to alternatives such as set_consent, export_consent, or list_opt_outs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on behavior for a missing/unknown id, no indication of what data is returned, no rate-limit or permission context. It does not contradict the annotations, but it contributes no behavioral value.

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

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

A single three-word sentence with zero waste and the verb front-loaded, but the brevity here is under-specification rather than disciplined conciseness — there is no second sentence carrying the information an agent actually needs.

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

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

There is no output schema, so the description is the only place return contents could be described, and it is silent. For a single-resource fetch in a 100+ tool catalog, the agent cannot tell what fields come back, what error behavior to expect, or why to choose this over list_contacts. Annotations cover safety but not the informational gap.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented in the schema as 'Contact id'. The description adds no format hints (e.g., UUID vs. phone number vs. internal key) beyond the schema, so the baseline of 3 applies.

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

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

The description restates the tool name and title almost verbatim ('Get contact' → 'Retrieve a contact') without adding scope or distinguishing it from the many neighboring contact tools (list_contacts, get_contact_topics, update_contact, upsert_contact). An agent learns nothing about what 'a contact' contains or how this differs from fetching contacts in bulk.

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 mention of alternatives such as list_contacts for enumeration or get_contact_topics for related data, and no prerequisites stated. Usage is only inferable from the verb 'retrieve' plus the required id parameter.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that: no mention of paging, per-topic subscription state (subscribed/unsubscribed/pending), or behavior for a contact with no topics.

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

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

It is short, but a single sentence fragment is under-specification rather than concision. There is no front-loaded verb, so the reader gains nothing that the tool name did not already convey.

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

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

There is no output schema, so the description is the only place a caller could learn what is returned (a list of topics with subscription status). It omits that entirely, leaving a gap for a tool whose entire value is the returned shape.

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 one parameter and 100% schema description coverage ('Contact id'), the schema already carries the semantics. The description adds no format hints (e.g., contact UUID vs. phone number) so the baseline 3 applies.

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

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

The description is a noun phrase with no verb: 'A contact's subscription to each topic.' It essentially restates the tool name and title rather than stating an action ('retrieve the topic subscriptions for a contact'). An agent can infer retrieval only from the name, not from the description 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 when-to-use guidance is given. The sibling set is telling — set_contact_topic exists for writes and get_topic/list_topics exist for the topic catalog — but the description never distinguishes this tool from those or states the precondition (a contact id must exist).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that: no behavior for a missing or deleted customer, no note on what fields are returned, no scoping (account/workspace) constraints. With annotations doing all the work, the description earns only minimal credit.

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

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

A single short sentence with the verb and resource front-loaded - nothing wasted, nothing padded. It is efficient, though efficiency here is partly a product of extreme under-specification.

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 read tool with rich annotations and no output schema, the description is minimally sufficient to call it correctly. However, it omits how to obtain the id and what happens on a not-found result, which are the two questions an agent actually has here.

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

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

Schema description coverage is 100% for the single 'id' parameter, so the schema already carries the documented meaning and the baseline of 3 applies. The description adds no format, source, or validation detail (e.g. whether id is the internal customer id or an external identifier).

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 ("Retrieve a customer"), which is slightly more than the title restating itself, but it does nothing to distinguish this from close siblings such as list_customers, get_customer_usage, or get_contact. An agent still has to infer that this fetches one record by id rather than an aggregate or usage report.

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

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

There is no when-to-use guidance, no mention of the alternative list_customers for enumerating customers, and no note on prerequisites such as needing a customer id obtained elsewhere. The agent is left to infer selection criteria from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context of its own — nothing on aggregation granularity, pagination, or whether the period bounds are inclusive.

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

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

A single short sentence with no filler, leading with the returned content. Its brevity is closer to under-specification than to padding, but nothing is wasted.

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

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

With no output schema, the description carries the burden of explaining what is returned; "messages, verifications and spend" does not say whether these are counts, timeseries, or aggregates. For a three-parameter reporting tool this leaves a meaningful gap.

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

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

Schema description coverage is 100%, including the defaults for start (first day of this month) and end (today), so the schema does the heavy lifting. The phrase "for a period" loosely ties to start/end but adds no semantics beyond what the schema states.

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

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

The fragment names the resource contents precisely ("messages, verifications and spend for a period") but omits a verb and any differentiation from close siblings such as get_usage, get_customer or get_spend_limit. An agent can infer it is a per-customer aggregate read, but cannot be sure from the text alone which usage tool to pick.

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 exclusions, and no mention of the account-level get_usage or get_spend_limit alternatives. The agent must fall back on tool names to disambiguate.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing else: no default time window when dates are omitted, no aggregation/granularity semantics, no rate-limit or cost notes, and no clue about how partial-result or empty-result rates are reported.

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

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

It is a single short sentence with no filler, which is good, but it reads as an under-specified fragment rather than a front-loaded explanation. Brevity here comes at the cost of information rather than from trimming waste.

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

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

For an aggregation tool with no output schema, three optional parameters, and undefined defaults, the one-line description leaves too much open. An agent cannot know the default time window, whether group_by defaults to 'day', or whether the result is a time series versus per-carrier totals.

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

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

Schema coverage is 67%; the description's 'by day, carrier, sending number' clarifies that group_by='carrier' means destination carrier and 'number' means sending number, which is mild added meaning. It says nothing about what happens when start_date/end_date are omitted, which is the main semantic question for an all-optional-param tool.

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

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

The phrase 'Delivery rates by day, destination carrier, or sending number' signals an aggregate deliverability-report tool, but it is a noun fragment with no verb and no noun for the resource itself. It is distinguishable from siblings by topic, yet it never states it retrieves/returns a report, and no sibling (e.g., get_usage, get_customer_usage) is referenced for contrast.

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 call this versus get_usage or get_customer_usage, no mention of how to interpret the three grouping modes, and no hint about defaults for the optional start_date/end_date. The agent must infer everything from the schema.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered without description help. The description adds a small amount of behavioral context by signaling that the response pairs the integration with its last sync, but says nothing about staleness, auth scopes, or failure modes. Added value over annotations is 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?

Six words with no waste, but this is under-specification rather than conciseness — the fragment is not front-loaded with an action verb and gives the agent almost no anchor. It earns its place only marginally.

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

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

There is no output schema, so the description carries the full burden of explaining return values, yet it never enumerates the fields returned beyond alluding to a last-sync timestamp, nor describes not-found behavior. For a simple single-record read this is a material gap.

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

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

Single parameter with 100% schema coverage ("Integration id"), so the schema already carries the burden; baseline 3 applies. The description does not clarify whether the id is a UUID, slug, or provider key, nor what happens with an invalid 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?

"One connected tool and its last sync" is a noun fragment that largely restates the name/title (get integration → one integration) rather than stating a verb+resource action. The one piece of added information, "its last sync," hints at what is returned, but an agent gets no explicit statement that this fetches a single integration by id.

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

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

There is no guidance on when to use this versus list_integrations, update_integration, or connect_integration, all of which appear in the sibling list. No prerequisites, no error/not-found behavior, no indication of whether this is for polling sync status.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description contributes the one genuinely new behavioral fact — that DNS records are included in the result — but says nothing about error behavior when the id is unknown.

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

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

A single compact sentence with zero filler, and the payload content (DNS records) is front-loaded. It borders on under-specification rather than verbosity, but nothing is wasted.

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

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

For a one-parameter read tool with rich annotations and a fully described schema, this is close to sufficient — the description even signals that DNS records come back, which no structured field states. Missing only not-found behavior and sibling routing.

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

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

Schema coverage is 100% and the id parameter is documented with its ld_ prefix format, so the schema carries the semantics. The description adds no syntax, format, or example beyond that, which is the expected baseline.

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

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

States precisely what is returned: a single short-link domain together with its DNS records. The word 'One' implicitly distinguishes it from list_link_domains, but no sibling is named, so differentiation is only inferable from the plural/singular contrast.

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 instead of list_link_domains or verify_link_domain, and no mention of prerequisites such as needing an existing ld_ id. The agent must infer the usage context from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the response includes a contact count, which is useful, but does not mention not-found behavior, permissions, or other operational details.

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

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

A single, front-loaded sentence with no wasted words. It communicates the core action and an important return detail efficiently.

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

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

For a simple read-only getter with full schema coverage and safety annotations, the description is largely complete. It notes the contact count return value, though it does not enumerate other list fields or error behavior; no output schema exists to fill that gap.

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

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

Schema description coverage is 100%, and the single parameter is documented as 'List id.' The description adds no format or semantic detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: retrieve a single list and its contact count. This implicitly distinguishes it from list_lists and list_list_contacts, but it does not explicitly name those alternatives.

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

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

Usage is implied by the standard 'get by id' pattern, but there is no explicit guidance on when to use this versus list_lists or list_list_contacts. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds that the response includes a 'delivery timeline', which is useful beyond annotations, but it does not describe pagination, error behavior, auth requirements, or the timeline's contents.

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

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

It is a single front-loaded sentence with no wasted words. The core action, identifier requirement, and returned detail are all stated immediately.

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

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

For a simple single-parameter read tool, the description plus annotations and full schema coverage are sufficient to invoke it correctly. It also hints that the return includes a delivery timeline, though it could be slightly more complete by noting how to obtain the id or what the timeline contains.

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

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

Schema description coverage is 100%, and the sole parameter is already documented as 'Message id (msg_...)'. The description restates the same id format but adds no additional syntax or semantic meaning beyond the schema, which matches the baseline of 3 when schema coverage is high.

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

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

States a specific verb ('Retrieve') and resource ('message'), including the identifier form ('msg_... id') and an extra return detail ('delivery timeline'). It is distinguishable from list_messages by the 'by id' phrasing, but it does not explicitly distinguish itself from sibling get_scheduled_message or other message-related 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 you should use it when you already have a message id, but it gives no explicit when-to-use guidance versus alternatives such as list_messages or get_scheduled_message. There are no exclusions or routing conditions.

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

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

Annotations already establish readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds value by naming the fields returned (useful since there is no output schema), but omits what happens if the number isn't owned or how the returned data is shaped.

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

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

A single front-loaded sentence identifying the action and the payload. The trailing field list is slightly list-like/fragmented but every element carries information; nothing is wasted.

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

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

For a one-parameter read with no output schema, naming the returned fields is the key compensating value, and it does that. However, it stops short of describing the return structure or the not-found/unauthorized case, leaving gaps an agent might need.

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

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

Schema coverage is 100% and the phone_number parameter is described as an 'E.164 number you own'. The description's 'one of your numbers' reinforces the ownership constraint but adds no format or syntax detail 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?

States a specific verb and resource ('Retrieve one of your numbers') and enumerates the data returned (status, registration, tags, pools, customer). It's clearly a single-number fetch, distinguishable in spirit from list_numbers and get_number_pool, though it never names those siblings to draw the contrast explicitly.

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

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

The phrase 'one of your numbers' implies a single-record lookup by an owned number, but there is no explicit guidance on when to prefer this over list_numbers, lookup_phone, or get_number_pool. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's only added signal is 'and its numbers,' which usefully tells the agent the response expands contained numbers rather than returning bare pool metadata. It says nothing about what happens with an invalid or deleted pool id.

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

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

A single front-loaded sentence with zero filler. It is arguably too terse to be maximally useful, but nothing in it is wasted.

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

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

For a simple one-parameter read with rich annotations and full schema coverage, this is close to sufficient. However, there is no output schema, so the agent has no view of the return shape — the description gestures at 'its numbers' but doesn't say what fields accompany them or how large a pool response might be.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as 'Pool id.' The description adds no format hints (e.g., whether the id is a UUID or a pool name), so it neither compensates nor detracts. Baseline 3 applies.

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

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

States a specific verb (retrieve) and resource (sender pool plus its numbers), so the agent knows it fetches a single pool with embedded number data. It doesn't explicitly differentiate from siblings like list_number_pools or get_number, but the singular resource makes the distinction reasonably inferable.

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 list_number_pools (enumerate pools) or get_number (single number lookup). The only implied usage is 'you have a pool id,' which comes from the schema, not the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds some useful context about what the response includes (checks, status, linked numbers), but does not mention error behavior or permissions.

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

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

It is very concise, but it is a sentence fragment that leads with the returned object rather than the action. There is no wasted text, though the structure is not front-loaded with an operation.

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

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

For a simple retrieval tool with rich annotations and full schema coverage, the description is adequate but incomplete. It partially describes returned content, but without an output schema it should say more about what the agent gets back.

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

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

Schema description coverage is 100%, and the single id parameter is already documented in the schema. The description adds no additional parameter semantics, so baseline 3 is appropriate.

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

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

The description names the resource and its included components ("checks, status, and linked numbers"), but it is a noun phrase rather than a clear retrieval action. It implies a single registration, which helps distinguish it from list_registrations, but it never explicitly says "retrieve by ID."

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

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

It gives no guidance on when to use this tool versus list_registrations or other get_* tools. There are no exclusions or prerequisites stated.

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