Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send an SMS, MMS or RCS message

send_message
DestructiveIdempotent

Send approved SMS, MMS, or RCS messages via Vobiz, with idempotency, scheduling, cost preview, and per-recipient delivery tracking.

Instructions

Send a real SMS, MMS or RCS message through Vobiz (POST /api/v1/sms/messages). Each recipient becomes its own message and is billed. Required: from, to, idempotency_key, and confirm: true after the user approved the exact sender, recipients and text. For sms/mms, from is one of your Vobiz messaging numbers (see list_messaging_numbers); for rcs it is your RCS sender name. Use preview_message_cost first to show the price and segment count. Opted-out recipients are refused by Vobiz (opted_out). status scheduled = held until scheduled_at; sent = handed to the network; delivery receipts update it to delivered or failed (check get_message). Repeating an idempotency_key never sends twice.

Input Schema

NameRequiredDescriptionDefault
toYesRecipient numbers in E.164, e.g. ['+14155550123']. Capped by VOBIZ_MAX_RECIPIENTS_PER_SEND.
tagNoYour label, stored on every message; filter list_messages by it.
fromYesSender: an E.164 Vobiz messaging number (sms/mms), or your RCS sender name (rcs).
textNoMessage body. Required for sms and rcs. Long SMS are split into billed segments.
titleNoMMS subject line.
channelNosms (default), mms or rcs.
confirmYesMust be true, set only after the user explicitly approved this send. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved.
media_urlsNoPublic https media URLs (MMS up to 10; RCS sends the first).
scheduled_atNoSend later at this RFC 3339 time, e.g. 2026-11-01T09:00:00Z.
dlt_entity_idNoIndia TRAI DLT Principal Entity ID.
dlt_header_idNoIndia TRAI DLT sender header ID.
dlt_template_idNoIndia TRAI DLT content template ID; text must match it.
failover_to_smsNoRCS only: send the text as SMS if RCS cannot be delivered.
idempotency_keyYesUnique key for this intended operation (e.g. a UUID). Repeating it replays the first result instead of acting again.

Output Schema

NameRequiredDescriptionDefault
okNoTrue only when every recipient was handed to the network; false when any recipient was not sent, or when the result is an error.
noteNoWhat the statuses mean and what to do next.
messagesNoOne entry per recipient, in the order given: id, to, status (scheduled, sent, not_sent, unknown), errorCode and errorMessage when not sent.
sent_countNoRecipients whose message was accepted (status scheduled or sent).
http_statusesNoHTTP status Vobiz returned for each accepted recipient.
not_sent_countNoRecipients refused or failed; see their errorCode (e.g. opted_out).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true, set only after the user explicitly approved this send."New value: +"Must be true, set only after the user explicitly approved this send. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved."
    • addedInput schema / properties / to / items / description
      Added value: +"Phone number in E.164 form, e.g. +919876543210 (country code, digits only, leading + optional)."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "http_statuses": {
+      "description": "HTTP status Vobiz returned for each accepted recipient.",
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "messages": {
+      "description": "One entry per recipient, in the order given: id, to, status (scheduled, sent, not_sent, unknown), errorCode and errorMessage when not sent.",
+      "items": {},
+      "type": "array"
+    },
+    "not_sent_count": {
+      "description": "Recipients refused or failed; see their errorCode (e.g. opted_out).",
+      "type": "number"
+    },
+    "note": {
+      "description": "What the statuses mean and what to do next.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True only when every recipient was handed to the network; false when any recipient was not sent, or when the result is an error.",
+      "type": "boolean"
+    },
+    "sent_count": {
+      "description": "Recipients whose message was accepted (status scheduled or sent).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: per-recipient billing, the scheduled/sent/delivered/failed status lifecycle, opt-out refusal, and the fact that repeating an idempotency_key replays rather than re-sends. It could go further on rate limits or what a partial multi-recipient failure looks like.

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

Conciseness4/5

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

Dense but well ordered: the operation and its payoff, then prerequisites, then workflow guidance, then status/idempotency semantics. Nothing is filler, though the middle section packs several clauses into long sentences, which slightly hurts scannability for a 14-parameter tool.

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

Completeness5/5

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

An output schema exists, so return values need not be enumerated, yet the description still explains how status transitions work and which sibling to consult for receipts. Combined with the explicit prerequisites for a destructive, billable, open-world send, an agent has everything needed to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3 and the schema does the heavy lifting on formats and patterns. The description nonetheless adds cross-parameter workflow semantics the schema cannot express: which four fields are required, that `confirm` must reflect explicit user approval, and that `from` means a messaging number for sms/mms versus an RCS sender name for rcs.

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

Purpose5/5

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

States a specific verb (send) plus the three concrete channels (SMS, MMS, RCS) and names the backing endpoint. It clearly separates itself from neighbouring read tools like list_messages/get_message and from broadcast tooling by being a single-send operation where 'each recipient becomes its own message and is billed'.

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

Usage Guidelines5/5

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

Explicitly routes the agent: call preview_message_cost first to show price/segments, use list_messaging_numbers to resolve a valid `from`, and get_message to check delivery receipts. It also states the gating condition for sending (confirm: true only after the user approved the exact sender, recipients and text) and the refusal case (opted-out recipients).

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

Deploy Server

Other Tools