Proof Holdings

list_reissued_proofs

Read-only

List your proofs whose token was re-signed at or after an instant, oldest first — what to re-fetch after a signing-key rotation, for example when a webhook was missed. Items are references {proof_id, reissued_at, token_url}, never tokens: pull a ph_ctl_* item with get_proof_token and a ph_dlg_* item with get_delegation_token. Proofs of the account's own verified assets are not listed here (the API key cannot read their tokens); the dashboard shows them. A key bound to a sub-account lists only that sub-account's proofs and the account's delegations.

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": {
      "since": "<since>"
    },
    "name": "list_reissued_proofs"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number
`limit`	No	Items per page
`since`	Yes	ISO-8601 instant with an offset, e.g. 2026-10-01T00:00:00Z

Output Schema

Name	Required	Description	Default
`data`	Yes
`pagination`	Yes	Pagination info in list responses

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnlyHint=true, it discloses that items are references rather than tokens, that certain proofs are excluded because the API key cannot read their tokens, and that a sub-account-bound key sees only that sub-account's proofs plus the account's delegations. It also spells out the authentication prerequisite and warns that start_login does not unlock this tool, which is exactly the kind of context annotations cannot carry.

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?

The core definition is front-loaded and dense with useful detail, with each clause carrying information. The trailing ACCESS block is necessarily verbose but slightly disrupts the flow; overall it stays efficient and free of filler.

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 an output schema exists, the description need not enumerate return fields, yet it still characterizes item structure and origin. Combined with the scoping and auth notes, an agent has everything needed to call it correctly and interpret the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so page and limit are already documented; the description adds meaning to `since` by tying it to when a token was re-signed and by fixing the result ordering as oldest first. It adds some value beyond the schema, though it does not explain pagination behavior beyond what the schema states.

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 (list your proofs whose token was re-signed), plus scope (at or after an instant), ordering (oldest first), and return shape (references, not tokens). It is clearly distinguishable from list_revoked_proofs and get_proof_token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggers for use (recovery after a signing-key rotation, e.g. a missed webhook) and routes follow-up work to the right siblings: get_proof_token for ph_ctl_* items and get_delegation_token for ph_dlg_* items. It also states exclusions, noting that the account's own verified-asset proofs are not listed here and are visible in the dashboard instead.

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.