VoidMob MCP

Official

by voidmobcom

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Reuse a verification number

reuse_number

Destructive

Receive another SMS on an earlier verification's number, free or paid, after checking reuse flags and price via get_rental.

Instructions

Receive another SMS on the number of an earlier verification (ver_...). Free reuse: when allow_reuse is true. Paid reuse (paid=true): when allow_paid_reuse is true; charges paid_reuse_price_cents, refunded automatically if the number is no longer available, and requires max_price_cents (that price, shown to and approved by the user). Check both flags and the price with get_rental first, then call get_rental with wait_seconds for the new code.

Input Schema

TableJSON Schema

Name	Required	Description
`paid`	No
`rental_id`	Yes	ver_... id of an earlier verification
`max_price_cents`	No	Required when paid=true: the paid_reuse_price_cents you showed the user and they approved, in US cents. Refused uncharged if the price is higher.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`verification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.2.1Oct 1, 2026

addedInput schema / properties / max_price_cents

Added value: +{
+  "description": "Required when paid=true: the paid_reuse_price_cents you showed the user and they approved, in US cents. Refused uncharged if the price is higher.",
+  "exclusiveMinimum": 0,
+  "maximum": 1000000,
+  "type": "integer"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "verification": {
+      "additionalProperties": {},
+      "properties": {
+        "allow_paid_reuse": {
+          "type": "boolean"
+        },
+        "allow_reuse": {
+          "type": "boolean"
+        },
+        "can_cancel": {
+          "type": "boolean"
+        },
+        "charged_price_cents": {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        "charged_reuse_cents": {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        "code": {
+          "type": "string"
+        },
+        "code_received_at": {
+          "type": "string"
+        },
+        "created_at": {
+          "type": "string"
+        },
+        "display_id": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "expires_at": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "paid_reuse_price_cents": {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        "phone_number": {
+          "type": "string"
+        },
+        "refunded_cents": {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        "reuse_counter": {
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        },
+        "service_id": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "service_name": {
+          "type": "string"
+        },
+        "status": {
+          "enum": [
+            "waiting_for_code",
+            "code_received",
+            "cancelled",
+            "expired",
+            "failed"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "status",
+        "phone_number",
+        "service_id",
+        "service_name",
+        "charged_price_cents",
+        "expires_at",
+        "can_cancel",
+        "created_at",
+        "reuse_counter",
+        "allow_reuse",
+        "allow_paid_reuse",
+        "paid_reuse_price_cents"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "verification"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedv1.1.8Sep 30, 2026
- changedInput schema / properties / rental_id / description
```
Previous value: -"ver_xxx from a verification"New value: +"ver_... id of an earlier verification"
```
- addedInput schema / properties / rental_id / pattern
```
Added value: +"^(?:ver_[A-Za-z0-9_-]{1,64})$"
```
First observedv1.1.3Aug 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds substantive behavior beyond the annotations: billing (paid_reuse_price_cents), automatic refund when the number is unavailable, and the requirement that max_price_cents reflect a user-approved price. It does not restate destructiveHint=false-style facts, and it does not contradict the declared destructive/openWorld profile. It stops short of discussing idempotency or concurrency for a non-idempotent, billable action.

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: the core action comes first, then the free/paid branches, then the required get_rental sequencing. It is a single run-on paragraph with one slightly awkward repeated reference to get_rental, but every clause carries information.

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 billable, destructive operation with an output schema (so return values need no explanation), the description covers cost, refund, approval, flags, and the get_rental prerequisite. Minor gaps: no statement of failure modes beyond price-too-high, and no mention of idempotency in the face of retries.

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?

With schema coverage at 67%, the description compensates well: it ties paid=true to allow_paid_reuse, explains that max_price_cents is a user-approved ceiling, and identifies rental_id as a ver_... id of an earlier verification. It adds conditional logic the schema cannot express, though exact price-lookup syntax remains in get_rental.

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+resource+scope: 'Receive another SMS on the number of an earlier verification (ver_...)'. It is clearly distinguishable from siblings like rent_number (new rental) and get_rental (status check), and it splits the operation into free vs. paid paths up front.

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?

Gives explicit preconditions ('when allow_reuse is true', 'when allow_paid_reuse is true') and an explicit workflow with the sibling tool: 'Check both flags and the price with get_rental first, then call get_rental with wait_seconds for the new code.' No inference required.

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