Skip to main content
Glama
Sign In
@proof-holdings/mcp-server

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_profile_assets

Read-only

Retrieves verified assets eligible for public proof display on a user's profile, optionally scoped to a specific sub-account.

Instructions

Get available verified assets that can be displayed on the user's profile. Returns assets eligible for public proof display.

ACCESS: needs a Proof account. Set PROOF_API_KEY and restart this server, then call this tool again. start_login does NOT open this tool.

Input Schema

NameRequiredDescriptionDefault
profile_idNoThe sub-account whose shown proofs set each asset's is_public flag (24 hex characters); omitted, the primary

Output Schema

NameRequiredDescriptionDefault
assetsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.2
    • addedInput schema / properties / profile_id
      Added value: +{
+  "description": "The sub-account whose shown proofs set each asset's is_public flag (24 hex characters); omitted, the primary",
+  "pattern": "^[0-9a-fA-F]{24}$",
+  "type": "string"
+}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "assets": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "channel": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "identifier": {
+            "type": "string"
+          },
+          "is_public": {
+            "type": "boolean"
+          },
+          "proof_expires_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "type": {
+            "type": "string"
+          },
+          "verified_at": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "type",
+          "identifier",
+          "channel",
+          "is_public"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "assets"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A3.6/5.0
Behavior3/5

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

The readOnlyHint annotation already establishes this is a safe read, and the output schema covers return values. The description does add meaningful auth context (Proof account required, PROOF_API_KEY env var plus server restart, start_login insufficient) that cannot be derived from structured fields. It says nothing about scoping behavior when profile_id is omitted beyond what the schema already states, so it is solid but not rich.

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?

Purpose comes first, then the access requirement, in three short sentences with no filler. The 'restart this server, then call this tool again' instruction is operational but earns its place by preventing a failed call.

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?

For a one-optional-parameter read tool with annotations and an output schema, the description covers purpose and the blocking prerequisite, which is the main failure mode. The only real gap is sibling differentiation from list_assets and update_profile_proofs.

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% and the single profile_id parameter is already documented with its 24-hex pattern and default-to-primary behavior. The description adds no additional meaning about the parameter, which is acceptable given the schema does the work.

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 available verified assets that can be displayed on the user's profile') and clarifies the returned subset ('eligible for public proof display'). It does not, however, distinguish itself from close siblings such as list_assets, get_asset, or update_profile_proofs, so an agent must infer the boundary.

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?

Gives a clear eligibility condition for use (assets that can be shown publicly on a profile) plus an explicit exclusion: start_login does NOT unlock this tool. It stops short of naming which alternative to call when the prerequisite is unmet, leaving the agent to figure out the API-key path itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools