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

@proof-holdings/mcp-server

Official
by ProofHoldings
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list_delegations

Read-only

Lists your own delegations with optional status and pagination filters, returning derived effective_status so you can see expired or invalid delegations even when stored status reads active.

Instructions

List your own delegations with optional filters. Each item carries the DERIVED effective_status/is_valid beside its stored status — read effective_status, since status records only whether the owner revoked the delegation themselves, so a delegation still reads active there after its domain control proof was revoked, suspended or expired, and after its OWN lifetime ran out. effective_status accounts for all of those: it reports expired once either lifetime has passed, whichever is earlier. Tokens are not included in the list — use get_delegation for the stored token. There is no public enumeration of third-party delegations.

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
pageNoPage number
limitNoItems per page
statusNoFilter by the delegation's OWN stored status (active|revoked). Does NOT filter the derived effective_status — status=active still returns delegations whose control proof died, and ones that simply ran out.

Output Schema

NameRequiredDescriptionDefault
dataNo
paginationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "data": {},
+    "pagination": {}
+  },
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and delivers: it explains that effective_status is derived, that stored status only reflects owner-initiated revocation, that the proof can be revoked/suspended/expired, and that expiry uses the earlier of two lifetimes. It also discloses that tokens are omitted and that the tool requires an authenticated Proof account. The only gap is no mention of pagination behavior or result ordering, which keeps it from a 5.

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?

Content is front-loaded with the core action first, then the status caveat, then the token exclusion, then access requirements. Some phrasing is dense and repeats what the status enum description already says, but nearly every sentence conveys a distinct constraint an agent would otherwise get wrong.

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 return-shape detail is unnecessary. The description covers the remaining risk areas for this tool: auth requirements and the exact remediation, the derived-vs-stored status trap, missing token data with a pointer to the right tool, and the absence of third-party enumeration.

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 baseline is 3, but the description adds real interpretive value by explaining why the status filter is misleading (it ignores control-proof death and lifetime expiry) and how effective_status resolves it. Page and limit are left entirely to the schema, which is acceptable given their self-explanatory descriptions.

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 with explicit scope: 'List your own delegations with optional filters.' It also carves out the boundary against siblings by noting tokens are excluded and that 'There is no public enumeration of third-party delegations,' so an agent can distinguish it from get_delegation and the various list_* siblings without opening a schema.

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?

Explicitly routes the agent to an alternative ('use get_delegation for the stored token') and tells it which field to read and why ('read effective_status'). It also documents a prerequisite path in the ACCESS block (PROOF_API_KEY, restart, and that start_login does NOT unlock this tool), which is exactly the when/when-not guidance an agent needs.

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