CodaPhone

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: the required 'contacts' scope and the one-contact-per-call cardinality. It omits idempotency/duplicate handling, rate limits, and any side effects (e.g. whether the contact is immediately messageable), so it is adequate but incomplete.

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

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

Four short sentences, front-loaded with the action and the required parameter, then options, then the two behavioral constraints. There is no filler, though the parameter sentence is largely duplicative of the schema.

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 4-parameter create tool with no output schema, the description supplies the action, the required and optional fields, the auth scope, and batch cardinality. The main gap is what happens on a duplicate msisdn, which an agent might need 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 100%, so all four parameters are already documented; the description mostly restates them. It adds only light framing ('list_id to file it under', 'opt_in_source note'), which is a marginal value-add over the schema and matches the baseline 3.

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

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

States a specific verb+resource ('Add a contact to the account') and immediately names the required identifier, making it clearly distinct from read-side siblings like list_contacts or search_numbers. It does not explicitly name a sibling it is not, keeping it 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 implied by the nature of the operation, and it adds the constraint 'Adds one contact per call', which is genuinely useful. However there is no explicit when-to-use/when-not guidance, no mention of alternatives for bulk contact creation, and no note on handling an already-existing number.

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

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

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: the operation requires the 'campaigns' scope, and the created campaign is inert until run_campaign is invoked. It is silent on idempotency/duplicate names, error modes, and what the call returns, but the auth and lifecycle context is genuine added 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?

Three tight sentences: what it creates, what to do next, and the prerequisite scope. No filler, and the core purpose is front-loaded.

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

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

For a creation tool with no output schema, the description never says what is returned (e.g., a campaign identifier) even though it tells the agent to chain into run_campaign, which presumably needs that identifier. The lifecycle chain is otherwise well 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%, so both parameters are already documented as name and optional base_message. The description only restates this ('with a name and an optional base message') without adding format, length, or validation semantics; 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?

Specific verb + resource ('Create a new bulk-messaging campaign') with the two configurable inputs named. It is clearly distinguishable from siblings like get_campaign, list_campaigns and run_campaign.

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

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

It explicitly routes the agent to run_campaign for the next lifecycle steps (variations, audience, schedule, launch) and states the required 'campaigns' scope. It does not state any when-not-to-use conditions, which keeps it 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?

With no annotations, the description carries the full behavioral burden and does disclose the key auth requirement (the 'read' scope) plus conditional return semantics ('the active number (if any)'). It does not explicitly declare read-only/idempotent behavior, but 'Get' plus the scope note make that behavior effectively unambiguous.

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, front-loaded with the action and resource, followed by a tight enumeration of return fields and the scope requirement. Every clause carries information an agent needs, with 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?

There is no output schema, so the description must cover return values, and it does so comprehensively (name, mode, number, plan, caps, usage, credits). Combined with the stated scope requirement and zero-parameter schema, an agent has everything needed to call this 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly describes the request as taking no inputs.

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

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

States a specific verb and resource ('Get the current CodaPhone account') and then enumerates exactly what the payload contains: name, mode, active number, plan caps, usage, and credits. No sibling tool overlaps this resource, so an agent can select it unambiguously without opening a 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 scope prerequisite ('Requires the "read" scope') and the word 'current' imply when to call it, but there is no explicit when-to-use, when-not-to-use, or alternative named. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the 'read' scope requirement and what data is returned, but says nothing about error behavior for a nonexistent id or any read-only guarantees beyond the implicit 'Get'.

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

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

Two tight sentences with the core action front-loaded and no filler. The scope requirement is appended cleanly, though it could arguably be folded into the first sentence.

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 no output schema, the description adequately conveys what the agent gets back by listing the returned fields and states the auth scope. It omits error/not-found behavior, which is the only real 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% for the single campaign_id parameter, so the schema already documents it. The description adds no format, example, or constraint details beyond 'by id', which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Get one campaign by id') and enumerates the returned sub-resources (base message, audience, schedule, pacing, counts), so the agent knows what this returns. It does not explicitly name or contrast with the sibling list_campaigns, so it stops short of full sibling differentiation.

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

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

The phrase 'by id' weakly implies this is the lookup path when you already have an identifier, but there is no explicit when-to-use or when-not guidance and no mention of list_campaigns as the alternative for enumerating campaigns.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add genuinely useful auth context by stating the 'read' scope requirement, but it says nothing about error behavior (e.g., not-found handling), rate limits, or whether the body may be truncated/redacted.

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

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

Two tight sentences with zero filler: the core action and returned fields come first, and the scope requirement is appended as a second clause. Every element 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?

There is no output schema, so the description appropriately summarizes the return payload fields, and it discloses the required scope. For a single-parameter read tool this is nearly complete; only error/edge-case behavior is omitted, which is minor.

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

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

With a single parameter at 100% schema description coverage, the schema fully documents message_id itself. The description adds no syntax, format, or source for the id 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 and resource ('Get one message by id') and even enumerates the returned fields (delivery status, direction, body, segment count, timestamp). It does not explicitly differentiate itself from siblings like get_thread, though the message-vs-thread distinction is reasonably implied.

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: retrieval of a single message by id. There is no explicit statement of when to use this versus alternatives such as get_thread or list_threads, and no conditions or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the required 'read' scope and that the thread's messages are included in the response, but says nothing about not-found behavior, message pagination, or read-only guarantees beyond the word 'Get'.

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

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

Two short sentences, zero waste, with the core action front-loaded and the scope requirement as a trailing constraint. Every sentence earns its place.

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

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

For a simple one-parameter read tool with no output schema, the description covers what is returned (thread plus messages) and the auth prerequisite. It is essentially adequate, missing only edge-case behavior for missing 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% but the single 'thread_id' description ('The thread id.') is bare. The description adds only 'by id', which roughly matches the schema without adding format or sourcing meaning; baseline 3 applies at high 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?

States a specific verb (Get) and resource (one conversation thread by id) and clarifies scope by noting it returns the thread 'together with its messages'. The 'one' implicitly distinguishes it from the sibling list_threads, though no sibling is named explicitly.

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

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

The description states a prerequisite ('Requires the read scope') but gives no when-to-use guidance or routing against alternatives like list_threads or get_message_status. Usage is only implied by the 'by id' framing.

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

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

With no annotations, the description carries the full burden; it does disclose the required 'read' scope and the shape of the returned data, which is genuine behavioral context. It omits pagination behavior, result limits, and whether the credit balance is account-wide or per-campaign.

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

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

A single front-loaded sentence that states the resource, the returned fields, and the auth prerequisite with 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 zero-parameter list tool with no output schema and no annotations, the description adequately covers what comes back (status, progress counts, credit balance) and the scope requirement. Pagination and empty-result behavior are the only notable omissions.

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. The description correctly implies no inputs are needed and adds no misleading parameter language.

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

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

States a specific verb and resource ('List the account's bulk-messaging campaigns') and even enumerates the payload (status, progress counts, credit balance). It is easy to distinguish from the singular get_campaign and from list_contacts, though it never names a sibling 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 implied by the operation itself (list campaigns) and the stated 'read' scope prerequisite, but there is no explicit guidance on when to prefer this over get_campaign or run_campaign. No exclusions or alternative-routing advice are given.

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

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

With no annotations, the description carries the burden, and it does disclose the required 'read' scope plus the result fields. It does not spell out rate limits, default pagination behavior, or explicitly confirm the operation is non-mutating, so it stops short of full transparency.

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

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

Three tight sentences: what it returns, then the optional controls, then the auth prerequisite. No filler and the key payload information is front-loaded.

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

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

For a five-parameter list tool with no output schema, the description covers result fields, filter options, pagination, and the required scope. Only the return shape details (pagination metadata, exact field formats) are left implicit, which is minor.

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

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

Schema description coverage is 100%, so every parameter (sort, limit, offset, search, list_id) is already documented with defaults. The description restates the same parameters without adding syntax, formats, or examples beyond the schema, so baseline 3 applies.

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

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

States a specific verb (List) and resource (the account's contacts), and even names the payload fields returned (opt-in status and timezone). The resource domain cleanly separates it from siblings like list_campaigns, list_threads, and search_numbers.

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

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

The description explains the optional filters and pagination available, which implies when to reach for them, but never names an alternative tool or states when not to use this one. Usage is inferred rather than prescribed.

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

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

With no annotations, the description carries the full burden and does well: it discloses ordering (most recent first), the returned payload shape (unread counts, last-message previews), pagination support, and the required 'read' scope. It stops short of noting pagination limits, default page size behavior beyond the schema, or errors.

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 dense sentences, front-loaded with the resource and scoping, then an auth note. 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, 2-param, no-annotation read tool with no output schema, the description covers return contents, ordering, pagination, and auth, which is nearly everything needed to call it correctly; only pagination limits/caps are 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 (limit, offset) are fully documented there with defaults, so the schema does the heavy lifting. The description's mention of 'limit/offset pagination' adds no syntax beyond that.

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

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

States a specific verb (List) and resource (account's conversation threads / inbox), and adds scope details (most recent first, unread counts, last-message previews) that let an agent distinguish it from get_thread and the list_campaigns/list_contacts siblings at a glance.

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

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

The description implies usage (the inbox listing) and notes the 'read' scope prerequisite, but never says when to choose this over get_thread or search-style siblings, nor any exclusions. Context is implied rather than stated.

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

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

With no annotations the description carries the full burden and does disclose meaningful traits: the side effect (clears the unread count), the auth requirement ('read' scope), and the return value (new total inbox unread count). It stops short of stating reversibility or behavior on already-read threads.

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 that is front-loaded with the primary action and adds only genuinely useful qualifiers. No redundant or filler content.

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

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

For a simple single-parameter mutation with no output schema, the description covers the action, its side effect, the required scope, and the returned value. Only minor edge-case behavior (e.g. already-read threads) 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?

There is only one parameter and schema coverage is 100%, so the schema already documents thread_id fully. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('mark a conversation thread as read') and clarifies the effect with a parenthetical ('clears its unread count'). The action is distinct from sibling read tools like get_thread and list_threads, though it does not explicitly name them.

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

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

The action is fairly self-explanatory so usage is implied, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative among siblings. Nothing warns against calling it on an already-read thread or in bulk.

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

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

No annotations are provided, so the description carries the full burden. It discloses useful traits: the required 'numbers' scope, the one-active-number-per-account rule, and the msisdn format. However, it omits whether the operation is idempotent, what happens to an existing number, whether provisioning has cost/irreversibility implications, and how failures surface.

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: purpose, required inputs plus optional extras, then the account constraint and scope requirement. Every sentence earns its place and nothing is buried or redundant.

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

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

For a mutation tool with no annotations and no output schema, the description covers the essentials: what it does, the prerequisite search step, the scope requirement, and the account-level constraint. The nested 'registration' object has no field-level guidance, and the outcome of provisioning (existing number handling, response shape) is left implicit, but coverage is broadly sufficient.

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

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

Schema description coverage is 100%, with each parameter documented in the schema, so the baseline is 3. The description restates the msisdn format and notes that label and registration are optional, but adds no syntax or semantic depth beyond the schema. It also loosely implies 'kind' must be provided even though the schema marks only msisdn required and defaults kind to local.

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 ('Provision/set up') and resource ('a phone number for the account') and ties the tool to its sibling 'search_numbers' as the source of the number. An agent can distinguish it from search_numbers and other siblings without opening a 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?

Routes the agent to search_numbers as the prerequisite source of a candidate and states the account constraint ('one active number') plus the required 'numbers' scope. There is a clear usage context, though no explicit when-not-to-use guidance or description of what happens if a number is already provisioned.

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

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

With no annotations, the description carries the full disclosure burden and does well: it states the required 'campaigns' scope, that sends automatically respect opt-outs, sending hours, credits, and plan caps, and that launch either starts immediately or waits for the scheduled time. It omits irreversibility/idempotency details for cancel and pause and doesn't describe failure behavior, so not a 5.

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

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

Front-loaded one-line purpose followed by a tight bullet list; each bullet maps one action to its parameters with no filler, and the trailing sentence covering scope and auto-enforced constraints is compact and 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 9-parameter multiplexer with no annotations and no output schema, the description covers every action, its inputs, and the cross-cutting sending constraints, which is close to sufficient for correct invocation. It stops short of describing return values or the effect of each control action (pause/resume/cancel semantics), leaving a small gap.

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

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

Schema description coverage is 100%, and every parameter already carries an action prefix in the schema itself ('generate: how many variations', etc.), so the description's action-to-parameter mapping largely restates structured data. It adds the useful grouping of parameters per action but no format or constraint detail beyond what the schema provides, making the baseline 3 correct.

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 specific verb and resource: 'Advance a campaign through its lifecycle,' then enumerates every action the single tool multiplexes. The lifecycle framing clearly separates it from siblings like create_campaign, get_campaign, and list_campaigns without needing to name them.

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

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

Each action bullet tells the agent what it does and which parameters it consumes, and the ordering (generate → variations → audience → schedule → launch) implies the intended workflow. It never states when *not* to use this tool or which sibling handles the excluded cases (e.g., creating a campaign), 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?

With no annotations, the description carries the full burden and does well: it declares the read-only nature ("Does not buy anything"), the required "numbers" scope for authorization, and the shape of results returned. It leaves out result limits/pagination and any rate-limit behavior, which are the remaining behavioral 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?

Three tight sentences, front-loaded with purpose, then filters, then return values and the non-purchase guarantee. No sentence is redundant 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 zero-required-parameter read tool with no output schema, the description covers purpose, filter semantics, authorization scope, and the returned fields (display, city/region, monthly price). Only result-set limits or pagination behavior is unaddressed, 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?

Schema description coverage is 100%, so the schema already documents all three parameters including defaults and the local-only caveat on areaCode. The description paraphrases those same semantics without adding format or constraint detail beyond the schema, matching the baseline for fully documented parameters.

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

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

States a specific verb+resource ("Search available phone numbers to provision") and immediately scopes it against the purchase action with "Does not buy anything." An agent can distinguish this read-only search from the sibling provision_number without opening either schema.

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

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

Explains that filters are optional and which conditions each filter selects (country, local/tollfree kind, 3-digit area code), giving clear context for when to apply them. It does not name provision_number explicitly as the follow-up alternative, so the when-to-use guidance is strong but not fully routed.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so well: it discloses that opted-out contacts are blocked, that free-send/plan limits apply automatically, and that the 'send' scope is required. These are non-obvious operational and auth constraints an agent needs. It stops short of describing failure responses, idempotency, or what is returned on success, so it falls short of a 5.

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

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

Two tightly packed sentences with zero filler. The core action is front-loaded, followed by the parameter routing rule and then the operational constraints, in a logical order for an agent reading top-down.

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 mutation tool with no annotations and no output schema, the description covers action, parameter modes, auth scope, and key blocking/limit behaviors. The one notable gap is what the caller gets back on success (e.g., a message id usable with get_message_status), which would help chaining in this sibling set.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, making 3 the baseline. The description reinforces the mutual exclusivity of 'to' and 'thread_id' and explains that 'name' saves a contact, but this largely restates what the schema descriptions already state rather than adding new syntax or format detail.

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

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

The description opens with a specific verb+resource: 'Send an SMS from the account's number.' This clearly distinguishes it from siblings like create_campaign, run_campaign, or mark_thread_read, which are about campaigns and thread state rather than message dispatch. An agent can identify the tool's function without opening the schema.

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

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

It gives explicit routing guidance between the two invocation modes: use 'to' for a new recipient, or an existing 'thread_id' to reply within a conversation. That is strong when-to-use guidance at the parameter level. It does not, however, contrast the tool against siblings (e.g., why send_message rather than create_campaign plus run_campaign), so not a full 5.

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