Read Voodoo SMS credits, reports, inbox and lists; send one SMS; manage the opt-out blacklist.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Each tool targets a distinct resource and action: sending, scheduling, cancellation, contacts, blacklist, credits, delivery reports, inbox, and numbers. The only near-overlap is get_contact_list versus list_contact_lists, but the descriptions clearly differentiate single-list-with-contacts from all-lists-without-contacts.
All tools use the same voodoosms_ prefix followed by snake_case verb_noun naming (create_contact_list, list_delivery_reports, send_sms, etc.). The one minor variation, add_to_blacklist, is still a readable verb phrase in the same convention.
With 13 tools, the set is well-scoped for an SMS API covering messaging, scheduling, contacts, reporting, and account resources. Each tool earns its place without redundancy or excessive fragmentation.
Core SMS lifecycle is covered: send, schedule, cancel, track delivery, receive, manage contacts, blacklist, and credits. Minor gaps exist, most notably no delete operation for contact lists and no tool to purchase or release Virtual Mobile Numbers, but agents can work around these limitations.
WRITE: adds one number to the account's opt-out blacklist; from then on no SMS is sent to it (sends to it fail with error 20). Use it for a recipient who asked to stop. This tool cannot remove a number again. Voodoo SMS REST: POST /blacklist.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Phone number in international format with the country code and no leading 0, e.g. 447700900123. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true; the description adds the crucial consequences: the operation is permanent ('cannot remove a number again'), future sends are blocked, and blocked sends return error 20. This is exactly the beyond-annotation behavioral context a mutation tool needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'WRITE:' to signal the operation class, then effect, then usage, then irreversibility, then the underlying REST endpoint. Every clause carries information; 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?
One required parameter, no output schema, and a description that covers the write semantics, irreversibility, and the failure mode. Nothing an agent needs to call this safely 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% and the single parameter already documents the international-format requirement with an example. The description only implicitly reinforces that one number is added per call, adding little beyond the schema. 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?
States a specific verb and resource ('adds one number to the account's opt-out blacklist') plus the concrete downstream effect (no SMS sent, sends fail with error 20). An agent can distinguish this from voodoosms_list_blacklist and the contact-list tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: 'Use it for a recipient who asked to stop.' That is clear when-to-use guidance. It does not name an alternative for the opposite need (viewing the blacklist via voodoosms_list_blacklist) or state any prerequisites, so it stops short of the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: cancels one SMS that was scheduled through the send API, so it will not be sent. A message that has already gone out cannot be cancelled. Whether credits are refunded for a cancelled message is not documented by the vendor. Voodoo SMS REST: DELETE /schedule/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The scheduled message id (id from list_scheduled_messages). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry destructiveHint=true, so the description adds real value: it says what is destroyed (the pending send), states the irreversibility boundary for already-sent messages, and honestly flags that credit refund behavior is undocumented rather than guessing. It omits auth requirements and error behavior for an invalid id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the write nature and effect; each sentence carries distinct information (action, limitation, refund caveat, endpoint) with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with no output schema, the description covers effect, constraint, and undocumented side effect (refunds), which is sufficient to call it correctly. Only error/idempotency behavior is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents that the id comes from list_scheduled_messages. The description adds no syntax, format, or edge-case detail beyond that, 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?
Names a specific verb (cancels) and resource (one SMS scheduled through the send API) and states the effect (it will not be sent). It is clearly distinguishable from siblings like list_scheduled_messages and send_sms without opening any 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?
Explicitly states the precondition and the exclusion: the message must have been scheduled, and one that has already gone out cannot be cancelled. It does not name a specific alternative tool for the already-sent case, but the when/when-not boundary is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: creates a new contact list with up to 500 contacts (the list name must be unique, at most 32 characters). It does not send anything. Voodoo SMS REST: POST /contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique list name, at most 32 characters. | |
| country | No | Default country calling code for the list (default 44). | |
| contacts | Yes | Contacts to put in the list: [{number, dynamic_data?}]. | |
| description | No | Optional description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only destructiveHint=true, so the description carries most of the burden and does add real context: the 500-contact cap, the uniqueness requirement on name, and the side-effect clarification that nothing is sent. It stops short of stating what happens on a duplicate name (error vs overwrite) or whether the call is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the operation class and key constraints, with no filler. The REST endpoint clause is useful for API-literate agents but is the least essential 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 4-parameter write tool with full schema coverage, no output schema, and minimal annotations, the description covers operation class, key constraints, and the no-send side effect. The main remaining gap is error/duplicate-name behavior, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents name, country, contacts, and description fully. The description's extra details (500 contacts, unique name ≤32 chars) largely restate schema constraints, 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 ('creates a new contact list') and labels the operation class ('WRITE'), which cleanly separates it from the sibling 'update_contact_list', 'get_contact_list', and 'list_contact_lists'. The POST /contacts endpoint mapping further pins down the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the WRITE label tells the agent this is the creation path, and 'It does not send anything' implicitly redirects messaging intent to send_sms. No explicit when-to-use/when-not conditions or named alternatives (e.g. update_contact_list for existing lists) are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one contact list including its contacts (id, number, status, dynamic_data, created_at). Voodoo SMS REST: GET /contacts?contact_list_id=.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Where to start the returned results (default 0). | |
| limit | No | Number of contacts to return (default 100, max 5000). | |
| contact_list_id | Yes | The contact list id (id from list_contact_lists). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds value by disclosing the returned field set and the underlying REST path, but says nothing about pagination defaults or response shape beyond that, which is the main behavioral gap for a list-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the outcome and followed by the REST mapping. The trailing '=' in the endpoint string is slightly sloppy but costs nothing in comprehension.
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, three-parameter tool with full schema coverage and no output schema, the description compensates well by naming the returned fields. Only pagination behavior is left unstated, which the schema largely covers via skip/limit.
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 skip, limit, and contact_list_id are all documented in the schema with defaults and maxima. The description only restates the endpoint and the id parameter, adding nothing beyond the schema; 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?
States a specific verb ('Get') and resource ('one contact list including its contacts') and enumerates the returned fields, so the agent knows exactly what comes back. It doesn't explicitly contrast itself with voodoosms_list_contact_lists, but the singular 'one contact list' implies the distinction.
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: fetch a single list's contacts by id, with the id sourced from list_contact_lists. There is no explicit when-to-use/when-not statement or named alternative, so an agent must infer the routing from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the SMS credit balance of the account. One credit pays for one 160-character SMS part (153 characters per part in a long message). Voodoo SMS REST: GET /credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 genuinely useful domain context beyond that: a credit pays for one 160-character SMS part, and 153 characters per part in a concatenated message, which is what lets an agent interpret the returned number correctly.
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: purpose first, then the credit-unit semantics, then the endpoint hint. Nothing redundant, nothing 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?
For a zero-parameter read with no output schema, the description supplies the one thing an agent needs to make sense of the result — the credit-to-SMS-part conversion. It stops short of describing the response shape, but the domain semantics effectively cover the interpretation gap that an output schema would otherwise fill.
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 per the baseline there is nothing for the description to disambiguate. The description correctly documents its argument-free nature in the same breath.
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 SMS credit balance of the account') and even names the underlying endpoint. It is trivially distinguishable from every sibling, all of which list, send, cancel, or mutate other resources.
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: an agent can infer this is the balance check to run before sending SMS, but the description never says when to call it, whether it needs to be called before voodoosms_send_sms, or that there is no alternative tool for this data. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the numbers on the account's opt-out blacklist (no SMS is ever sent to them), or look up one number ({empty: true} means it is not on the list). Returns an empty result when the blacklist is empty. Voodoo SMS REST: GET /blacklist.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Newest date a number was added. | |
| skip | No | Where to start the returned results (default 0). | |
| sort | No | Sort by id, ASC or DESC (default DESC). | |
| limit | No | Number of entries to return (default 25, max 1000). | |
| start | No | Oldest date a number was added. | |
| number | No | Look up a single number (international format, e.g. 447700900123). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering safety, the description adds semantic context the annotations cannot: that listed numbers are opt-outs that never receive SMS, that a single-number lookup returning `{empty: true}` means the number is not blacklisted, and that no matches yields an empty result. It does not discuss pagination defaults 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?
Three compact sentences, front-loaded with the primary bulk-list behavior before the lookup variant. The trailing REST endpoint note is useful provenance, though 'Returns an empty result when the blacklist is empty' is mildly redundant with the empty-result behavior already implied.
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, 6-parameter list tool with no output schema and full schema coverage, the description supplies the missing semantic layer: what the blacklist means and how to interpret the single-number response. Only return-shape details for the paged list mode are left unaddressed, which is minor given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the paging/sort/date parameters are already documented and the baseline is 3. The description still earns above baseline by explaining the semantic outcome of the `number` lookup param (`{empty: true}` means not on the list), which the schema's one-line description does not convey.
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 numbers on the account's opt-out blacklist') and immediately clarifies what membership means (no SMS is ever sent to them), so an agent understands the tool's scope without opening the schema. It also distinguishes the bulk-list mode from the single-number lookup mode, separating it from the add_to_blacklist sibling.
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 'or look up one number' clause tells the agent the alternate mode and the condition that triggers it, which is real routing guidance. It stops short of explicitly contrasting against siblings like add_to_blacklist or warning about when not to use pagination params.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's contact lists (id, name, status, size, created/updated times) without their contacts. Returns an empty result if there are none. Voodoo SMS REST: GET /contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Where to start the returned results (default 0). | |
| limit | No | Number of lists to return (default 100, max 5000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds useful return-shape context: it lists returned fields, explains that contacts are excluded, notes that an empty result is returned when there are none, and names the REST endpoint, which is meaningful beyond the 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 definition is front-loaded and compact: the core purpose and return shape come first, followed by a useful empty-result note and the REST endpoint. It is appropriately sized, though the endpoint line is slightly less essential for tool selection than the rest.
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 adequately explains the returned fields and the empty-result behavior. Pagination is covered by the fully documented skip and limit parameters, and the read-only nature is covered by annotations, so nothing needed 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 skip and limit are already fully documented in the input schema. The description adds no parameter-specific meaning or format details beyond what the schema provides, making the baseline 3 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 uses the specific verb 'List' with the resource 'contact lists' and enumerates the returned fields (id, name, status, size, created/updated times). The phrase 'without their contacts' clearly distinguishes it from get_contact_list, which would retrieve a single list with its contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by contrasting this summary list with fuller contact retrieval, but it does not explicitly state when to use this tool versus get_contact_list, create_contact_list, or update_contact_list. No exclusions or conditions are named, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List delivery reports of sent messages (message_id, sender_id, to, sent_at, delivered_at, price, status), optionally filtered. Use it to check whether a message was delivered. Dates accept a UNIX timestamp, ISO 8601 (2026-10-01T09:00:00+00:00) or plain English ('yesterday', '2 weeks'). Voodoo SMS REST: GET /report.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only messages sent to this number (international format, e.g. 447700900123). | |
| end | No | End of the date range to filter on. | |
| limit | No | Number of reports to return (default 25, max 1000). | |
| start | No | Start of the date range to filter on. | |
| status | No | Only messages with this status. | |
| sent_at | No | Only messages sent at this date/time. | |
| sender_id | No | The sender id the messages were sent with. | |
| message_id | No | The messages[].id returned when the SMS was sent. | |
| delivered_at | No | Only messages delivered at this date/time. | |
| external_reference | No | The external_reference used when sending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint, so the description does usefully add that start/end/sent_at/delivered_at accept UNIX timestamps, ISO 8601, or plain English - a non-obvious behavior documented nowhere in the schema. However, it says nothing about result ordering, auth requirements, rate limits, or how pagination behaves across a large report set, so this is added context rather than rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then use case, then date syntax, then the REST mapping - a sensible ordering with little waste. The parenthetical list of seven returned fields is slightly run-on but earns its place given there is no output 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 read-only, 10-parameter filter tool with no output schema, the description covers purpose, use case, date filter semantics, and the returned field set. The remaining omissions (ordering, pagination behavior) are secondary and the schema carries the per-parameter limits.
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 already 100%, so the baseline is 3, but the description goes further by explaining the accepted date formats for the four date-ish filters, which the schema descriptions ("Start of the date range to filter on.") omit entirely. That is meaningful supplemental guidance for the trickiest 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?
"List delivery reports of sent messages" gives a specific verb + resource, and the parenthetical field enumeration plus "GET /report" pins down exactly what data comes back. It implicitly but clearly separates itself from siblings like list_inbox (inbound) and list_scheduled_messages (future sends).
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?
"Use it to check whether a message was delivered" supplies an explicit context of use, which is more than most siblings offer. It stops short of naming alternatives or stating when NOT to use it (e.g. for inbound messages, use list_inbox), so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SMS received on the account's Virtual Mobile Numbers (replies and keyword messages). Needs a purchased number; an empty inbox returns an empty result. Dates accept a UNIX timestamp, ISO 8601 or plain English. Voodoo SMS REST: GET /inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | The number the message was sent to: your virtual number (international format). | |
| end | No | Newest date of the messages to return. | |
| from | No | The number the message came from (international format). | |
| skip | No | Where to start the returned results (default 0). | |
| sort | No | Sort by id, ASC or DESC (default DESC). | |
| limit | No | Number of messages to return (default 25, max 1000). | |
| start | No | Oldest date of the messages to return. | |
| keyword | No | The keyword (first word of the message). | |
| reference | No | The external_reference of the original outgoing message. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering safety, the description still adds useful behavior beyond annotations: the purchased-number prerequisite and the empty-inbox semantics. It doesn't discuss pagination limits or how large result sets behave, which is a minor gap for a 9-parameter list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, tightly front-loaded with the core purpose before prerequisites and format details. Every sentence carries information the agent needs and none restates 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 read-only, nine-parameter list tool with no output schema, it covers purpose, prerequisites, empty results, and date parsing. Pagination and sorting defaults are left entirely to the schema, so it is complete enough but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description goes further by disclosing accepted date formats ('UNIX timestamp, ISO 8601 or plain English') for start/end, which the schema only constrains by length and does not explain. That is genuine added meaning over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List SMS received on the account's Virtual Mobile Numbers') and clarifies the scope as replies and keyword messages, which cleanly separates it from sibling list tools like list_delivery_reports and list_scheduled_messages. The endpoint mapping reinforces the intent.
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 a clear precondition ('Needs a purchased number') and a result expectation ('an empty inbox returns an empty result'), which tells the agent when this tool is meaningful. It stops short of naming when to prefer an alternative sibling, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Virtual Mobile Numbers (VMNs) the account has purchased, used to receive SMS. Returns an empty result if there are none. Voodoo SMS REST: GET /numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: it states an empty result is returned when no numbers exist, which helps the agent interpret output, though it omits pagination or ordering details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core purpose front-loaded. The trailing 'Voodoo SMS REST: GET /numbers' is somewhat redundant developer metadata but is compact and not distracting.
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 parameters, no output schema, and annotations covering the read-only safety profile, the description provides enough context to call the tool and interpret an empty response. Minor gaps like result ordering or volume limits are low-impact here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds nothing about parameters because none exist, and it does not need to.
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 Virtual Mobile Numbers'), defines the acronym, and explains their purpose ('used to receive SMS'). An agent can distinguish this from sibling list tools such as list_inbox or list_blacklist by the resource alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (checking purchased numbers) but gives no explicit when-to-use, prerequisites, or alternatives. For a simple zero-parameter list tool this is adequate but leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SMS that were scheduled through the send API and are still waiting to go out (messages scheduled in the portal's Web SMS are not shown). Voodoo SMS REST: GET /schedule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely non-obvious behavioral context beyond the annotations: the list is filtered to still-pending items and excludes messages scheduled through the portal UI. It omits pagination and ordering behavior, which keeps 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 sentences, front-loaded with the scope and the exclusion caveat, plus the backing REST endpoint. No filler and nothing 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 zero-parameter read-only list tool, the description covers scope, filter semantics, and the underlying endpoint. With no output schema, it could have said a word about the shape of the returned list (e.g. recipient, scheduled time), but the omission is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description adds no parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List SMS ... scheduled through the send API and are still waiting to go out') and pins the exact scope by excluding portal-created messages. An agent can tell instantly that this is the pending-scheduled-message lister, distinct from voodoosms_list_inbox or voodoosms_list_delivery_reports.
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 selection context: use it for messages scheduled via the send API, and it explicitly notes that portal Web SMS schedules are not returned. It does not, however, point to a related sibling such as voodoosms_cancel_scheduled_message as a follow-up action, so routing is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: SENDS A REAL SMS to ONE recipient and USES THE ACCOUNT'S CREDITS (1 credit per message part, charged whether or not it is delivered; it cannot be undone). sandbox is required: true validates and prices the message without sending or charging, false sends it for real. Optional schedule queues it for later (cancel with cancel_scheduled_message). Do not retry after an error or timeout without checking list_delivery_reports / list_scheduled_messages, or the recipient may get it twice. One recipient per call; there is no bulk or list send. Voodoo SMS REST: POST /sendsms.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ONE recipient number: international format with the country code and no leading 0 (447700900123), or a national number if country_code is given. | |
| msg | Yes | The message text. 160 characters per part (153 in a long message), 70 (67) if it has emoji or other non-GSM characters; maximum 918 (402 with Unicode). | |
| from | Yes | Sender id shown to the recipient: 4 to 11 letters/digits or a number of up to 15 digits. | |
| sandbox | Yes | REQUIRED. true = validate and price the message only: nothing is sent and no credits are used. false = really send the SMS and use credits. Use true first unless the user clearly asked to send now. | |
| schedule | No | Send later: a UNIX timestamp, ISO 8601 (2026-12-25T09:00:00+00:00) or plain English ('2 weeks'). Must be in the future. | |
| timezone | No | Timezone for `schedule` (default UTC). | |
| country_code | No | Country calling code of the recipient (e.g. 44), when `to` has no country code. | |
| external_reference | No | Your own reference for this SMS (e.g. an order number); shown in reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructiveHint=true, but the description adds substantial behavioral context: real SMS is sent, credits are consumed per message part whether delivered or not, the action cannot be undone, sandbox mode validates and prices without charging, and retries risk duplicate delivery. This aligns with and enriches the destructive hint rather than contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the critical WRITE/real-SMS/credit warning, then covers sandbox, scheduling, retry safety, and recipient limits in compact sentences. Every clause carries actionable information 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?
Given eight parameters, minimal annotations, and no output schema, the description supplies the missing safety, cost, sandbox, scheduling, duplicate-prevention, and scope information needed to invoke the tool correctly. Return values are not required to be explained because no output schema exists and the description points to delivery-report tools for verification.
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 eight parameters, establishing a baseline of 3. The description adds operational meaning beyond the schema by clarifying that sandbox is required and should default to validation mode, and that schedule queues rather than sends, which is useful cross-parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (sends a real SMS to ONE recipient) and distinguishes itself from siblings by explicitly excluding bulk/list sends and naming cancel_scheduled_message and the delivery-report 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?
Provides explicit when-to-use guidance: use sandbox=true first unless the user clearly asked to send now, use schedule for later sends, cancel via cancel_scheduled_message, and do not retry on error without checking list_delivery_reports / list_scheduled_messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: renames a contact list and/or adds up to 500 contacts to it (existing contacts are not removed). Adding dynamic data needs a list created as dynamic. It does not send anything. Voodoo SMS REST: PUT /contacts/{contact_list_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New list name, at most 32 characters. | |
| contacts | No | Contacts to add: [{number, dynamic_data?}]. | |
| contact_list_id | Yes | The contact list id (id from list_contact_lists). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true; the description adds real context beyond that — 'existing contacts are not removed' scopes the destructive risk, 'WRITE' flags mutation, and the dynamic-list prerequisite is a behavioral requirement not visible in the schema. It stops short of describing auth needs or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight clauses, front-loaded with the WRITE marker and the operation, then prerequisites, then side-effect clarification. Nothing is redundant and the endpoint reference is compact.
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 return-value burden, but for a PUT mutation that's minor. It covers side effects, limits, prerequisites, and endpoint; only the response shape and permission requirements 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 each parameter is fully documented in the schema, so the baseline is 3. The description's '500 contacts' cap and dynamic_data prerequisite largely restate what maxItems and the nested schema already convey.
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 ('renames a contact list and/or adds up to 500 contacts to it') and immediately disambiguates from siblings like create_contact_list, list_contact_lists, and send_sms. An agent can tell what the tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: 'Adding dynamic data needs a list created as dynamic' is a prerequisite, and 'It does not send anything' rules out the send_sms sibling. However, it never explicitly contrasts with create_contact_list or get_contact_list, so exclusions are 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
voodoosms_add_to_blacklistvoodoosms_cancel_scheduled_messagevoodoosms_create_contact_listvoodoosms_get_contact_listvoodoosms_get_creditsvoodoosms_list_blacklistvoodoosms_list_contact_listsvoodoosms_list_delivery_reportsvoodoosms_list_inboxvoodoosms_list_numbersvoodoosms_list_scheduled_messagesvoodoosms_send_smsvoodoosms_update_contact_listRead FireText credit, messages and reports; send an SMS to up to 10 numbers; manage opt-outs.
Read D7 Networks balance, SMS pricing and delivery status; look up numbers; send one SMS.
Read smsmode balance, messages, replies, campaigns and usage; send SMS to up to 10 numbers.
Read BulkSMS messages, replies, profile and webhooks; send SMS to up to 10 numbers.
Add one secure layer between your agents and this server.
