Skip to main content
Glama

CallMCP — Phone Call MCP Server

Start Text Registration Checkout

start_text_registration_checkout

Create the payment link for a business's own carrier registration (a one-time filing fee plus a monthly campaign fee). Business owner only, and only once the details and the EIN are saved. An admin who prepared the details gets owner_required with owner_handoff_url: the page the owner opens to type the EIN, review and confirm. Returns checkout_url for the owner to open and pay; nothing is charged by this tool, and filing starts only after payment. A checkout_url means neither payment nor filing. On a plan that includes registration there is nothing to pay: the tool sends it to the carriers straight away and returns included_in_plan and filed true instead of a link, so that path requires confirm_submission true, which records that the owner reviewed and confirmed the saved details and external submission. Submission is not carrier approval. The tool takes no EIN, document contents, credentials or legal attestations.

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": {
      "business_id": "<business_id>",
      "confirm_submission": "<confirm_submission>"
    },
    "name": "start_text_registration_checkout"
  }
}

Input Schema

NameRequiredDescriptionDefault
business_idYes
confirm_submissionYesTrue only after the owner explicitly confirms the saved details and possible immediate carrier submission.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when success is false
filedNo
chargedNo
successYesWhether the tool completed successfully
monthly_usdNo
checkout_urlNo
one_time_usdNo
included_in_planNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=true), the description discloses what is and is not charged, that filing starts only after payment, that a checkout_url implies neither payment nor filing, and that the included_in_plan path files immediately subject to confirm_submission. It also preempts a likely misfire by stating the tool accepts no EIN, documents, credentials or legal attestations, and clarifies that submission is not carrier approval.

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?

Purpose and preconditions are front-loaded and nearly every sentence carries a distinct fact (fees, roles, handoff URL, no-charge semantics, alternate plan path). The included_in_plan branch arrives late and the short declaratives ("A checkout_url means neither payment nor filing.", "Submission is not carrier approval.") interrupt the flow of what is otherwise a dense but well-earned paragraph.

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 branching, multi-outcome tool with an output schema already documenting return fields, the description covers roles, prerequisites, both outcome paths, the required flag on the immediate-filing path, and monetary side effects. The only unaddressed trait is repeat-call behavior, which is minor given the idempotentHint=false annotation.

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 only 50%, so the description must carry weight, and it does for confirm_submission: it explains that the flag records the owner's review of the saved details and possible immediate carrier submission, and that it is required specifically on the included_in_plan path. business_id gains only implicit meaning (the business whose own registration is being filed), with no format or provenance guidance.

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 first sentence names a specific verb and resource: "Create the payment link for a business's own carrier registration," and immediately scopes it to a one-time filing fee plus a monthly campaign fee. It also distinguishes the tool from generic checkout siblings by specifying the 'own' carrier registration and by describing the divergent included_in_plan path that returns no link at all.

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?

Preconditions are explicit and conditional: "Business owner only, and only once the details and the EIN are saved," plus the stated consequence for the wrong actor (owner_required with owner_handoff_url). What is missing is naming the prerequisite siblings (save_text_registration_details, submit_text_registration) directly, so the agent must infer which tool must precede this one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.