Sparetext

Fill in a number's verification

submit_number_verification

Fill in (or fix, after a rejection) the toll-free verification Twilio needs before a business number can send. Use only true facts the user gave you about their business; never invent or guess a name, address, EIN or opt-in proof. Ask the user for anything missing (the EIN, a public URL showing how people opt in) before calling. The EIN (businessRegistrationNumber) is required except for a SOLE_PROPRIETOR. Twilio reviews it in a few days; get_number shows the result. Refused for read-only and send-only connections.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "businessName": "<businessName>",
      "website": "<website>",
      "businessType": "<businessType>",
      "address": "<address>",
      "contact": "<contact>",
      "useCase": "<useCase>",
      "useCaseSummary": "<useCaseSummary>",
      "sampleMessage": "<sampleMessage>",
      "optInType": "<optInType>",
      "optInProofUrl": "<optInProofUrl>",
      "monthlyVolume": "<monthlyVolume>"
    },
    "name": "submit_number_verification"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The number's id (num_…) from list_numbers
`address`	Yes	US address
`contact`	Yes	Who Twilio may contact
`useCase`	Yes
`website`	Yes	The business's website, https://…
`optInType`	Yes
`businessName`	Yes
`businessType`	Yes
`monthlyVolume`	Yes	Texts a month, as Twilio's band
`optInProofUrl`	Yes	A public https URL showing how people opt in (a screenshot of the form, a signed page)
`sampleMessage`	Yes	A real example of a text it will send, with an opt-out line
`useCaseSummary`	Yes	What the business texts people about, and why they expect it
`businessRegistrationNumber`	No	The EIN, like 12-3456789. Required unless businessType is SOLE_PROPRIETOR.

Output Schema

Name	Required	Description	Default
`number`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say it is a non-destructive, non-idempotent write with open-world access. The description adds real behavior: Twilio reviews in a few days (asynchronous), the submission is refused on read-only/send-only connections, resubmission is the fix after rejection, and the data must be truthful rather than invented — none of which annotations convey.

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?

Four tight sentences ordered by importance: what it does, the truthfulness constraint, the missing-data procedure, the EIN conditional, then timing and refusal. Every sentence carries actionable information with no filler.

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?

For a 13-parameter, nested-object submission tool with an output schema, the description covers the things schema and annotations cannot: prerequisites, refusal conditions, async review timing, and the no-fabrication rule. Return values are handled by the output schema, so nothing critical is left implicit.

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 coverage is 69% and the description only touches two fields (businessRegistrationNumber, optInProofUrl), and its EIN conditional largely restates the schema's own description. The useful addition is the sourcing instruction — ask the user rather than guessing business name, address, EIN, or opt-in proof — but the remaining 11 parameters get no help.

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?

Opens with a specific verb and resource — filling in (or fixing after rejection) the toll-free verification Twilio requires before a business number can send. This clearly separates it from siblings like request_business_number (new request) and get_number (status read).

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?

States the trigger conditions (before a business number can send, or after a rejection), names conversational prerequisites (ask the user for a missing EIN or opt-in URL first), and routes the agent to get_number for the review result. It also gives explicit exclusions: refused for read-only and send-only connections.

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

All Sparetext tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?