Skip to main content
Glama
Sign In
joltsms-mcp-server

joltsms-mcp-server

by rchanllc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

joltsms_provision_number

Rent a dedicated real-SIM US phone number for inbound SMS and OTP extraction. Handles async provisioning and 3DS payment authorization.

Instructions

Rent the next available dedicated real-SIM US phone number ($50/month).

Optionally pass payment_method_id from joltsms_list_payment_methods. Omit it to use the valid account default or the sole saved card.

Provisioning is async — the number may take seconds to minutes to become ACTIVE. Specific area codes are not currently selectable.

If 3DS authentication is required, this tool returns a URL the user must visit to authorize payment.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "joltsms_provision_number"
  }
}

Input Schema

NameRequiredDescriptionDefault
payment_method_idNoSaved card ID from joltsms_list_payment_methods. Omit to use the valid account default or the sole saved card.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses recurring cost ($50/month), async provisioning with realistic latency ('seconds to minutes to become ACTIVE'), the unavailability of area-code selection, and the 3DS payment-authorization URL flow. It stops short of stating reversibility or what happens on provisioning failure.

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

Conciseness5/5

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

The core action and cost are front-loaded, followed by four short, non-overlapping sentences covering payment, async timing, a known limitation, and the 3DS branch. No sentence is redundant.

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

Completeness4/5

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

For a mutation tool with no annotations and no output schema, the description covers the critical unknowns: billing, latency, area-code limitation, and the 3DS return path. It leaves the normal success payload (e.g., the new number ID/phone number) unspecified, which would help an agent chain into joltsms_get_number.

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

Parameters3/5

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

Schema description coverage is 100% and the single optional parameter is fully documented in the schema. The description restates the same omit/default rule rather than adding new semantics such as format, source, or failure behavior for an invalid ID, so the baseline 3 applies.

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 with full qualification: 'Rent the next available dedicated real-SIM US phone number ($50/month).' This clearly distinguishes it from siblings like joltsms_list_numbers, joltsms_release_number and joltsms_update_number, which operate on numbers the agent already holds.

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

Usage Guidelines4/5

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

Explicitly routes the agent to joltsms_list_payment_methods for the payment_method_id and explains the omit-to-use-default behavior, which is real selection guidance. It does not, however, state when this tool is preferable to alternatives such as joltsms_get_number or joltsms_update_number when the user already has a number.

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