Proof Holdings

get_asset

Read-only

Get a single verified asset by ID. Returns details including type, value, status, and verification timestamps.

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_asset"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Asset ID

Output Schema

Name	Required	Description
`id`	Yes	MongoDB ObjectId
`type`	Yes	Type of asset being verified. Not yet available — no channel of theirs can be completed, so a create or start answers 400 `channel_not_available`: social, wallet, account.
`status`	Yes	Status of a verified asset
`channel`	Yes	How the asset was verified: a verification channel, or `otp` / `magic_link` for an email address confirmed from the dashboard
`metadata`	No	Channel-specific details recorded at verification
`proof_id`	No	Public handle of the proof backing this asset (`ph_ctl_<32 hex>`), or null when the asset predates the proof registry. This is the `control_proof` value `POST /api/v1/delegations` takes.
`has_proof`	No	Whether a proof token is stored for this asset. Sent by the point read (`GET /me/assets/{id}`) only.
`created_at`	Yes
`identifier`	Yes
`proof_token`	No	The stored signed proof token. Returned by the point read (`GET /me/assets/{id}`) to a JWT owner session ONLY — an API-key caller and the list response carry `has_proof` alone.
`verified_at`	No
`proof_status`	No	Registry status of that proof. Only an `active` proof can anchor a delegation.
`proof_expires_at`	Yes	When the proof backing this asset expires

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": "User verified asset",
+  "properties": {
+    "channel": {
+      "description": "How the asset was verified: a verification channel, or `otp` / `magic_link` for an email address confirmed from the dashboard",
+      "type": "string"
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "has_proof": {
+      "description": "Whether a proof token is stored for this asset. Sent by the point read (`GET /me/assets/{id}`) only.",
+      "type": "boolean"
+    },
+    "id": {
+      "description": "MongoDB ObjectId",
+      "type": "string"
+    },
+    "identifier": {
+      "type": "string"
+    },
+    "metadata": {
+      "additionalProperties": {},
+      "description": "Channel-specific details recorded at verification",
+      "properties": {},
+      "type": "object"
+    },
+    "proof_expires_at": {
+      "description": "When the proof backing this asset expires",
+      "type": "string"
+    },
+    "proof_id": {
+      "description": "Public handle of the proof backing this asset (`ph_ctl_<32 hex>`), or null when the asset predates the proof registry. This is the `control_proof` value `POST /api/v1/delegations` takes.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "proof_status": {
+      "description": "Registry status of that proof. Only an `active` proof can anchor a delegation.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "proof_token": {
+      "description": "The stored signed proof token. Returned by the point read (`GET /me/assets/{id}`) to a JWT owner session ONLY — an API-key caller and the list response carry `has_proof` alone.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "description": "Status of a verified asset",
+      "type": "string"
+    },
+    "type": {
+      "description": "Type of asset being verified. Not yet available — no channel of theirs can be completed, so a create or start answers 400 `channel_not_available`: social, wallet, account.",
+      "type": "string"
+    },
+    "verified_at": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "type",
+    "channel",
+    "identifier",
+    "status",
+    "proof_expires_at",
+    "created_at"
+  ],
+  "type": "object"
+}

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

TDQS

A3.8/5.0

Behavior4/5

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

readOnlyHint=true is consistent with "Get". Beyond the annotations, the description adds real behavioral context the schema can't convey: an account prerequisite and an explicit anti-hint that start_login does not satisfy it, which prevents a failed-call loop. It stops short of saying what happens with an unverified or revoked asset ID.

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 tight sentences: what it returns first, then the access blocker, front-loaded before any call attempt. The phrase "needs a Proof account" is slightly redundant with the following sentence but nothing is wasted.

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?

An output schema exists, so the description needn't detail return shape, and the auth prerequisite plus the start_login caveat cover the main failure mode. For a one-parameter read tool, that is complete enough to call correctly on the first try.

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 description coverage is 100% for the single `id` parameter, so the schema already carries the semantics and baseline 3 applies. The description adds no ID format, prefix, or source-of-IDs guidance beyond "by ID".

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 single verified asset by ID") and notes the returned fields, which implicitly separates it from list_assets. It doesn't name the list/revoke siblings explicitly, so the differentiation is inferential rather than stated.

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

Usage Guidelines3/5

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

The access notes do tell the agent how to get into a usable state (authenticate via /mcp, and that start_login does not unlock this tool), which is genuine usage guidance. But there's no statement of when to prefer this over list_assets or get_profile_assets, and no when-not guidance beyond the auth prerequisite.

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.