Skip to main content
Glama

list_delegations

Read-only

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. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_delegations"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoSearch: literal, case-insensitive text matched in the artifact, the issuing domain or the ph_dlg_ handle
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. Changed1 schema field changed
    • addedInput schema / properties / q
      Added value: +{
      +  "description": "Search: literal, case-insensitive text matched in the artifact, the issuing domain or the ph_dlg_ handle",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "data": {},
      +    "pagination": {}
      +  },
      +  "type": "object"
      +}
  3. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description explains the derived nature of effective_status/is_valid, exactly which conditions they account for (control proof revoked, suspended, expired, own lifetime elapsed, earliest wins), and why stored status is misleading. It also discloses a real payload limitation (tokens are not returned) and the account/authentication prerequisite, which annotations do not cover.

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?

Front-loads the purpose in the first sentence, then explains the derived status, the token exclusion, and access. The auth block is slightly procedural and could be trimmed, but every sentence carries operational information — no 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?

For a paginated read tool with an output schema already defining return shape, the description covers everything else an agent needs: scope, filter semantics, the derived-vs-stored status distinction, token omission, auth requirement, and the absence of a third-party listing capability.

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 q/page/limit are already documented. The description still adds meaning by tying the status filter to the derived-field model, warning that status=active still returns delegations whose control proof died or that ran out — reinforcing a trap the schema notes but the description makes salient.

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 own delegations") plus the scope restriction ("your own") and the presence of optional filters. It also distinguishes itself from get_delegation for tokens and rules out public/third-party enumeration, so an agent knows what this listing does and does not cover.

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 explicit routing: use get_delegation for the stored token, and there is no public enumeration of third-party delegations, so an agent won't search for one. It also tells the caller to read effective_status rather than status when deciding validity. It does not contrast against verify_delegations or other list tools, but the in-scope guidance is concrete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.