Spur

Submit texting registration

spur_submit_texting_registration

Destructive

Send the user's registration to the carriers (also resubmits a rejected one after fixes). Charges the Spur wallet: $29 one-time for low volume / sole proprietor or $79 for standard (includes the first month, then $3 or $15/mo), or $15 to resubmit after a carrier rejection; spur_get_texting_setup shows the exact amount due now. Tell the user the amount. Walk the user through the full details first, and only call after they explicitly approve and personally confirm both statements: they only text people who agreed to receive their messages and honor STOP, and they won't send prohibited content (cannabis, firearms, high-risk loans or debt collection, gambling, sexual content, hate speech).

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": {
      "user_confirms_consent": "<user_confirms_consent>",
      "user_confirms_no_prohibited_content": "<user_confirms_no_prohibited_content>",
      "confirm": "<confirm>"
    },
    "name": "spur_submit_texting_registration"
  }
}

Input Schema

Name	Required	Description
`confirm`	Yes	Set to true ONLY after the user explicitly approved this exact action in the conversation. Never assume approval.
`user_confirms_consent`	Yes	The user confirmed they only text people who agreed to receive their messages and honor STOP requests
`user_confirms_no_prohibited_content`	Yes	The user confirmed they won't send prohibited content

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the destructive/open-world/non-idempotent annotations by disclosing the actual wallet charges ($29, $79, $15 resubmit), the recurring monthly fees, and that the user must be told the amount. It also specifies the exact consent and prohibited-content affirmations the user must give.

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?

Front-loads the action and cost, then the approval gate and confirmation statements. It is dense and somewhat long, but the pricing and prohibited-content list are operationally necessary for the agent to explain before calling.

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?

Covers the financial side effects, the required affirmations, and the pre-call workflow for a destructive mutation with no output schema. It stops short of describing what the call returns or what the likely next step is after submission, such as carrier review or verification.

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. The description adds real meaning by spelling out the two substantive confirmations (consent/STOP compliance and prohibited-content categories) and by framing confirm=true as requiring explicit in-conversation approval, rather than merely repeating the schema.

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: submit the user's texting registration to carriers, with the additional resubmission-after-rejection case spelled out. It also names spur_get_texting_setup as the place to read the exact amount due, which orients the agent against a sibling tool.

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?

Explicitly says to walk the user through the full details first and only call after explicit approval plus personal confirmation of both statements. It also points to spur_get_texting_setup for the exact charge, and warns never to assume approval in the schema, which reinforces the gating.

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

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