Skip to main content
Glama

List Unlock Protocol keys held by a wallet

unlock_list_keys

List every Unlock Protocol membership a wallet holds across a network to find all locks at once, without knowing lock addresses upfront. Returns key details and validity, sorted by expiration.

Instructions

List every Unlock Protocol key a wallet holds across locks on a network, via the Unlock subgraph, read-only. Returns each key's lock address and name, tokenId, expiration, and validity, sorted by expiration descending and capped at 100 results with a truncation flag. Use this when you need every membership a wallet holds and don't know the lock addresses up front; use unlock_check_membership instead when you already know which lock to check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkNoNetwork name (defaults to "base")base
walletAddressYesWallet address to list Unlock Protocol keys for
includeExpiredNoInclude expired and cancelled keys, not just currently valid ones (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it says the operation is read-only, uses the Unlock subgraph, returns specific fields, sorts by expiration descending, caps at 100 results, and includes a truncation flag. These are meaningful behavioral details beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: the action and scope come first, then return behavior and limits, then usage guidance with an alternative. Every sentence contributes distinct, useful information.

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?

There is no output schema and no annotations, but the description compensates by disclosing return fields, sorting, cap, truncation flag, read-only nature, and the intended use case. This is complete for an agent to select and invoke the tool correctly.

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%, so all three parameters already have descriptions. The tool description does not add much parameter-specific meaning beyond restating the general purpose, which is acceptable but not an enhancement. Baseline 3 applies.

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?

Uses a specific verb ('List') with a clear resource ('Unlock Protocol keys a wallet holds across locks on a network') and explicitly distinguishes itself from unlock_check_membership. The description states both scope and what results include, so an agent can identify the tool without opening the 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 states when to use this tool ('when you need every membership a wallet holds and don't know the lock addresses up front') and names the alternative ('use unlock_check_membership instead when you already know which lock to check'). This gives an agent direct routing guidance.

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