Proof Holdings

get_multi_channel_verification_status

Read-only

Get the status of a multi-channel verification group by its group_id. Returns the aggregate status (pending/verified/expired), the winning_channel once one completes, per-channel statuses, and the proof token (with expires_at) when the group is verified.

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), 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": {
      "group_id": "<group_id>"
    },
    "name": "get_multi_channel_verification_status"
  }
}

Input Schema

Name	Required	Description	Default
`group_id`	Yes	Multi-channel verification group ID (format vg_<hex>)

Output Schema

Name	Required	Description
`proof`	No
`status`	No	Group-level status: verified as soon as any channel completes
`channels`	No	Per-channel statuses without per-channel error detail
`group_id`	No
`winning_channel`	No	Channel that completed the verification (null while pending)

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": {},
+  "properties": {
+    "channels": {
+      "description": "Per-channel statuses without per-channel error detail"
+    },
+    "group_id": {},
+    "proof": {},
+    "status": {
+      "description": "Group-level status: verified as soon as any channel completes"
+    },
+    "winning_channel": {
+      "description": "Channel that completed the verification (null while pending)"
+    }
+  },
+  "type": "object"
+}

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

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds substantial extras: the state machine (pending/verified/expired), when winning_channel appears, and the account/authentication requirement with the /mcp → Authenticate path plus the explicit note that start_login does NOT open this tool. It stops short of rate-limit or polling-guidance details.

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?

Return semantics are front-loaded in the first sentence, followed by the UX precondition and then access requirements — a sensible ordering. It is slightly long for a single-parameter read tool, but every sentence carries actionable information.

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?

Despite an output schema existing (so returns needn't be explained), the description still summarizes them, and it covers the two things structured fields cannot: the required authentication state and the user-facing display obligation. Nothing an agent needs to call it correctly 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?

Schema coverage is 100% (group_id typed as string with the vg_<hex> format documented), so the schema already carries the parameter semantics. The description only restates 'by its group_id', adding no format or validation detail beyond the schema.

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 opens with a specific verb+resource ('Get the status of a multi-channel verification group') and then enumerates the exact return fields (aggregate status, winning_channel, per-channel statuses, proof token with expires_at). This clearly distinguishes it from creation/flowering siblings like create_multi_channel_verification or wait_for_verification.

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 gives a concrete usage context ('Before calling this for a challenge you created') and an explicit precondition about the reply text the user must already have seen. It does not, however, mention alternatives such as wait_for_verification or polling cadence, so a 'when not to use' comparison is missing.

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.