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

With no annotations, the description carries the full burden and does well: it discloses that values are never exposed, that timestamps may be null for legacy secrets, that npub ownership proof is required, and why the field list is itself sensitive. It omits rate limits or a safety hint on the mutating siblings, but covers the core behavioral profile.

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

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

Front-loads the key distinction (field names, not values) and proceeds through timestamp semantics, purpose, cost, and auth in a tight sequence. Every sentence earns its place, with only mild redundancy in restating the no-values guarantee.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still clarifies the delivered_at timestamp semantics usefully. Combined with the auth explanation, an agent has what it needs, though a note on fresh-vs-cached dpop_token usage would complete it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the npub and dpop_token parameters are already fully documented in the schema (including the detailed kind-27235 signing requirements). The description adds no parameter-specific syntax beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (stored patron credential field names), and immediately bounds the scope with '(not values)'. This cleanly distinguishes it from sibling mutations like delete_patron_credential, update_patron_credential, and forget_credentials.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the purpose ('use this to verify which fields are configured and how old each one is') and notes it is free, giving the agent a clear reason to prefer it. It does not name a specific alternative tool or a when-not-to-use condition, so it stops short of a 5.

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