Skip to main content
Glama
wkalidev

unlock-mcp

by wkalidev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check Unlock Protocol membership

unlock_check_membership

Check whether a wallet has a valid, non-expired key for a specific Unlock Protocol lock. Returns status (valid, expired, no key) plus lock details, so you can verify membership before granting access.

Instructions

Check whether a wallet holds a valid (non-expired) key for a specific Unlock Protocol lock, read-only. Returns status (valid, expired, no_key, not_a_contract, or not_a_lock), lock name, tokenId, and expiration. Use this when you already know the lock address to check; use unlock_list_keys instead when you need every lock a wallet holds and don't know the addresses up front. The verdict normally comes from the lock's own getHasValidKey; on locks that predate it, the call falls back to comparing the read expiration to the local clock and reports verdictSource: "local_clock" (absent when the contract answered). Set requireContractVerdict to fail instead of accepting that fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
networkNoNetwork name (defaults to "base")base
lockAddressYesAddress of the PublicLock contract to check
walletAddressYesWallet address to check for a valid key
requireContractVerdictNoWhen true, fail with an error instead of falling back to comparing keyExpirationTimestampFor to the local clock when the lock's own getHasValidKey can't be read (e.g. it predates getHasValidKey). That fallback is a supported valid/expired answer by default (false) — set this to require a verdict sourced from the contract itself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • addedInput schema / properties / requireContractVerdict
      Added value: +{
+  "default": false,
+  "description": "When true, fail with an error instead of falling back to comparing keyExpirationTimestampFor to the local clock when the lock's own getHasValidKey can't be read (e.g. it predates getHasValidKey). That fallback is a supported valid/expired answer by default (false) — set this to require a verdict sourced from the contract itself.",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv0.2.0
    • removedInput schema / properties / walletAddress / $ref
      Removed value: -"#/properties/lockAddress"
    • addedInput schema / properties / walletAddress / type
      Added value: +"string"
  3. First observedv0.1.0

TDQS

A4.9/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 declares the operation as read-only, describes return statuses, and explains the getHasValidKey vs. local_clock fallback behavior plus the requireContractVerdict escape hatch. This is unusually transparent about how the verdict is produced.

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?

The description is dense but every sentence earns its place: what it does, what it returns, when to use it, and the fallback behavior. It front-loads the core purpose before diving into edge-case mechanics.

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?

Even though there is no output schema, the description enumerates the returned status values and fields. It also explains the fallback mechanism and the parameter that disables it, making the tool callable and interpretable without additional context.

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 the parameters are already documented. The description adds value by explaining what requireContractVerdict actually controls and how verdictSource relates to the fallback, going beyond the schema's description.

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?

The description states a precise action: check whether a wallet holds a valid key for a specific Unlock Protocol lock. It also differentiates itself from the sibling unlock_list_keys by noting the addressing condition, so an agent can distinguish the tools without opening schemas.

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?

It explicitly says to use this tool when you already know the lock address, and to use unlock_list_keys when you need every lock a wallet holds and don't know the addresses up front. This gives clear selection criteria against the most likely alternative.

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