Skip to main content
Glama

remove_phone

Destructive

Remove a phone number from the account. Always requires one code: start_2fa_for_action with action_type phone_remove and targets [this phone id]. Revokes every proof of the number and your own consents naming it, declines pending confirmations waiting on it, flags approval setups left with no approver, deletes the record and its messenger links, signs out your other devices, and names the new primary phone — your Proof of Me circles then reach you there. Refused for the number you signed in with, for your only way to sign in, and for your last phone while circles are active (circles_need_phone: add another phone first, or archive the circles). Cannot be undone.

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": {
      "id": "<id>"
    },
    "name": "remove_phone"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPhone record ID

Output Schema

NameRequiredDescriptionDefault
typeNo
noticeNo
successNoAlways `true`. The 1.x Go, PHP and Python SDK types carry it as a string, as released; it is typed boolean in the next major.
identifierNoMasked.
removed_idNo
new_primaryNoThe row that becomes (or became) primary when the removed one was; null otherwise.
proofs_revokedNo
lookalike_watchNo
circles_repointedNoPhones only: circles that now reach the owner at `new_primary`; 0 for an email.
sessions_signed_outNoEvery other device was signed out, idle ones included; the calling session stays. False when that could not be done — the removal itself still happened.
sessions_invalidatedNoOther listed devices signed out, idle ones included; the calling session stays. A device missing from the list — signed in before the list held idle devices, or one whose listing could not be recorded — is not counted, so read `sessions_signed_out` for whether every other device was signed out.
authorizations_revokedNo
hitl_configs_without_approverNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "authorizations_revoked": {},
      +    "circles_repointed": {
      +      "description": "Phones only: circles that now reach the owner at `new_primary`; 0 for an email."
      +    },
      +    "hitl_configs_without_approver": {},
      +    "identifier": {
      +      "description": "Masked."
      +    },
      +    "lookalike_watch": {},
      +    "new_primary": {
      +      "description": "The row that becomes (or became) primary when the removed one was; null otherwise."
      +    },
      +    "notice": {},
      +    "proofs_revoked": {},
      +    "removed_id": {},
      +    "sessions_invalidated": {
      +      "description": "Other listed devices signed out, idle ones included; the calling session stays. A device missing from the list — signed in before the list held idle devices, or one whose listing could not be recorded — is not counted, so read `sessions_signed_out` for whether every other device was signed out."
      +    },
      +    "sessions_signed_out": {
      +      "description": "Every other device was signed out, idle ones included; the calling session stays. False when that could not be done — the removal itself still happened."
      +    },
      +    "success": {
      +      "description": "Always `true`. The 1.x Go, PHP and Python SDK types carry it as a string, as released; it is typed boolean in the next major."
      +    },
      +    "type": {}
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description adds extensive behavioral detail beyond the destructiveHint annotation: it lists revoked proofs and consents, declined confirmations, flagged approvals, deleted links, signed-out devices, primary phone reassignment, and refusal conditions. This gives an agent a clear picture of the irreversible side effects.

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

Conciseness5/5

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

The description is front-loaded with the purpose and prerequisite, then proceeds through consequences, refusals, and authentication. Despite its length, every sentence carries actionable information for a destructive tool.

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?

Given the destructive annotation, output schema presence, and single well-documented parameter, the description covers authentication, prerequisites, side effects, refusals, and irreversibility. Nothing essential for safe invocation is missing.

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?

The single id parameter has 100% schema description coverage and is documented as a Phone record ID. The description adds only that the same phone id is used as the target in the required 2FA action, which is minor additional meaning.

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 description states a specific verb and resource: remove a phone number from the account. It clearly distinguishes this from sibling tools such as remove_email by specifying the resource, and the scope is unambiguous.

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?

It explains the required 2FA prerequisite and refused conditions in detail, including the alternative of adding another phone or archiving circles. However, it does not explicitly route to sibling tools like set_primary_phone or remove_email, leaving that comparison implied.

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.