Skip to main content
Glama
Sign In

Spur

by com.usespur
OverviewDiscussionsAdmin

Buy phone number

spur_buy_phone_number
Destructive

Buy a local number for the user's account (it's theirs immediately and replies land in their SMS inbox). It can't send texts until their carrier registration is approved. Plans include some numbers; beyond that each costs $5/mo from the Spur wallet, first month charged now (spur_get_texting_setup shows the user's price). Tell the user the price and get explicit approval for this exact number first.

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": {
      "phone_number": "<phone_number>",
      "confirm": "<confirm>"
    },
    "name": "spur_buy_phone_number"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionNoState from the search result, for display
confirmYesSet to true ONLY after the user explicitly approved this exact action in the conversation. Never assume approval.
localityNoCity from the search result, for display
phone_numberYesphone_number from spur_search_phone_numbers

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key behavioral consequences: immediate ownership, inbound SMS but no outbound texting until carrier registration is approved, plan-included versus paid numbers, a $5/mo charge, and first-month billing now. The approval requirement is also reinforced, which is important for a destructive purchase action.

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 description is compact and front-loaded: it states the action, then the immediate consequence, then the limitation, then pricing and approval requirements. Every sentence carries operational or safety-relevant information.

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 destructive purchase tool with no output schema, the description covers what happens on success, the cost model, the carrier-registration limitation, and the required user approval. It also points to the pricing source, so an agent has enough context 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 schema already defines all four parameters. The description adds useful context by emphasizing that approval must be for this exact number and that the price should be confirmed, which strengthens the confirm parameter's meaning beyond the schema 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?

The description gives a specific verb and resource: buy a local phone number for the user's account. It also states the immediate outcome (number is theirs, replies go to their SMS inbox), which distinguishes this from search, release, or default-number management tools.

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?

It clearly sets the context for use, including the need to tell the user the price and get explicit approval before buying. It references spur_get_texting_setup for pricing, but it does not explicitly mention when not to use it or name alternatives such as spur_search_phone_numbers or spur_release_phone_number.

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

All Spur toolsInspect
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