KaiCalls

Save Text Registration Details

save_text_registration_details

Idempotent

Save a business's legal name, entity type, industry, website, address, authorized contact and what it will text (service only, or service and sales) for its own carrier registration. Business owner only. Pass only what the owner told you: anything omitted is filled from what is already on file (see get_text_registration known). Ask one question at a time and save each answer as you go: answers given so far are kept, and while questions remain the result lists saved_steps, missing and the next_question to ask. The owner can finish here or on the registration page. Never takes the EIN: the owner types it on the registration page returned as setup_url. Refused once a filing is already with the carriers. Charges nothing and files nothing.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No
`state`	No
`street`	No	Must match the address the IRS has.
`industry`	No
`text_types`	No	service: replies and follow-ups to people who contacted the business. service_and_sales: also lets sales texts go to people who opted in to marketing.
`business_id`	Yes
`postal_code`	No	5-digit ZIP, or ZIP+4.
`website_url`	No	Carriers check the site loads.
`business_type`	No
`contact_email`	No
`contact_phone`	No	A US number the carriers can reach.
`contact_title`	No	As the contact signs, e.g. Owner.
`contact_last_name`	No
`contact_first_name`	No
`legal_business_name`	No	Exactly as on the IRS EIN letter.
`contact_job_position`	No

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when success is false
`saved`	No
`missing`	No
`success`	Yes	Whether the tool completed successfully
`next_step`	No
`setup_url`	No
`consent_url`	No
`saved_steps`	No
`registration`	No
`next_question`	No
`next_step_text`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 30, 2026
- addedOutput schema / properties / next_question
```
Added value: +{
+  "type": "object"
+}
```
- addedOutput schema / properties / saved_steps
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

Changed3 schema fields changedSep 29, 2026

changedInput schema / required

Previous value: -[
-  "business_id",
-  "legal_business_name",
-  "business_type",
-  "industry",
-  "website_url",
-  "street",
-  "city",
-  "state",
-  "postal_code",
-  "contact_first_name",
-  "contact_last_name",
-  "contact_email",
-  "contact_phone",
-  "contact_job_position",
-  "contact_title"
-]New value: +[
+  "business_id"
+]

addedOutput schema / properties / missing

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / saved
```
Added value: +{
+  "type": "boolean"
+}
```

AddedSep 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) only sketch the safety profile; the description adds substantive behavior: omitted fields are backfilled from on-file data, partial saves are kept and resumable, the result reports saved_steps/missing/next_question, EIN is never accepted, and it charges and files nothing. This is rich context beyond structured fields.

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-loaded with what is saved, then behavior, then constraints and refusal. Every sentence carries information, though the middle section on incremental saving is dense and relies on the reader parsing several clauses about saved_steps/missing/next_question.

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?

An output schema exists and the description references the return fields rather than re-explaining them. For a mutation tool with annotations, ownership restrictions, refusal conditions, idempotent partial-save semantics, and the EIN exclusion are all covered, leaving no material gap for correct invocation.

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 only 44%, so the description must compensate. It names the conceptual field groups (legal name, entity type, industry, website, address, authorized contact, text types) and clarifies the write-only-what-was-told defaulting rule, but it does not add per-field semantics for street/postal/contact_title/contact_job_position beyond what the schema already documents. Adequate but not compensating for the coverage gap.

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 (Save) and resource (text registration details) and enumerates exactly what is captured: legal name, entity type, industry, website, address, authorized contact, and text types. This clearly distinguishes it from siblings like get_text_registration (read), start_text_registration_checkout (payment), and set_up_phone_system.

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 when-to-use guidance: business owner only, pass only what the owner told you, ask one question at a time and save as you go, and the owner may finish here or on the registration page. It also states a refusal condition (once a filing is already with the carriers) and cross-references get_text_registration's `known` field.

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

All KaiCalls 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.