SimpleTexting MCP by usefulapi

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

Annotations only declare readOnlyHint=true; the description corroborates that ('Safe and read-only') and adds genuinely new behavior: nothing is sent, and it returns three computed values. It discloses the underlying REST route and payload shape, which helps an agent reason about semantics, though it does not cover failure modes 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?

The lead clause is front-loaded with the dry-run nature and the three computed outputs, which is the highest-value information. The trailing REST endpoint reference is marginally useful for debugging but is the one sentence that does not directly aid tool selection.

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 convey return semantics, and it does so explicitly (segments, SMS/MMS classification, estimated cost). For a 2-parameter read-only tool, nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (text required, mode optional with example values AUTO|SMS|MMS) are already documented. The description restates the payload as {text, mode?} but adds no syntax or constraint detail 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 action (DRY-RUN evaluate) on a specific resource (message body) and enumerates exactly what is computed: segment count, SMS vs MMS, and estimated cost. 'WITHOUT sending anything' immediately separates it from simpletexting_send_message and the get_* 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?

The DRY-RUN framing plus 'WITHOUT sending anything' makes the intended context clear: use this before sending to preview cost/segments. It never names simpletexting_send_message as the alternative or states exclusions, but the contrast is unambiguous from the phrasing.

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?

readOnlyHint=true already covers the safety profile, so the bar is lower; the description still adds value by disclosing the returned content (message, recipients, status). It does not mention auth requirements, pagination, or error behavior for a missing id, keeping it 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 short sentences, front-loaded with purpose and return content, followed by the REST endpoint. No sentence is redundant or padded.

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?

Annotations cover the read-only safety profile and there is no output schema, so the description correctly supplies the return fields and lookup key. It is essentially complete for a single-parameter read tool, though it omits any note on failure behavior for an invalid id.

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 there is only one parameter, already documented as 'Campaign id.' The description restates 'by its id' but adds no format or sourcing detail 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 (get), resource (campaign), and scope (a single campaign by id), and enumerates what it returns (message, recipients, status). The word 'single' plus the id-based lookup cleanly distinguishes it from simpletexting_list_campaigns.

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

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

The id-based lookup implies this is for retrieving one known campaign, which contrasts implicitly with the list sibling. However, it never explicitly names an alternative or states when-not to use it, so usage is inferred 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?

readOnlyHint=true already declares the safe-read profile, so the description's added value is limited to naming the lookup keys and the returned field groups. It omits behavior for a missing/invalid contact (error semantics) and rate limits, leaving the annotation to carry safety.

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; the core ('Get a single contact by id or phone number') is front-loaded, followed by returned fields. The trailing REST endpoint restatement is mildly redundant but harmless.

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 annotations covering safety and no output schema, the description adequately covers what is fetched and what comes back. Only error/not-found 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 coverage is 100%, so the schema already documents the single 'contact' parameter as 'Contact id or phone number.' The description repeats this without adding format, validation, or fallback detail, 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 ('Get') and resource ('a single contact') with lookup key ('id or phone number') and enumerates returned content (profile fields, list memberships, custom fields). It distinguishes itself from list_contacts only implicitly via 'single,' without naming the alternative.

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 word 'single' implies use when fetching one known contact versus the sibling list_contacts, but there is no explicit when-to-use, when-not, or named alternative. 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?

readOnlyHint=true already covers the safety profile, and the description adds value beyond that by disclosing the return payload ('its URL and metadata') and mapping the call to the underlying REST operation GET /media/{id}. It does not mention failure modes (missing id, 404) or auth requirements, so it is good but not exhaustive.

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

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

Two short sentences, front-loaded with the action and scope, with the endpoint breadcrumb tacked on last. Nothing is wasted or repeated.

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 no output schema, the description discloses enough about the response (URL plus metadata) and the operation to call it correctly. It could be more complete by noting that the id must come from list_media or message payloads, but nothing critical is missing.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents media_id. The description only restates that lookup is 'by its id' and adds no format, source, or example for what a valid media id looks like.

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 a single media item (MMS asset) by its id') and scopes it to one item, which implicitly separates it from the sibling simpletexting_list_media. It stops short of naming that sibling explicitly, so an agent must infer the split from the word 'single'.

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 you call this when you need the URL/metadata of one already-known asset id, versus listing all media. There is no explicit when-to-use statement, no prerequisite (e.g. media id source), and no named alternative.

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

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

The readOnlyHint annotation covers the safety profile, and the description goes beyond it by enumerating what the response contains (text, direction, status, timestamps) and citing the underlying REST call GET /messages/{id}, which usefully confirms the read semantics and data 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?

Two tight sentences with the core purpose front-loaded and no filler. The REST endpoint reference is mildly redundant for an agent but harmless and short.

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 responsibly lists the return fields (text, direction, status, timestamps), which is the key missing piece of structure. Combined with the readOnly annotation and one fully documented param, an agent has enough to call it correctly; only alternative-routing guidance is absent.

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 required parameter with 100% schema coverage ("Message id."), so the schema already carries the parameter documentation. The description only restates "by its id" and adds no format or sourcing guidance beyond the schema, fitting 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 and resource ("Get a single message by its id") and contrasts implicitly with the plural simpletexting_list_messages sibling by emphasizing "single." It's clear what the tool returns, though it never names a sibling explicitly to route between get and 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: retrieve one message when you have its id. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as simpletexting_list_messages for browsing or simpletexting_evaluate_message for analysis.

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?

readOnlyHint=true already tells the agent this is a safe read, but the description adds a genuinely surprising behavioral trait — only immediate campaigns are returned — plus the paged-collection nature and the underlying REST endpoint. It does not disclose default page size, response shape, or rate limits, so it stops 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 tight sentences with the scope stated first, the caveat second, and an endpoint mapping appended. No sentence is padding; the caveat is appropriately prominent.

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 seven-parameter, fully optional, read-only list tool, the description covers filtering, pagination semantics, and the key content exclusion. With no output schema, it could say slightly more about what each returned record contains or the default page size, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description restates the filter categories (sending number, state, list, date range) without adding format syntax, date formats, or precedence rules, so it earns the baseline 3 rather than more.

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 ('List') and resource ('the account's campaigns') and specifies the scope as a 'paged collection', which reads as the bulk-listing tool. It does not name any sibling tool, so the differentiation from simpletexting_get_campaign is left to be inferred from the plural/resource 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?

It states the available filter dimensions (sending number, state, list, start-date range) and adds an explicit exclusion: scheduled/recurring campaigns are NOT returned. That exclusion functions as useful when-not guidance, but no alternative tool is named for retrieving scheduled/recurring campaigns or a single campaign.

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, so the safe-read profile is covered. The description adds that results come back as a paged collection and can be cursor-filtered, which is genuine context beyond the annotations, but it omits defaults (page size, direction) and any return-shape detail.

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 well-structured sentence front-loads the resource and collection behavior. The trailing 'SimpleTexting REST: GET /contacts' adds marginal value but is short enough not to hurt.

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-param list tool with full schema coverage and readOnly annotations, the description covers purpose, paging, and filters adequately. With no output schema, a brief note on the returned contact shape would have closed the 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%, so the schema already documents page, size, since, and direction. The description only restates that since and direction are optional filters and adds no syntax, format, or default-value information 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) plus the collection shape (paged) and filter dimensions. It distinguishes the tool from get_contact by making clear this returns a collection, 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 resource name (use this to enumerate contacts) but there is no explicit when-to-use versus get_contact, no mention of when filtering is appropriate, and no exclusions. Nothing actively misleads, but the agent must infer the context.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered by structured data. The description adds that results are paged, which is genuine behavioral context, but does not disclose default page size, maximum page size behavior, or ordering.

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 core action, with no filler prose. The trailing 'SimpleTexting REST: GET /media' is largely redundant API traceability rather than actionable information, which keeps it just under 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 zero-required-parameter list tool with no output schema and annotations covering the read-only safety profile, this is nearly sufficient: the agent knows what it retrieves and that results are paged. Only the return shape and pagination defaults 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?

Both parameters are fully documented in the schema (page is zero-based, size is 1-100), so schema coverage is 100% and the baseline is 3. The description adds nothing beyond implying pagination exists, so it does not exceed 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 states a specific verb and resource — 'List the account's media items (MMS assets)' — and adds the collection shape ('as a paged collection'), which an agent can distinguish from the sibling get_media. It stops short of explicitly contrasting itself with get_media, 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?

Usage is only implied: 'as a paged collection' signals browsing, but there is no when-to-use statement, no mention of when to prefer get_media for a single asset, and no prerequisites. Nothing misleading, but nothing explicit 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 readOnlyHint=true, so the safety profile is covered. The description adds useful context that the result is a paged collection spanning inbound and outbound history, but says nothing about rate limits, auth scope, or default/max page behavior beyond that.

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 the core purpose front-loaded; the trailing 'SimpleTexting REST: GET /messages' is mild added integration context rather than filler, but is marginally redundant. Tight overall.

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 list tool with annotated safety, full schema coverage, and no output schema, the description is essentially complete. It does not describe return shape or ordering, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, with both page and size fully documented (zero-based, 1-100). The description adds no further parameter meaning, 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 ('List the account's messages'), scopes the data ('inbound + outbound message history'), and is clearly distinguishable from siblings like get_message (singular) and send_message. The agent can tell what this returns 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 only implied by the plural 'List' verb and the paged-collection framing; the description never states when to use this versus get_message or evaluate_message, nor any preconditions. Adequate but with a clear gap in 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 only supply destructiveHint=true; the description adds meaningful context beyond that: the message is REAL, it MODIFIES live data, and it consumes message credits. That cost/irreversibility angle is genuinely useful. It stops short of stating whether sends can be undone or throttled.

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 highest-stakes fact (real send, modifies data, costs credits). The trailing REST-body enumeration is somewhat redundant with the schema but serves as a quick contract summary; the emphasis caps are justified by the risk.

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

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

For a 7-parameter mutation tool with no output schema and only a destructiveHint annotation, the description supplies the missing risk framing (live data, credit spend). It omits delivery confirmation behavior and rate limits, which are minor given no output schema is defined.

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 baseline is 3. The description restates the body keys (contactPhone, text, accountPhone, mode, subject, fallbackText, mediaItems) but adds no formatting, ordering, or interaction rules beyond what the schema already documents.

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+resource in caps ('SENDS A REAL SMS or MMS to a recipient') and pins down the exact REST operation (POST /messages) with its JSON body. This clearly separates it from read-side siblings like get_message, list_messages, and evaluate_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?

Gives an implicit usage rule ('Provide only the optional fields you need') and warns of real-world cost, which frames when to invoke. However, it never names or contrasts an alternative — notably the sibling evaluate_message, which an agent might prefer for validation — so the when/when-not decision is only partially covered.

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 destructiveHint=true, so the description usefully clarifies the mutation semantics: an existing live contact is modified in place, and unspecified fields are left untouched rather than cleared. It also pins the REST operation (PUT /contacts/{contactIdOrNumber}). It does not cover whether listIds replace or append, nor any rate-limit/auth context.

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

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

Three tight sentences, front-loaded with the mutation warning and the partial-update rule before the API reference. No filler, nothing repeated from the schema fields.

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

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

With no output schema, the description carries the return-value burden, but an update tool's response matters less than its side effects, which are stated. The remaining gap is the ambiguous additive-vs-replacement behavior of listIds and customFields, which neither the description nor the schema resolves.

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 field is self-documenting, so the baseline is 3. The description goes one step further by resolving the key ambiguity of an update call — that omitted fields are not affected — which the schema alone does not convey. It adds no per-parameter syntax detail 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?

Names a specific verb (UPDATES) and resource (a live contact), and enumerates the mutable surfaces: profile fields, list memberships, custom fields. This clearly separates it from the read-side siblings (get_contact, list_contacts) without requiring the schema to be opened.

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 instruction 'Provide only the fields you want to change' establishes partial-update usage, which is real guidance. However, it never states when to reach for this tool versus get_contact/list_contacts, nor any precondition (e.g., the contact must already exist, or whether nonexistent ids create a contact).

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