KaiCalls

Get Activation Status

get_activation_status

Read-onlyIdempotent

Read current call readiness and persisted private-test proof for one accessible business. Only a currently entitled owner with a coherent assigned number gets the existing private-test setup link. Missing entitlement, incomplete setup or stale sessions do not authorize a call. It cannot assert or advance proof. A completed private test is separate from customer-route coverage; forwarding is optional and does not define whether the assigned phone works.

Input Schema

TableJSON Schema

Name	Required	Description
`business_id`	No	Business ID (optional only when the token reaches exactly one business).
`oauth_transaction_id`	No	Opaque OAuth transaction identifier used only to bind a completed receipt.
`activation_session_id`	No	Optional exact session ID. A superseded or foreign session is rejected.
`origin_conversation_id`	No	Opaque client conversation identifier used only to bind a completed receipt.
`receipt_idempotency_key`	No	Client key for replay-safe delivery of a completed activation receipt.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when success is false
`proof`	No
`state`	No
`routes`	No
`success`	Yes	Whether the tool completed successfully
`business_id`	No
`next_action`	No
`call_readiness`	No
`activation_receipt`	No
`owner_phone_on_file`	No	Whether the owner's own mobile number is on file for SMS alerts or ring-first. Its absence does not invalidate an email-confirmed private test or require forwarding.
`activation_session_id`	No
`notification_attempts`	No
`command_center_unlocked`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 13, 2026

addedOutput schema / properties / call_readiness
```
Added value: +{
+  "type": "object"
+}
```

changedOutput schema / properties / owner_phone_on_file / description

Previous value: -"Whether the owner's own mobile number is on file. False means no SMS nudge, ring-first, or forwarding verification can reach a human — the line is not fully set up regardless of proof state."New value: +"Whether the owner's own mobile number is on file for SMS alerts or ring-first. Its absence does not invalidate an email-confirmed private test or require forwarding."

AddedSep 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false. The description goes beyond that by explaining it 'cannot assert or advance proof' and clarifying that a completed private test is separate from customer-route coverage and that forwarding is optional. That added context is valuable, though return shape is left to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Information is front-loaded with the primary purpose in the first sentence, but the paragraph is dense and some sentences (the forwarding/customer-route distinction) are hard to parse and could be tightened.

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?

With complete schema coverage, full annotations, and an output schema, the description covers the key behavioral caveats an agent needs—eligibility, non-advancement of proof, and the optional nature of forwarding. Sufficient, with minor room to clarify return values.

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 description coverage is 100%, so all five parameters are already documented (including business_id optionality and session rejection). The description adds no per-parameter meaning beyond that; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) and resource (current call readiness and persisted private-test proof) scoped to one business. It is clearly a read/status tool distinguishable from setup siblings like set_up_phone_system or get_setup_checklist, though it doesn't name an explicit alternative.

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?

Provides clear context on what qualifies (entitled owner with coherent assigned number, completed private test) and what does not (missing entitlement, incomplete setup, stale sessions). No explicit when-to-use-this-vs-sibling routing, but the eligibility conditions are strong guidance.

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.