Proof Holdings

get_identity_challenge

Read-only

Get a Proof-Me identity challenge by ID. Returns its status (pending, confirmed, denied, cancelled, failed, expired, revoked or suspended), the channel the CONFIRM ran on, and — once the person being checked decided — the proof token and its proof_id. Poll this for resolution.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

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": "get_identity_challenge"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Identity challenge ID

Output Schema

Name	Required	Description
`id`	Yes
`status`	Yes	The one status every read reports. `pending` — waiting for the person being checked; `confirmed` — they confirmed; `denied` — they denied; `cancelled` — whoever started the check withdrew it; `failed` — the check could not be delivered; `expired` — nobody answered in time; `revoked` / `suspended` — the confirmation's proof was revoked or suspended (`POST /proofs/{proof_id}/revoke` or `/suspend`; revoking a denial's proof leaves it `denied`), or — `revoked` only — the member being checked was removed from the Circle while the check was still pending, which leaves `proof_id` null. Removing a member is not guaranteed to revoke a confirmation they already gave; revoke that one by its `proof_id`. A proof that merely reached its own expiry still reads `confirmed`; whether its token is still valid is `POST /proofs/validate`'s answer.
`channel`	No	Channel the CONFIRM was dispatched on (GET)
`is_drill`	No	True for a drill (scheduled, or started from the dashboard) rather than a real check (GET)
`proof_id`	No	Public handle of the decision's proof — what `POST /proofs/{proof_id}/revoke` takes. Null until a decision minted one (GET).
`circle_id`	No	The Circle the check belongs to (GET)
`created_at`	No	ISO 8601 timestamp
`expires_at`	No	ISO 8601 timestamp
`proof_token`	No	Signed proof token, present once the person being checked decided
`resolved_at`	No	ISO 8601 timestamp of the decision — the CONFIRM, the DENY, the cancellation or the delivery failure — or null while the check is unanswered and after a timeout.
`confirm_channel`	No	Channel the CONFIRM was dispatched on (POST)
`single_channel_warning`	No	True when the account holder has only one channel, so the CONFIRM ran on the same channel as the suspicious contact (degraded)

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": "An identity challenge (Proof of Me)",
+  "properties": {
+    "channel": {
+      "description": "Channel the CONFIRM was dispatched on (GET)",
+      "type": "string"
+    },
+    "circle_id": {
+      "description": "The Circle the check belongs to (GET)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "confirm_channel": {
+      "description": "Channel the CONFIRM was dispatched on (POST)",
+      "type": "string"
+    },
+    "created_at": {
+      "description": "ISO 8601 timestamp",
+      "type": "string"
+    },
+    "expires_at": {
+      "description": "ISO 8601 timestamp",
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "is_drill": {
+      "description": "True for a drill (scheduled, or started from the dashboard) rather than a real check (GET)",
+      "type": "boolean"
+    },
+    "proof_id": {
+      "description": "Public handle of the decision's proof — what `POST /proofs/{proof_id}/revoke` takes. Null until a decision minted one (GET).",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "proof_token": {
+      "description": "Signed proof token, present once the person being checked decided",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "resolved_at": {
+      "description": "ISO 8601 timestamp of the decision — the CONFIRM, the DENY, the cancellation or the delivery failure — or null while the check is unanswered and after a timeout.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "single_channel_warning": {
+      "description": "True when the account holder has only one channel, so the CONFIRM ran on the same channel as the suspicious contact (degraded)",
+      "type": "boolean"
+    },
+    "status": {
+      "description": "The one status every read reports. `pending` — waiting for the person being checked; `confirmed` — they confirmed; `denied` — they denied; `cancelled` — whoever started the check withdrew it; `failed` — the check could not be delivered; `expired` — nobody answered in time; `revoked` / `suspended` — the confirmation's proof was revoked or suspended (`POST /proofs/{proof_id}/revoke` or `/suspend`; revoking a denial's proof leaves it `denied`), or — `revoked` only — the member being checked was removed from the Circle while the check was still pending, which leaves `proof_id` null. Removing a member is not guaranteed to revoke a confirmation they already gave; revoke that one by its `proof_id`. A proof that merely reached its own expiry still reads `confirmed`; whether its token is still valid is `POST /proofs/validate`'s answer.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "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?

readOnlyHint already declares the safety profile, and the description adds genuinely non-obvious context: an account/auth prerequisite, the authenticate-then-retry recovery path, and the warning that start_login does NOT unlock this tool. It also documents the full status vocabulary the agent must branch on, which is not derivable 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?

Two short, front-loaded paragraphs: capability and return contract first, then a clearly labeled ACCESS prerequisite. The parenthetical Claude Code auth instructions are slightly verbose for a general-purpose agent but still earn their place by preventing a failed call loop.

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 an output schema present and annotations covering read-only semantics, the description supplies the remaining pieces: the auth gate, polling guidance, and the status set. It stops short of routing to the blocking alternative tools in this crowded get_/wait_ family, which is the only material gap.

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?

Only one parameter and the schema describes it at 100% coverage ('Identity challenge ID' with a 24-hex pattern), so the description's 'by ID' adds nothing new. Baseline 3 applies when the schema carries the semantics.

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 ('Get a Proof-Me identity challenge by ID') and immediately enumerates the returned fields, so an agent knows exactly what it retrieves. It is clearly distinguished from the write-side sibling create_identity_challenge by the ID-based retrieval framing.

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?

'Poll this for resolution' gives an explicit usage mode, which is the key behavioral decision for this tool. It does not, however, point at alternatives such as wait_for_verification or get_verification for agents that should block rather than poll, so there is no exclusion guidance.

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.