Proof Holdings

get_add_phone_status

Read-only

Check the status of an in-progress phone addition by session ID. Poll until terminal state.

Before calling this for a challenge you created, make sure your reply text already shows the user what to act on — the link itself, the SMS text and number, or a note to check their inbox; a link that appeared only in a tool result is one they never saw.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), or sign in with start_login — a session opens this tool — then call this tool again.

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": {
      "session_id": "<session_id>"
    },
    "name": "get_add_phone_status"
  }
}

Input Schema

Name	Required	Description	Default
`session_id`	Yes	Add-phone session ID

Output Schema

Name	Required	Description
`status`	Yes
`channel`	Yes
`session_id`	Yes
`verified_at`	No	Present once `status` is `verified`
`phone_number`	No	The number the person proved; absent until they have

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "A phone-add session's state",
+  "properties": {
+    "channel": {
+      "type": "string"
+    },
+    "phone_number": {
+      "description": "The number the person proved; absent until they have",
+      "type": "string"
+    },
+    "session_id": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "verified_at": {
+      "description": "Present once `status` is `verified`",
+      "type": "string"
+    }
+  },
+  "required": [
+    "session_id",
+    "channel",
+    "status"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedSep 19, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that — that this is a repeated-poll operation, that it requires an authenticated Proof account with two distinct auth paths, and that a link surfaced only in a tool result is effectively invisible to the user. That last point is a non-obvious failure mode an agent could not infer from the schema.

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 polling instruction are front-loaded in the first sentence, and each subsequent block (UX caveat, access) carries distinct information. The ACCESS paragraph is somewhat long for what it conveys, but nothing is genuinely redundant.

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?

An output schema exists, so return values and terminal states need not be spelled out, and auth plus polling rhythm are covered. The only remaining gap is that it never names the companion tool that opens the session (start_add_phone), leaving the full workflow to inference.

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?

Single parameter with 100% schema description coverage, so the schema already defines session_id. The description restates 'by session ID' but adds no format, provenance, or sourcing guidance beyond what the schema provides; baseline 3 applies.

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 ('Check the status of an in-progress phone addition') and scopes it by session ID, with the polling lifecycle implied. The word 'phone' cleanly separates it from the sibling get_add_email_status and get_multi_channel_verification_status without needing to name them.

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?

Gives explicit operational guidance ('Poll until terminal state') and a concrete precondition before calling (the user-facing link/SMS text must already be in the reply). It also names start_login as an auth fallback, but never points to start_add_phone as the tool that creates the session being polled, so the entry path is only implied.

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

All Proof Holdings 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.