SMS Everyone MCP by usefulapi

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description earns credit by spelling out the real-world consequence (future campaigns are suppressed) and the hard constraint that numbers can never be opted back in. It stops short of describing partial-failure or duplicate handling, so the batch behavior remains partly opaque.

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 write marker is front-loaded, then scope, then irreversibility, then the use condition, then the endpoint. Every sentence carries information an agent needs, and 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 destructive, two-parameter write with no output schema, the description covers consequence, irreversibility, batch limits, and user-confirmation gating. Remaining gap is return/error behavior, such as whether invalid numbers fail the whole batch or are skipped, which a calling agent would want.

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 'confirm' and the international-format requirement for 'numbers'. The description only restates the 1-to-25 bound that the schema already enforces via minItems/maxItems, adding no syntax or format detail beyond it. 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 the specific operation (adds phone numbers to the optout database), the batch bound (1 to 25), and the downstream effect (no later campaign is sent to them). This clearly separates it from the read-only sibling smseveryone_list_optouts.

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?

"Do it only when the user asks" gives an explicit gating condition requring user intent, and the irreversibility note warns against casual use. It does not name a sibling alternative, but the sibling set offers no competing write path, so the guidance is nearly complete.

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 real value beyond that: irreversibility, the pre-start-time window, the server-side error behavior, and the underlying REST shape (POST /api/campaign with Action delete). It does not describe the confirmation workflow or recipient-side consequences, which keeps it from 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?

Three short sentences, mutation intent front-loaded, then the timing constraint, then the irreversibility warning. Every sentence carries distinct information with no restatement of the title or 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?

With only two fully documented parameters and no output schema, the description covers the essential calling context: what is destroyed, when it is allowed, and why failure occurs. Minor gap is the absence of any mention of the confirmation requirement that gates the write, which the schema carries 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?

Schema description coverage is 100%, so both parameters, including the confirm gate with its user-confirmation guidance, are fully documented in the schema. The description adds no parameter-specific detail such as where the campaign_id comes from or when confirm should be set, 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?

States a specific verb and resource ("deletes a scheduled SMS campaign so it is not sent") and makes the effect on delivery explicit. It does not name the closest sibling, pause_campaign, though the "cannot be undone" phrasing implicitly separates it from a reversible pause.

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 clear precondition and when-not: only works before the campaign start time, after which the API refuses with an error. It lacks an explicit pointer to pause_campaign as the alternative for campaigns already running, so routing to the right sibling is left partly to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds genuinely useful context beyond them: it discloses that the underlying call is POST /api/RetrieveUserSettings, which stops an agent from mistaking a POST endpoint for a mutation. It also lists the concrete fields returned, which annotations cannot convey since no output schema exists.

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 resource and the returned fields, then the endpoint detail. Nothing is padded and nothing needs re-reading.

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

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

With no output schema, the description must carry the return-shape burden, and it does by naming the four meaningful values. For a zero-parameter read with annotations covering safety, an agent has everything needed to call it correctly.

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

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

Zero parameters, so the baseline is 4; the empty schema means there is no parameter semantics to explain or compensate for.

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?

Uses a concrete verb ('Show') on a specific resource ('the SMS Everyone account') and enumerates exactly what is returned: user id, remaining credits, unicode flag, international-messaging flag. No sibling tool touches account-level settings, so the boundary is unambiguous without naming 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?

Usage is only implied: an agent can infer this is a pre-flight check before sending or a credit check. There is no explicit when-to-use statement, no prerequisites, and no named alternative (none exists among siblings, which mitigates the gap only slightly).

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 and openWorldHint=true, so the safety profile is covered. The description adds real value by naming the four possible status values an agent should expect back, but says nothing about behavior for an unknown or expired campaign_id, which matters for an open-world read.

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

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

Two compact sentences with the purpose front-loaded and no filler. The trailing 'SMS Everyone REST: POST /api/campaign with Action status' is mildly redundant implementation detail but short enough not to hurt scanning.

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 convey return semantics, and it does so by listing the four status states. For a one-parameter read tool with annotations covering safety, the only real omission is error/not-found behavior.

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

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

Schema description coverage is 100% and the single campaign_id parameter is already documented as the ID returned at send/schedule time. The description adds no syntax, format, or validity guidance beyond that, so the schema carries the burden and 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 ('Show') and resource ('campaign status') and enumerates the possible outcomes (Scheduled, Running, Paused, Deleted), which is more informative than the title alone. It does not, however, distinguish itself from the sibling smseveryone_get_delivery_status, which an agent must choose between.

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 'a sent or scheduled campaign' implies the prerequisite that the campaign_id must come from a prior send/schedule call, which is useful context. There is no explicit statement of when to prefer this over the nearby smseveryone_get_delivery_status or when the tool is not appropriate.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a genuinely important behavioral trait: the API returns the entire list while this tool truncates to the first `limit` numbers and reports the total count, so the agent knows results are partial and paging may be required. It also exposes the underlying endpoint (POST /api/crm), which explains why a read appears as a POST. Return shape detail beyond 'total count' is not given.

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 key behavior — truncation to limit plus total count — is front-loaded in the first two sentences. The trailing REST note ('POST /api/crm with Action details') is terse and slightly cryptic but short enough not to bloat the definition.

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 describing returns and does so adequately: a set of mobile numbers plus a total count. Combined with fully documented parameters and read-only annotations, an agent has enough to invoke it correctly, though it doesn't describe the shape of each entry or how paging terminates.

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 three parameters are already documented, including offset paging via next_offset. The description reinforces limit semantics ('first `limit` numbers') and that a total count comes back, but says nothing about offset, which is the parameter an agent is most likely to misuse. 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: 'Show the mobile numbers stored in one list,' which is clearly distinguishable from the sibling smseveryone_list_contact_lists (which returns lists, not numbers). It stops short of explicitly naming that sibling as the contrast, but the resource scope is unambiguous.

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

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

Usage is only implied: the agent must infer that this is the tool to call once it has a CrmId, and that inference is carried by the list_id parameter description referencing list_contact_lists rather than by the prose. No explicit when-to-use, when-not-to-use, or alternative is stated in 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?

With readOnlyHint/openWorldHint already declaring read safety, it still adds context that the annotations don't cover: an empty list has two distinct causes (no receipt yet, up to 24h, or a campaign id not on this account), and the production rate limit is one request per minute. It also names the underlying REST endpoint (POST /api/DRStatus), which is unusually 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?

Three sentences: the shape of the result first, then scoping, then the two operational caveats (empty results and rate limit). Each sentence adds a new fact, with nothing repeated from the schema and no filler.

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

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

With no output schema, the description must carry return values, and it does, listing the per-destination fields. Combined with the empty-list explanation and the rate limit, an agent has everything needed to call this and interpret a blank result; paging details sit in the schema, so omitting them is fine.

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 campaign_id, limit, offset and destination are already documented at the schema level, and the description mostly restates them. 'Pass destination to see one number only' adds a small amount about how the result set changes, but it says nothing new about limit/offset beyond the schema, so this 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+resource (delivery receipts of a campaign) and defines the shape of the result: one entry per destination containing a timestamp, a DeliveryReceiptStatusId and a carrier code. This makes it distinguishable from get_campaign_status, which is a campaign-level operation; get_delivery_status is per-destination.

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 specifies when to narrow the scope (pass destination for a single-number lookup) and when to use paging (offset/next_offset); it also states the prerequisite that campaign_id is the id returned when the message was sent or scheduled. It never explicitly rules out or routes to alternatives such as get_campaign_status or list_replies.

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 and openWorldHint=true, so the safety profile is covered; the description adds real value by mapping the tool to 'POST /api/crm with Action list', which pre-empts confusion about a POST-backed tool that is actually a read, and by enumerating the fields returned. It stops short of describing paging behavior or result-size implications, which the schema carries instead.

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

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

Two compact sentences: the returned-field inventory comes first, the REST mapping second. No filler and nothing redundant with the 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 parameterless read-list tool with full schema coverage and clear annotations, the description supplies enough: what it lists, what each entry contains, and the underlying API action. The returned-field list partly substitutes for the missing output schema; only pagination semantics are left entirely to the schema.

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

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

Schema coverage is 100% and the schema already documents limit (default 500, max 1000) and offset (with the next_offset paging hint). The description adds nothing about parameters, so the baseline 3 applies even though the endpoint/action note gives useful framing.

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 stored lists (CRM groups) of mobile numbers') and adds the returned fields (CrmId, description, number count). The plural 'lists' with no id parameter clearly separates it from the sibling get_contact_list, so an agent can pick correctly 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?

Usage is implied by the listing semantics and the returned field set, but the description never states when to use this versus smseveryone_get_contact_list, nor any conditions or exclusions. The REST endpoint reference ('POST /api/crm with Action list') is implementation detail rather than 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 readOnlyHint and openWorldHint, and the description adds genuinely new behavior: the API returns the entire list while this tool truncates to `limit` and reports the total, which is important for an agent reasoning about completeness. It does not state ordering or whether the total reflects pre- or post-pagination counts, but the truncation disclosure is the key trait.

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 resource and its significance, then pagination behavior, then the underlying REST call. Every clause carries information and nothing is repeated from 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?

With no output schema, the description still tells the agent what each row contains (number, date added, reason) and warns that results are truncated with a total provided. Combined with annotations, that is enough to call this correctly without exploring further.

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 `limit` and `offset` are already documented with defaults and bounds. The description reinforces the semantics of `limit` ('shows the first `limit` entries') but says nothing about `offset` beyond the schema, 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?

States a specific verb and resource — list phone numbers in the account's optout database — and even names the fields returned (number, date added, reason). It never contrasts itself with the closest sibling (smseveryone_get_contact_list / smseveryone_list_contact_lists), so an agent must infer that this is the suppression list rather than the marketing contact 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?

Usage is implied rather than stated: the parenthetical 'messages to them are never sent' tells the agent why the list matters, and the paging note implies use when enumerating opt-outs. There is no explicit when-to-use, when-not-to-use, or pointer to smseveryone_add_optouts as the write counterpart.

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?

Although annotations already mark it read-only and open-world, the description adds meaningful behavioral detail: rate limiting to once per minute per account, a recommended five-minute polling interval, time-window semantics, and the returned reply fields. It also notes the underlying REST endpoint without contradicting the read-only annotation.

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 purpose and returned fields are front-loaded, followed by compact operational guidance. The REST endpoint detail is slightly extraneous, and the phrase 'leaves the replies available for later calls' is a bit opaque, keeping 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?

For a read-only list tool with no output schema, the description supplies the return fields, time-window rules, default behavior, and polling constraints. Combined with full schema coverage and read-only annotations, an agent has enough information 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 coverage is 100%, and all five parameters (days, limit, offset, date_start, date_end) are fully documented in the schema. The description reinforces the time-window defaults and limits but adds little beyond what the schema already provides, 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?

States a specific verb and resource ('List SMS replies received on the account') and enumerates the returned fields (received time, Originator, Recipient, text, reference id). This clearly distinguishes it from sibling tools such as opt-out listing, contact-list retrieval, and campaign status.

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

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

Provides clear operational context: time-window selection via days 1-7 or a date range up to 30 days, default days=1, and a production polling limit with a recommended interval. It does not explicitly name a sibling alternative or a when-not-to-use condition, so it falls short of a full 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 and idempotentHint=true, so the description's job is added context, and it delivers: there is no server-side resume, the user must resume in SMS Everyone, and a running campaign likely completes first. What it omits is what state the campaign lands in and what the call returns, which matters for a destructive write.

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 WRITE marker and the core action before caveats. The trailing REST endpoint note is marginally useful but is the one sentence that could be trimmed without loss to the agent.

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

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

Covers preconditions, irreversibility and the real-world race with fast sends, which is what an agent needs before a destructive write. No output schema exists and the description doesn't indicate the response shape or resulting campaign status, 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% and both parameters, including the confirm gate, are fully documented in the schema. The description adds no parameter-level detail (e.g. how to obtain campaign_id beyond the schema text), 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?

Opens with 'WRITE: pauses a scheduled campaign (or one that is sending)', giving a specific verb, resource and mutation class in the first clause. The parenthetical about send speed makes clear this is a pause-not-cancel operation, separating it from smseveryone_cancel_campaign conceptually even without naming 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?

States a concrete precondition ('a campaign scheduled in the past cannot be paused') and the practical consequence of calling on a running campaign. It does not explicitly route to cancel_campaign or get_campaign_status when pausing is wrong, so the alternative-selection guidance is implied rather than 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 flag destructive/openWorld/non-idempotent, and the description goes further with credit spend, irreversibility, optout-list skipping, and the originator registration constraint. It does not cover response timing or delivery-status follow-up (e.g. get_delivery_status), which is the main remaining gap.

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

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

Front-loaded with the write/irreversible warning, which is the highest-priority fact, and all sentences carry actionable content. It is a dense wall of text in a single paragraph, and the cost arithmetic is slightly over-elaborated for the 10% weight it deserves.

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, credit-spending write with no output schema, the description covers cost model, irreversibility, recipient constraints, sender registration rules, scheduling semantics, and the underlying REST call. An agent has everything needed to call it safely and correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description adds real value by explaining billing/segmentation for message (160 vs 153, unicode 70/67), the registered-originator requirement, and that a past time_scheduled sends immediately. Only the confirm parameter's contract is left 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 and resource (sends real SMS to 1-25 numbers) with explicit warning that it spends credits and is irreversible. It also names the sibling cancel_campaign as the alternative for scheduled messages, so an agent can separate this from the campaign-management 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?

Explicit preconditions: 'Only send what the user explicitly asked for; confirm the text, recipients and sender first,' plus the exclusion 'No stored lists, no bulk' and the routing hint to cancel_campaign. This is a clear when/when-not with a named alternative.

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