Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Preview message cost

preview_message_cost
Read-only

Calculate SMS/MMS cost before sending: get segment count, unit price, total cost, and destination country without sending the message or incurring charges.

Instructions

Price one message before sending (GET /api/v1/sms/messages/cost-preview): segment count, unit cost, total cost, currency and destination country for a sender, recipient and text. Sends nothing and is not billed. Use it before send_message to show the user the price; the real charge is per recipient and per segment, so multiply by the number of recipients. RCS cannot be previewed.

Input Schema

NameRequiredDescriptionDefault
toYesRecipient, E.164; its country decides the unit price.
fromYesYour Vobiz messaging number, E.164 (see list_messaging_numbers).
textNoMessage body; its length and characters decide the segment count.
channelNoChannel to price: sms (default) or mms.

Output Schema

NameRequiredDescriptionDefault
okNoTrue on success; false when the result is an error (then error, message and retryable are set).
previewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.4.2
    • changedInput schema / properties / channel / description
      Previous value: -"sms (default) or mms."New value: +"Channel to price: sms (default) or mms."
    • changedInput schema / properties / from / description
      Previous value: -"Your Vobiz messaging number, E.164."New value: +"Your Vobiz messaging number, E.164 (see list_messaging_numbers)."
    • changedInput schema / properties / text / description
      Previous value: -"Message body; its length decides the segment count."New value: +"Message body; its length and characters decide the segment count."
    • changedInput schema / properties / to / description
      Previous value: -"Recipient, E.164."New value: +"Recipient, E.164; its country decides the unit price."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "ok": {
+      "description": "True on success; false when the result is an error (then error, message and retryable are set).",
+      "type": "boolean"
+    },
+    "preview": {
+      "additionalProperties": {},
+      "properties": {
+        "channel": {
+          "description": "Channel that was priced.",
+          "type": "string"
+        },
+        "country": {
+          "description": "Destination country derived from the recipient number.",
+          "type": "string"
+        },
+        "currency": {
+          "description": "ISO currency of the prices.",
+          "type": "string"
+        },
+        "segmentCount": {
+          "description": "Billable segments the text splits into.",
+          "type": "number"
+        },
+        "totalCost": {
+          "description": "unitCost multiplied by segmentCount, for this one recipient.",
+          "type": "number"
+        },
+        "unitCost": {
+          "description": "Price of one segment.",
+          "type": "number"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substance beyond that: it confirms 'Sends nothing and is not billed' and surfaces the billing model (per recipient and per segment) plus the RCS limitation, which annotations do not capture.

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 front-loaded: verb and endpoint first, then return fields, then usage. Every clause carries information, though the sentence runs long and could be trimmed without loss.

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?

With an output schema present, returns need not be re-explained, and annotations carry the safety profile. The description still supplies the pricing model, prerequisites (sender/recipient/text), the RCS gap, and the send_message relationship, leaving nothing an agent needs to call 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, but the description adds real meaning by explaining the pricing logic behind the parameters (recipient country decides unit price, text length decides segments, cost must be multiplied by recipient count). That interpretation goes beyond the schema's per-field text.

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 and resource (price/preview one message's cost), enumerates exactly what is returned (segment count, unit cost, total cost, currency, destination country), and distinguishes itself from send_message by being explicitly non-sending. An agent can separate it from all messaging siblings immediately.

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?

'Use it before send_message to show the user the price' gives explicit timing and names the complementary sibling. The exclusion 'RCS cannot be previewed' and the note that charges multiply by recipient count cover when-not and edge cases.

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