tollbooth-authority

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

With no annotations, the description fully discloses behaviors: it's free, requires proof of npub ownership, details dpop_token format and constraints (time, tag, etc.). This goes beyond minimal requirements.

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?

The description is concise, well-structured with bullet points, and front-loaded with the main purpose. Every sentence adds value without redundancy.

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?

Given the tool's moderate complexity, the existence of an output schema (not shown but noted), and clear annotations of parameters, the description is complete: it covers purpose, usage, behavior, and parameter semantics thoroughly.

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 coverage is 0%, but the description explains all three parameters in detail: npub (public key context), dpop_token (exact format and requirements), and days (default 30). This adds significant meaning beyond the schema.

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?

The description clearly states the tool generates a patron's account statement, listing exactly what it returns (purchase history, credit tranches, usage breakdown, daily logs). It also distinguishes this from the operator's Authority tax balance, making the purpose unambiguous.

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?

The description explains the tool is for generating a patron's spending account statement and is free. While it doesn't explicitly list when not to use or alternatives, it contrasts with the operator's tax balance, providing some guidance. Given the large sibling list, this is adequate.

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

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

With no annotations, description carries full burden. It discloses cost (1 api_sat) and verification process, but does not explicitly state it is read-only or describe side effects. The dark-themed SVG description gives visual expectation.

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?

Well-structured and front-loaded with purpose. Parameter descriptions are thorough but somewhat wordy; could be slightly more concise, but every sentence adds value.

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?

Covers return format (SVG, contents), cost, verification, all parameters. Output schema exists to describe returns further. Missing prerequisites like having an account or sufficient balance, but overall sufficient for a visual generation tool.

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 coverage is 0%, but description compensates exceptionally. Gives detailed instructions for `dpop_token` format and validation, explains `npub`, and provides default for `days`. Adds significant meaning beyond raw schema.

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?

Clearly states it generates a visual SVG infographic, and distinguishes from sibling `authority_account_statement` by saying it returns the same data rendered as a graphic. The verb 'Generate' and resource 'infographic' are specific.

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?

Provides good usage context: cost per call and verification step. Implicitly contrasts with `account_statement` for raw data, but lacks explicit when-not-to-use or alternatives beyond that single sibling.

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

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

With no annotations, the description carries full burden. It states the tool is free and polls the Authority MCP-to-MCP, suggesting a network call. It does not disclose permissions, side effects, or whether the operation is read-only. The description is basic but not misleading.

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?

The description is concise at two sentences, with the purpose front-loaded. Every sentence adds information. It could be slightly more structured by explicitly mapping the authority parameter, but overall it is efficient.

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?

Given the existence of an output schema, the description need not detail return values. It lists possible statuses. However, missing parameter explanations and no disambiguation from sibling 'authority_get_adoption_status' leave gaps for an agent to fully understand context.

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 0%, so the description must add meaning. It mentions 'at a chosen Authority' which hints at authority_npub, but provides no explanation for dpop_token or any parameter details. The description fails to clarify parameter semantics beyond what the schema already shows.

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?

The description clearly states the tool checks adoption-request status at a chosen authority, listing possible statuses. However, it does not distinguish itself from the sibling tool 'authority_get_adoption_status', which appears to have a nearly identical purpose.

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?

The description implies the tool is for checking status after requesting adoption, but provides no explicit guidance on when to use it versus alternatives like 'authority_approve_adoption' or 'authority_get_adoption_status'. No usage exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It mentions the provisioning effect and the deferred nature, but lacks details about side effects, required permissions, or whether the operation is reversible. While not misleading, it could be more transparent about behavioral traits.

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?

Two sentences, zero wasted words. Front-loaded with the primary action, then concise context. Efficient and well-structured.

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?

Given the tool's simplicity (2 params, output schema present), the description is complete. It explains what the tool does, its relationship to a sibling, and the parameters are self-explanatory from the schema.

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 coverage is 100% with descriptions for both parameters. The description adds marginal context about 'authority_proof' being consent from Authority's OWN npub, but the schema already conveys this. Baseline 3 is appropriate.

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?

The description clearly states the tool approves a pending request and provisions the operator, using strong verb+resource. It also distinguishes itself from register_operator as its deferred counterpart, adding specificity.

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?

The description explicitly positions this tool as the counterpart to register_operator, indicating when to use it (after review) and when not to (use register_operator instead). This provides clear guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the paid_tool decorator handles the fee debit and stores cost in runtime._last_debit_cost, and that no recomputation is needed. However, it lacks details on side effects, permissions, idempotency, or error behavior.

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?

The description is 4 sentences, front-loaded with the core purpose, and each sentence adds distinct value: purpose, decorator behavior, and caller context. It is appropriately concise without being under-specified.

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?

Given the presence of an output schema (implied by the context signal) and the moderate complexity (3 parameters, no nested objects), the description covers the key aspects: return type, decorator role, and usage context. It is adequate for a server-side certification tool.

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 67% (2 of 3 parameters described). The dpop_token parameter has no description in the schema, and the tool description adds no parameter details beyond what's in the schema. The description does not compensate for the missing parameter documentation.

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?

Description clearly states the tool certifies a purchase order and returns a Schnorr-signed Nostr event certificate, providing a specific verb and resource. However, it could more explicitly distinguish itself from sibling tools like authority_purchase_credits by stating that it is invoked after a purchase is initiated.

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?

The description mentions it is called by operator MCP servers when a patron purchases credits, giving context for usage. However, it does not provide explicit when-not-to-use guidance or alternatives, leaving some ambiguity for an AI agent.

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

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

No annotations are provided, so the description bears full burden. It mentions 'activate Authority' but does not disclose side effects, permissions, or idempotency. The behavioral impact is vague.

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?

The description is very concise (one sentence) and includes crucial sequencing info upfront. However, it could be slightly more informative without losing conciseness.

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?

Given the tool's simplicity (one parameter, output schema present), the description covers the basic function but lacks detail on the activation process and potential outcomes.

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% for the single parameter. The description does not add significant meaning beyond the schema's parameter description.

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?

The description clearly states it checks parent approval and activates Authority, with context as step 3/3. It uses specific verbs and resource, but lacks explicit differentiation from sibling tools like authority_approve_adoption.

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?

The description implies it is part of a sequence (step 3/3), offering some usage context. However, it does not provide explicit when-to-use, when-not-to-use, or alternative tools.

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

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

With no annotations, the description carries the burden. It clearly indicates a read operation with no destructive side effects, and explains the consequence of a zero balance. However, it lacks details on authentication requirements or rate limits, but these are minor given the simplicity.

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?

The description is extremely concise with three sentences, each adding value. It is front-loaded and contains no fluff.

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?

For a simple read tool with no parameters and an existing output schema, the description provides all necessary context: what it does, the meaning of the return value, the action on zero balance, and distinction from patron balance. It is fully complete.

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?

The input schema has no parameters, so schema coverage is 100%. The description adds no parameter details, but none are needed. A score of 4 is appropriate as the description is complete for a parameterless tool.

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?

The description clearly states the tool checks the operator's tax balance at the Authority, specifies the return value (sats for certifying patron credits), and distinguishes it from patron balances, differentiating it from sibling tools like authority_check_balance.

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?

The description explains when to use the tool (to check balance) and provides guidance on what to do when balance is zero (call purchase_credits). It also clarifies this is the operator's own funding, not a patron balance, but does not explicitly compare to other similar tools.

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

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

No annotations exist, so description carries full burden. It discloses read-only nature (check), cost (free), and authentication requirement (dpop_token with specific constraints). Safety profile is well-covered.

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-loaded with purpose, then context, then parameter details. Sentences are efficient but could be slightly trimmed. Structure is logical and easy to parse.

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?

Given the large sibling set and no annotations, the description covers key aspects: authentication, cost, differentiation. Output schema exists, so return values need not be described. Minor gap: doesn't mention what happens on invalid input (e.g., insufficient dpop_token validity).

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 has 0% description coverage, but the description thoroughly explains both parameters: npub as Nostr public key and dpop_token with detailed construction rules (kind-27235 event, u tag, nonce, etc.). Adds significant value beyond schema types.

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?

The description clearly states 'Check a patron's credit balance at this operator' and distinguishes it from the operator's own balance using specific verb-resource framing. It differentiates from sibling tools like authority_check_authority_balance.

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?

Provides explicit context: this is for patron spending balance, free, requires npub ownership proof. It mentions an alternative for operator's balance, though it mistakenly references itself instead of authority_check_authority_balance. Still, the intent is clear.

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

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

With no annotations, the description must fully disclose behavior. It merely says 'look up', implying a read-only operation, but does not confirm side effects, authentication needs, or rate limits. This is insufficient for safe agent invocation.

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?

The description is extremely short (one sentence) but fails to include essential details. It is not front-loaded with actionable guidance. Every sentence should earn its place; here the sentence is too vague to be valuable.

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?

Despite having an output schema that could describe return values, the description is incomplete. It omits usage context, parameter details, and behavioral traits, leaving the agent underinformed for a tool with one parameter.

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?

The schema has 0% description coverage for the single 'npub' parameter, and the description adds no extra meaning. It does not explain what an npub is, expected format, or constraints, forcing the agent to guess.

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?

The description clearly states the tool looks up an npub in the DPYC community registry, specifying both the verb (look up) and resource (registry). It distinguishes itself from the many sibling tools, which cover different authority-related operations.

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?

No guidelines are provided regarding when to use this tool versus the many similar 'authority' tools. There is no information on prerequisites, context, or exclusions, leaving the agent without decision support.

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

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

No annotations are provided, so the description fully bears the burden. It details authentication via dpop_token and npub, explains the prevention of front-running, and gives specific formatting instructions for the token. This is valuable beyond the raw schema. It does not discuss error handling or return behavior, but the output schema likely covers that.

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?

The description is front-loaded with the purpose and usage note, followed by parameter details. While fairly long, every sentence serves a purpose and does not contain fluff. A bit more conciseness could be achieved by integrating some details into the parameter list, but it's still well-structured.

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?

Given the parameter count and complexity (especially dpop_token), the description covers the essential information: prerequisites (calling after purchase_credits), parameter semantics, and authentication details. It does not describe the return value format, but the presence of an output schema likely fills that gap. Overall, it is sufficiently complete for an agent to use correctly.

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 coverage is 0%, and the description provides thorough explanations for all three parameters: invoice_id (source of invoice), npub (public key of buyer), and dpop_token (detailed format specification). This adds essential meaning that the schema alone lacks.

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?

The description clearly states 'Check the payment status of a Lightning invoice,' which is a specific verb+resource. It also implies its relationship to purchase_credits, but does not explicitly distinguish from siblings like authority_certify_credits or authority_restore_credits.

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?

It explicitly says 'Call after paying the invoice from purchase_credits' and notes 'Free — no credits required.' This provides clear context for when to use it. However, it does not mention when not to use or alternatives.

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

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

The description discloses that the tool is free and no credits are required, and that it shows base cost and constraint effects. However, with no annotations provided, it lacks explicit statements about side effects (e.g., read-only behavior) or data modification. The 'Preview' label implies non-destructive action, but this is not explicitly stated.

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?

The description is moderately concise with minimal redundancy. It includes a structured Args section, but the note about FE callers adds slight verbosity. Overall, it is efficient and well-organized.

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?

Given the tool has 4 parameters and an output schema, the description covers the purpose and two parameters adequately, but misses the npub and dpop_token parameters entirely. It also does not explain the return format despite the existence of an output schema, though it mentions what is shown (base cost and constraint effects).

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?

The description explains two of the four parameters (tool_id, tool_kwargs) in detail, including examples and resolution logic. However, it fails to mention npub and dpop_token, which appear in the input schema but are not documented anywhere, leading to incomplete parameter coverage.

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?

The description clearly states 'Preview the effective cost of a tool call', which is a specific verb+resource. It distinguishes itself from sibling tools (e.g., authority_check_balance, authority_get_pricing_model) by focusing on cost preview rather than other account-related functions.

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?

The description provides context for use, mentioning that FE callers typically have the capability name and that the tool resolves both UUIDs and capability strings, making it convenient. However, it does not explicitly state when not to use this tool or mention alternative tools.

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

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

With no annotations, the description declares the tool is 'Free, no side effects' and 'does not evict the cache or touch relays', clearly indicating a read-only, safe operation. It does not mention permissions or rate limits, but adds sufficient behavioral context.

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?

The description is four sentences plus an Args list, with no superfluous words. The purpose is stated first, followed by usage context, behavioral traits, and parameter details.

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?

Given the existence of an output schema and low parameter count, the description covers the essential context: prerequisites (dpop_token origin), cache behavior, and cost. It does not detail failure modes, but the output schema likely handles that.

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?

The input schema lacks descriptions (0% coverage). The description adds meaning by specifying that patron_npub requires 'npub1...' format and that dpop_token is the phrase returned by request_npub_proof / receive_npub_proof. It claims both are required, though schema does not mark them as such.

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?

The description specifies 'Check whether a previously-cached dpop_token is still valid' with a clear verb and resource. It distinguishes itself from check_oauth_status by targeting the npub-proof flow.

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?

It explains when to use this tool: before a paid call to avoid burning credits on failure. It mentions an alternative (check_oauth_status) and states it is free with no side effects. However, it does not explicitly exclude use cases.

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

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

No annotations are provided, so the description must disclose behavioral traits. It describes the verification and escalation process, and explains the resolution of the parent Authority. However, it does not mention what happens on success/failure, side effects (e.g., state changes), or permissions needed. It is adequate but not fully transparent.

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?

Two sentences cover purpose, step context, and resolution logic. The first sentence front-loads the core action, and the second provides necessary detail. No wasted words.

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?

Given that this is a step in a multi-step process and an output schema exists, the description is fairly complete. It explains the step number, action, escalation, and parent resolution. Missing details on error handling or preconditions, but adequate for the context.

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?

The single parameter candidate_npub has 100% schema coverage, but the description adds meaningful context: 'The Nostr npub of the candidate who replied to the DM challenge.' This explains the role of the parameter within the onboarding step, going beyond the schema definition.

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?

The description clearly states it is 'Step 2/3 of Authority onboarding' and specifies the action: 'verify candidate DM, escalate to parent Authority.' This distinguishes it from sibling tools like authority_register_authority_npub or authority_get_operator_onboarding_status, and provides a specific verb-resource pair.

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?

The description explicitly places this tool in a sequence ('Step 2/3'), indicating when it should be used. It also explains how the parent Authority is resolved, giving context for usage. However, it does not include explicit when-not to use or alternatives, but the step-based guidance is clear.

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

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

Without annotations, the description discloses cascading deletions to redemptions and explains that chain steps become no-ops with warnings. It also states the restriction to operators, but does not detail the 'proof' requirement or reversibility.

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?

The description is concise with three front-loaded sentences, each adding value without redundancy.

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?

It covers behavioral aspects like cascading and restrictions, but lacks parameter details, which reduces completeness for a tool with 2 parameters and no schema descriptions.

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?

The input schema has 2 parameters (coupon_id, dpop_token) with 0% schema description coverage, but the description fails to explain these parameters or their roles.

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?

The description clearly states the action ('Delete a coupon') and resource, distinguishing it from sibling tools like authority_mint_coupon and authority_forget_coupon by detailing cascading deletions to redemptions.

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?

It mentions the tool is restricted to operators requiring proof, implying who can use it, but provides no guidance on when to use this tool versus alternatives like authority_forget_coupon.

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

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

With no annotations provided, the description carries the full burden. It explains that this is a write operation to a sensitive vault and requires authentication. However, it does not disclose potential side effects, error handling, idempotency, or whether the field must exist. The description adds some transparency but lacks completeness for a mutation tool.

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?

The description is concise and well-structured: a brief summary followed by clear paragraphs for each parameter. Every sentence adds necessary information without redundancy. The use of bullet-like formatting in the Args section improves readability.

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?

The tool has an output schema (not shown), which reduces the need to explain return values. The description covers authentication and parameter semantics thoroughly. However, it does not mention what happens on success or error, or whether deletion is idempotent. Given the complexity of the dpop_token, the description is mostly complete.

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?

The input schema provides no descriptions (0% coverage), but the description compensates with detailed explanations for all three parameters: npub (format), dpop_token (exact JSON format, constraints, caching), and field (what it refers to). This adds significant value beyond the schema.

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?

The description clearly states the tool's purpose: 'Remove a single patron credential field' and 'Deletes one field from stored credentials without affecting other fields.' It distinguishes from sibling tools like update and forget by specifying it removes a single field, and the verb 'delete' contrasts with 'update' or 'forget'.

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?

The description explains when to use this tool: to remove a specific credential field, noting it is free and requires proof of npub ownership via dpop_token. It provides detailed authentication requirements but does not explicitly state when not to use it or compare to alternatives like authority_forget_credentials or authority_update_patron_credential.

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

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

With no annotations, the description carries the full burden. It discloses that two proofs are required, explains the consequence of missing authority_proof (unauthorized removal), and implies a destructive action. It does not mention reversibility or side effects, but is sufficient.

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?

The description is concise and front-loaded, with no wasted sentences. It efficiently communicates purpose, prerequisites, and security implications.

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?

Given the large sibling set, the description provides necessary context: purpose, required proofs, and a security note. Output schema likely covers return values, so completeness is adequate.

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 coverage is 67%. The description adds meaning for authority_proof beyond the schema, but does not describe dpop_token. npub's description in schema is sufficient. Overall, the description provides some added value but is not fully comprehensive.

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?

The description clearly states 'Remove an Operator from the DPYC community registry,' using a specific verb and resource. It distinguishes from siblings like authority_register_operator and authority_update_operator.

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?

The description explains the required proofs (proof and authority_proof) and their purpose, preventing unauthorized removal. It implicitly advises when to use the tool, though it doesn't explicitly contrast with alternatives.

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

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

With no annotations, the description carries full burden. It discloses the cosmetic nature and re-redeemability, but doesn't detail if it's idempotent, side effects on related data, or permission requirements. Adequate but not thorough.

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?

Three concise sentences with no redundancy. The most critical information is front-loaded, and every sentence adds value.

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?

Despite having an output schema, the description ignores return values. With 3 parameters and no annotation guidance, the description leaves gaps (e.g., what happens on failure, how to interpret response). Needs more detail.

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 coverage is 0%, so description must explain parameters. It only mentions npub (requires proof) and coupon_id implicitly, but does not explain either parameter's format or role. The dpop_token parameter is completely unmentioned.

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?

Clearly states it removes a coupon from a patron's redemption list, and adds that it's cosmetic only, distinguishing from full deletion. The verb 'remove' and resource 'patron's redemption list' are specific and unambiguous.

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?

Gives context that it's cosmetic and free, and requires npub proof. However, it doesn't explicitly state when to prefer this over sibling tools like authority_delete_coupon, though the cosmetic nature implies the distinction.

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

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

With no annotations provided, the description carries full responsibility and delivers exceptionally. It explicitly states the destructive nature ('deletion is as destructive as a write') and details the authentication mechanism (dpop_token requirements, u tag, nonce, etc.), providing complete transparency about security and behavioral constraints.

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?

The description is well-structured with a summary line and an 'Args' section, but it's slightly verbose. Every sentence adds value, though some details (like 'Free' at the end) are unclear and could be omitted or clarified.

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?

Given the complexity of the tool (destructive operation with authentication), the description is comprehensive. It covers what the tool does, when to use it, how to authenticate, and the effects. The presence of an output schema further reduces the need to describe return values.

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?

All three parameters are described in detail beyond the bare schema. For 'dpop_token', the description provides exact formatting instructions, validation rules (created_at, u tag, content), and caching hints, which is critical for correct invocation given the 0% schema coverage.

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?

The description begins with a clear verb 'Delete' and resource 'vaulted credentials for a specific service and npub', immediately conveying its purpose. It distinguishes itself from sibling tools like 'authority_delete_patron_credential' by focusing on forgetting credentials for any service and npub, not just patron 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?

The description provides context on when to use the tool (for operator vs. patron credentials) and emphasizes the requirement for proof of npub ownership. However, it does not explicitly say when NOT to use it or mention alternative tools, leaving some ambiguity.

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

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

With no annotations, the description must compensate. It notes that status values are 'not sensitive' and implies the operation is free and requires no proof, suggesting no authentication or cost. However, it does not disclose side effects, rate limits, or permissions, leaving gaps. Still provides some behavioral context beyond the tool name.

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?

Extremely concise: two short, front-loaded sentences. Every word adds value, with no redundancy. The structure efficiently conveys the core purpose and a behavioral note.

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?

Adequate for a simple read tool with output schema, but missing usage context relative to siblings. The ambiguity about whose status is read (caller vs. other operator) detracts from completeness.

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?

The input schema already has 100% coverage and clearly describes 'operator_npub' as the npub whose status to read. The description adds no extra meaning to this parameter, so it meets the baseline for full schema coverage.

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?

The description clearly states 'Read an operator's adoption-request status' and lists possible statuses. However, the mention of 'its ``adoption_status`` tool' creates ambiguity about whether this tool reads the caller's own status or another operator's, especially given the sibling tool 'authority_adoption_status'.

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?

No explicit guidance on when to use this tool versus alternatives like 'authority_adoption_status' or 'authority_list_adoption_requests'. The description vaguely implies this tool is for reading a specific operator's status by npub, but does not clarify use cases or exclusions.

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

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

With no annotations, the description clearly states the tool is read-only, free, and returns specific fields or empty profile. Adequately discloses behavior beyond the bare name.

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?

Two sentences, front-loaded with core action and standard, followed by important context. No wasted words.

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?

Given output schema exists, description of return fields is sufficient. Mentions empty profile case. Lacks error handling details but acceptable for simple read tool.

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 coverage is 0%, and description only mentions 'npub' in passing without explaining format (e.g., bech32), default behavior, or constraints. Fails to compensate for missing schema description.

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?

Clearly states it reads a public Nostr profile for an npub, specifies NIP-01 kind-0 metadata, and lists return fields. Distinguishes from sibling write tool (authority_publish_nostr_profile).

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?

Indicates it's free, requires no proof, and data is public, giving appropriate context for usage. Does not explicitly mention when not to use or alternatives, but implies read-only nature.

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

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

With no annotations, the description should disclose behavioral traits like side effects, authentication needs, or error handling. It only describes the action without mentioning if it is read-only, whether state is modified, or if specific permissions are required. This is a significant gap.

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?

The description is concise, with two focused sentences followed by parameter explanations. No extraneous content. However, the parameter listing could be better formatted (e.g., bullet points) for readability.

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?

Given the output schema exists, the description adequately covers the tool's purpose and parameters. It omits preconditions like requiring an existing notarization, but for a tool with two simple string parameters, it is largely complete.

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?

The description includes an 'Args' section that explains each parameter's meaning: notarization_id is a record ID, npub is a Nostr public key prefixed with 'npub1'. This adds clarity beyond the schema's basic string type, especially with 0% schema description coverage.

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?

The description clearly states the tool generates a Merkle inclusion proof for a patron's balance in a Bitcoin-notarized snapshot. It uses a specific verb-resource combination and distinguishes itself from siblings like authority_list_notarizations (listing) and authority_notarize_ledger (creating snapshots).

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?

The description implies usage for generating proofs given a notarization_id and npub, but does not explicitly state when to use this tool versus alternatives, nor provides any exclusion criteria or prerequisites. It is adequate but lacks guidance on context.

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

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

No annotations provided, so description carries full burden. It reveals the authentication requirement (Schnorr signature) which is a key behavioral trait. However, it does not state that the operation is read-only, nor does it disclose error handling or performance implications beyond the auth gate.

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?

Two short sentences: first states purpose, second adds critical gating info. No wasted words, front-loaded with essential information.

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?

Output schema exists, so return values are covered. However, the description lacks guidance on how to obtain the required Schnorr signature or what happens if authentication fails. For a tool requiring cryptographic proof, more context would be beneficial.

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 coverage is 50% (only npub has a description). The tool description does not mention either parameter, so it adds no meaning beyond the schema. The dpop_token parameter is undocumented in both schema and description, leaving a gap.

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?

The description clearly states the tool retrieves 'operator bootstrap configuration' including 'Neon URL, schema'. This is specific and distinct from sibling tools like authority_register_operator or authority_update_operator.

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?

It mentions the gating condition (Schnorr signature proof of npub ownership) but does not explicitly state when to use this tool versus alternatives like authority_get_operator_onboarding_status or authority_operator_status. Usage context is implied but not contrasted.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool reports configuration readiness and shows missing items with delivery instructions, but does not explicitly state that it is read-only, any authorization needs, or potential side effects. The term 'Free.' hints at no cost but is insufficient for full transparency.

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?

The description is three sentences, front-loaded with the primary purpose, and each sentence adds value. No redundant or extraneous information.

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?

For a simple parameterless tool with an output schema, the description fully explains what the tool does and provides an alternative use case. It is complete for its complexity level.

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?

The tool has zero parameters, and schema description coverage is 100% (trivially). Following the guidelines, baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.

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?

The description clearly states the tool reports 'configuration readiness' for an operator, elaborates on what it shows (configured/missing settings and how to deliver missing values), and distinguishes itself from the sibling tool 'get_patron_onboarding_status' which is for patron-level credential status.

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?

The description provides an explicit alternative: 'For patron-level credential status, use get_patron_onboarding_status instead.' It also implies usage for operator configuration readiness, and the word 'Free.' may indicate cost-free usage.

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

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

With no annotations, description fully discloses that the tool is free, exposes metadata only, and that the field list itself is sensitive. Details dpop_token requirements and timestamp behavior, leaving no ambiguity.

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?

Well-structured with clear separation of purpose, usage, and parameter details. While thorough, some technical dpop_token details could be condensed slightly, but overall efficient and front-loaded.

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?

Given output schema exists (has output schema: true), description need not repeat return structure. Covers purpose, parameters, behavior, and prerequisites completely for a metadata-list tool.

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 has no descriptions (0% coverage). Description compensates fully by defining npub as 'patron's Nostr public key' and dpop_token with extensive format, usage, and caching instructions, far exceeding schema information.

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?

The description clearly states the tool lists stored patron credential field names, not values. It distinguishes itself from sibling tools like authority_delete_patron_credential by specifying its read-only, metadata-focused nature.

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 says 'use this to verify which fields are configured and how old each one is' and details prerequisites (npub ownership proof, dpop_token format). Could mention alternatives for other operations, but context from sibling list implies them.

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

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

Discloses that proof of npub ownership is required and explains the output per service type. Does not explicitly state read-only behavior, but 'Report' implies no mutation. With no annotations, it adequately covers behavior.

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?

Structured with main sentence, service type bullets, note on free/requirement, and Args list. Slightly verbose ('Free.' standalone), but front-loaded with purpose and generally efficient.

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?

Given an output schema exists (not shown), the description covers what the tool reports for both service types and prerequisites. No gaps for a tool with two parameters and simple output.

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?

Both parameters are described clearly (patron_npub format, dpop_token event details). Schema coverage is 0%, so description fully compensates, adding meaning beyond the schema's type/requirement.

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 it reports patron credential readiness for the operator, distinguishing between set-once and dynamic services. Among siblings like authority_get_operator_onboarding_status and authority_get_patron_credential_fields, the purpose is clear and specific.

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?

Provides context on when to use by describing service types and prerequisites (proof of npub ownership). Does not explicitly state when not to use or name alternatives, but the differentiation between service types guides appropriate usage.

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

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

With no annotations, the description provides useful behavioral context: self-initialization if no model exists, cost ('Free.'), and limitation ('No economic data from code'). This goes 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.

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

Three concise sentences with no fluff. The purpose is front-loaded, and each sentence adds value (function, cost, behavior, limitation).

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?

Given the tool's simplicity (no parameters, output schema exists), the description covers the essential behavioral aspects. It could mention what the pricing model contains, but the output schema likely covers that.

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?

The schema has no parameters (coverage 100% by default). The description adds meaning by explaining the output (active pricing model) and initialization behavior, which is helpful beyond the empty schema.

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?

The description clearly states 'Get the active pricing model for this operator,' using a specific verb and resource. It distinguishes from siblings like 'set_pricing_model' and 'reset_pricing_model' by focusing on retrieval.

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?

The description implies usage as a getter, but does not explicitly state when to use it versus alternatives. The mention 'Free.' hints at cost implications, but no direct guidance on alternatives or exclusions.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It mentions the access restriction (owner consent) but does not explicitly state that the operation is read-only or non-destructive. Given the output schema exists, return format is handled, but behavioral safety beyond the context is not fully addressed.

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?

The description is two sentences long, with the first sentence immediately stating the purpose. No filler or repetition. Every word contributes to understanding.

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?

Given the simple input (one parameter) and presence of output schema, the description provides sufficient context: ownership restriction, queue nature, and the review surface. It does not elaborate on what happens if the caller is not the owner, but that is implied by 'restricted'.

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?

There is one parameter (authority_proof) with 100% schema coverage. The description adds 'consent proof' context but does not significantly expand on the schema's description. Baseline 3 is appropriate as the schema already explains the parameter well.

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?

The description clearly states the action ('list pending operator-adoption requests') and identifies the resource ('owner queue'). It differentiates from sibling tools like authority_approve_adoption or authority_receive_adoption_request by specifying it is for the owner and refers to pending requests, setting it apart as a read-only list.

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?

The description indicates that the tool is restricted to the Authority owner and is used for reviewing requests on your own time, implying it is for inspection rather than action. However, it does not explicitly contrast with alternatives for approval or rejection, though the context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Free, no side effects' at the end, which is exactly the kind of behavioral transparency expected. It also reveals important behavioral details: inclusion of unregistered tools with registered:false flags, drift detection against the live wire surface (issue #175), and the canonical-UUID behavior where mcp_name changes but tool_id stays. It doesn't describe output structure details, but the description covers the meaningful behavioral traits comprehensively.

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?

The description is thorough but front-loads the core purpose in the first line, then layers detail progressively (authoritative use case, then edge-case behavior, then drift detection). Every paragraph adds distinct value: identity semantics, unregistered handling, mcp_name vs tool_id stability, and wire-surface diffing. It's on the longer side but dense with necessary nuance—the version-reference and issue-number citations slightly inflate length without adding agent-relevant behavioral detail.

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?

This is a zero-parameter read-only introspection tool with an output schema and no annotations. The description covers: what it returns (canonical identities), its purpose (authoritative source), its edge cases (unregistered tools, registered:false), its semantic guarantees (tool_id stability across renames), and its safety profile (free, no side effects). For a tool of this complexity, the description is fully complete—there's nothing an agent would need to know that isn't stated.

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?

The tool has 0 parameters with 100% schema coverage (an empty object), so the baseline for parameter semantics is 4. The description adds no parameter info because there are none, and that's entirely appropriate—the description isn't expected to document parameters that don't exist. The introduction of 'tool_id, mcp_name' as output concepts adds value by priming the agent on what the return shapes are. Given zero params, this dimension is essentially N/A and deserves full marks.

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?

The description uses a specific verb+resource ('Return canonical (tool_id, mcp_name, …) for every tool the wheel exposes') that precisely states what the tool does. It distinguishes itself from siblings by clearly identifying itself as the authoritative identity source, contrasting with the operational tools in the sibling list (all authority_* operational functions). The 'canonical-UUID design' framing makes its distinct role unmistakable.

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?

The description explicitly states when to use this tool: 'The authoritative source for any client (Studio, agents, FE) that needs to know how this MCP identifies its tools.' It also names the specific consumer (Reconcile) and explains the exact usage pattern (UUID-join against stored pricing model, with explicit non-usage guidance: 'no name-based UUID derivation, no guessing'). This is exceptional guidance that clearly discriminates against alternatives.

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

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

With no annotations, the description carries full burden. It transparently states the tool is free (no credits), lists the returned fields (type, category, description, parameter specs), and implies a read-only operation. It does not disclose caching, authentication needs, or pagination, but for a simple listing tool, this is adequate. No contradictions.

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?

Two sentences: one clearly states the action and target, the second elaborates on the return value and cost. No filler, every sentence adds value. Front-loaded with the main purpose.

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?

Given zero parameters and existence of an output schema, the description sufficiently covers what the tool does and returns. It could optionally mention that no context or credentials are needed (given it's free), but the current description is complete enough for an agent to use correctly.

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?

The input schema has zero parameters, so the description's job is minimal. It does not need to explain parameters, but it usefully describes the output content (type, category, description, parameter specs), adding context beyond the schema. Baseline for 0 params is 4.

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?

The description explicitly states the tool lists all constraint types and their parameter schemas for a pricing pipeline. It clearly distinguishes itself from sibling listing tools (e.g., authority_list_coupons, authority_list_notarizations) by specifying the resource (constraint types) and the domain (pricing pipeline).

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?

The description mentions 'Free — no credits required,' which implies it's safe to use without cost concerns. However, it does not provide explicit guidance on when to use this tool versus alternatives like other listing tools, nor does it state prerequisites or when not to use it. The pricing pipeline context gives some direction but lacks thoroughness.

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

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

No annotations are provided, so the description carries full burden. It discloses listing behavior, ordering, and progress bar rendering from times_redeemed vs total_uses, and restricted access. However, it does not clarify the proof mechanism or explicitly state it is read-only.

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?

The description is concise (3 sentences), front-loaded with the primary purpose, and adds relevant detail about output fields and restrictions. No unnecessary content though slight restructuring could improve clarity.

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?

Given the existence of an output schema (not shown), the description partially covers output fields (times_redeemed, total_uses) but lacks explanation of the dpop_token parameter and does not reference the output schema structure. The agent would need to infer the response format.

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?

The schema has one parameter (dpop_token) with 0% coverage, and the description does not mention or explain it. The vague reference to 'requires proof' links to the token but lacks explicit semantics, adding minimal value beyond the schema.

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?

The description clearly states the action (list), the resource (coupons), and the scope (operator's minted coupons, newest first). It is specific but does not explicitly distinguish from sibling tools like authority_list_my_coupons, though the scope 'minted' differentiates it.

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?

The description notes that the tool is 'RESTRICTED to operator — requires proof,' indicating who can use it. However, it does not provide guidance on when to use this tool versus alternatives like authority_list_my_coupons or authority_check_proof_status.

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

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

No annotations are provided, so the description carries the full burden. It explains return content (active and exhausted redemptions with status field listing possible values) and notes the tool is free and requires npub proof. This is good but could mention rate limits or pagination.

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?

The description is two sentences: first states purpose, second adds return details and cost/auth. Every part adds value, no fluff.

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?

For a simple list tool with two parameters and an output schema, the description covers purpose, return structure, and auth requirement. It is complete given the tool's complexity.

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 0%, and the description does not explain the meaning or format of the parameters (npub, dpop_token). It only mentions npub proof in the auth context, not parameter details. This is insufficient for a 0% coverage scenario.

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?

The description clearly states the tool lists coupons redeemed by the patron on this operator, distinguishing it from general coupon listing (e.g., authority_list_coupons). The verb 'List' and resource 'coupons this patron has redeemed' is specific.

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?

The description indicates it is 'Free' and requires 'proof of npub,' providing context on cost and authentication. It does not explicitly state when to use alternatives, but the scope is clear enough for selection.

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

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

No annotations, so description carries full burden. It discloses restriction to owner and that it's a list (owner queue), but doesn't explicitly state read-only or behavior on invalid proof. However, it provides meaningful context without contradiction.

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?

Two sentences front-load key info: purpose, restriction, and relationship to sibling. No wasted words.

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?

Given output schema exists, return values not needed. Description covers purpose, restriction, and usage context with sibling. Complete for a list tool with single parameter.

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 coverage is 100% and parameter is described in input schema. Description adds no additional meaning about the parameter beyond what schema provides, so baseline 3.

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?

Description clearly states it lists operators reporting Neon-402 (specific error). Distinguishes from sibling 'network_persistence_health' by contrasting reactive vs proactive lists.

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 says 'Restricted to the Authority owner' and positions as companion to network_persistence_health, explaining when to use each (reactive vs proactive).

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

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

No annotations provided, so the description must carry full behavioral disclosure. It mentions 'recent' records but does not define recency, ordering, pagination, or authentication requirements. Key behavioral traits are missing.

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?

The description is concise with two sentences and a parameter list. It is efficiently structured but could benefit from a brief note on default behavior or sorting.

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, reducing the need to explain return values. However, the description lacks context on record ordering, pagination limits, or the meaning of statuses, which are important for correct use.

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 coverage is 0%, so the description provides the only explanation. It effectively describes limit with default and status with a usage hint ('submitted', 'confirmed'), though it could include a more exhaustive list of valid statuses.

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?

The description clearly states it lists Bitcoin notarization records, which identifies the specific resource. However, it does not explicitly differentiate from other list tools like authority_list_adoption_requests, relying on the resource name alone.

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?

No guidance on when to use this tool versus alternatives. With many sibling list tools, the description should indicate context or prerequisites for using authority_list_notarizations.

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

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

No annotations exist, so the description must disclose behavioral traits. It mentions the return value and restricted access, but lacks details on side effects, idempotency, or error handling.

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?

The description is concise with a one-line purpose and bulleted arguments, no redundant information.

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?

Given the presence of an output schema, the description covers purpose, parameters, and restrictions well; missing error handling but still highly informative.

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 0%, but the description explains 6 of 7 parameters with role and constraints (e.g., 'discount_percent: Percentage off the base price (0-100)'). Missing dpop_token description.

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?

The description states 'Create a new operator-owned discount coupon' with a specific verb and resource, clearly distinguishing it from sibling tools like update, delete, redeem.

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?

The description provides clear context with authentication requirements and parameter defaults, but does not explicitly state when to use versus alternatives among the many coupon-related siblings.

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

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

Describes the three layers and their availability (projects conditional, own_store always, operator_alerts reactive). No annotations exist, so description carries full burden; it discloses read-only behavior and conditions.

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?

The description is detailed but well-structured with bullet points and clear sections. Each sentence adds value, though slightly verbose for a health check tool.

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?

Given the tool's complexity (three layers, conditional availability) and the presence of an output schema, the description covers the essential functionality and constraints adequately.

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%, and the schema already documents the single parameter 'authority_proof'. The tool description adds no further meaning for this parameter beyond what the schema provides.

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?

The description clearly identifies the tool as 'the health of the DPYC economy's accounting store (Neon)' with three distinct layers, making it specific and distinct from the many authority_* sibling tools.

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?

States restrictions ('Restricted to the Authority owner') and explains the three layers with conditions (e.g., 'configured=false when no key is present'). Does not explicitly compare to alternatives, but usage context is clear.

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

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

With no annotations, the description discloses key behavioral traits: operator-only, background task, long confirmation time (1-6 hours), and no credit cost. This helps the agent understand the tool's non-immediate nature. It could mention error handling or permissions, but overall sufficient.

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?

Three concise sentences with the main action front-loaded. Every sentence adds essential information: what it does, who can use it, timing, and cost. No redundant words.

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?

For a no-parameter tool, the description covers the core action, timing, and access restrictions. The output schema likely handles return values. Could mention if it requires specific permissions or state, but overall adequate.

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?

No parameters exist, so no description needed. The schema coverage is 100%. Baseline score of 4 applies since the description adds no parameter information beyond the schema.

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?

The description clearly states the action: building a Merkle tree of patron balances and submitting the root to Bitcoin via OpenTimestamps. It distinguishes from sibling tools like authority_list_notarizations and authority_get_notarization_proof by specifying the exact operation.

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?

The description explicitly notes it is an operator-only background task, indicating who should use it and that it runs asynchronously. It mentions Bitcoin confirmation takes 1-6 hours and is free, providing context for when to invoke. However, it does not compare to alternative tools like authority_check_proof_status.

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

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

No annotations provided, so description carries full burden. It discloses critical behavior: proof of ownership requirement for explicit npub to prevent enumeration, and fallback to self-inspection. Also explains security rationale. No contradictions.

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?

Description is two sentences with a front-loaded purpose statement followed by concise details. No redundant or extraneous text. Every sentence adds value.

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?

With an output schema present, the lack of return value description is acceptable. However, the description omits any explanation of the dpop_token parameter and does not mention error conditions or prerequisites. Given the low complexity and sibling context, it is mostly complete but has a notable gap.

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 coverage is 50% (only npub described in schema). Description adds meaning to npub (proof requirement, fallback) but does not mention dpop_token parameter. Baseline for partially covered schema is 3; description compensates slightly but insufficiently for missing dpop_token context.

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?

Description clearly states the tool's function: 'View registration status, balance summary, and the Authority's Nostr npub.' The verb 'view' and specific resources differentiate it from sibling tools like authority_check_authority_balance.

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?

Describes two usage scenarios ('When an explicit npub is provided' vs empty) with clear reasoning for each. However, no explicit guidance on when to choose this tool over sibling tools or what prerequisites are needed.

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

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, output format, or side effects. 'Free' is vague and does not clarify behavior.

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?

The description is extremely concise (one sentence) but still conveys the core purpose efficiently. It could be slightly more informative without added length.

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?

Given no parameters and an output schema existing, the description provides minimal context. It explains the tool returns a description of the ecosystem, but 'via the Oracle' is ambiguous and no details on what the output covers.

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?

With zero parameters and 100% schema coverage, the description has no need to elaborate on parameters. The baseline of 4 is appropriate.

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?

The description clearly states the verb 'describe' and the resource 'DPYC ecosystem', and distinguishes from more specific oracle sibling tools like authority_oracle_get_tax_rate.

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?

The description implies this tool is for a general overview of the ecosystem, but does not explicitly state when to use it over siblings or provide any when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as getting a tax rate and being free, but does not disclose behavioral traits such as read-only nature, idempotency, or rate limits. Minimal but adequate for a simple query.

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?

The description is extremely concise: a single sentence that immediately states the purpose. No wasted words.

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?

Given that there are no parameters and an output schema exists (though not detailed), the description is mostly complete for a simple query tool. It could mention edge cases or return format, but brevity is acceptable.

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?

There are zero parameters, so baseline is 4 per rubric. The description does not add parameter information because none is needed, and schema coverage is 100%.

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?

The description clearly states the tool's purpose: 'Get the current DPYC certification tax rate.' It specifies the resource (DPYC certification tax rate) and the action (get), making it distinct from sibling tools. The inclusion of 'Free.' adds helpful context.

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?

No explicit guidance on when to use this tool versus alternatives is provided. As a simple getter with no parameters, usage is implied but there are no exclusions or alternatives mentioned.

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

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

With no annotations, the description should disclose behavioral traits. It only states 'Get' and 'Free', implying a read-only operation but lacking explicit details on side effects, return behavior, or required permissions.

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?

The description is very short with two fragments, which is concise. However, the second fragment 'Free.' is not necessary and could be integrated. Front-loaded adequately.

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?

Given zero parameters and an existing output schema, the description is sufficient for a simple retrieval tool. It could mention what the instructions contain, but the output schema likely covers that.

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?

No parameters exist, so schema coverage is 100%. The description adds no value beyond the schema, meeting the baseline of 3.

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?

The description clearly states it retrieves 'DPYC onboarding instructions', specifying the resource. However, it does not explicitly differentiate from sibling oracle tools like 'authority_oracle_about', though the unique action is implied.

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?

No guidance on when to use this tool versus alternatives. The description only says 'Free', which is not usage advice. No context on prerequisites or scenarios.

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

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

No annotations provided, so description must bear full burden. Only mentions 'Free' but does not disclose other behavioral traits such as rate limits, idempotency, or any side effects. Minimal disclosure for a lookup operation.

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?

Extremely concise with two short sentences. Front-loaded with the core action. Every word is justified; 'Free' may be helpful but is not redundant.

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?

Given the tool's simplicity (single string parameter, output schema exists), the description is minimally adequate. However, it fails to explain what the output contains (e.g., member details) or any special behavior, leaving some gaps for an AI agent.

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?

Single parameter 'npub' with 0% schema description coverage. Description only says 'by npub' without explaining format, constraints, or what 'npub' represents (likely a Nostr public key). Adds little value beyond the parameter name.

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?

Description clearly states the action ('Look up'), resource ('DPYC community member'), and identifier ('by npub'). It is specific and distinguishes from siblings like authority_get_nostr_profile which likely retrieves a profile rather than a community member lookup.

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?

No guidance on when to use this tool versus alternatives among many sibling tools. Lacks context such as prerequisites or scenarios where other tools (e.g., authority_check_dpyc_membership) might be more appropriate.

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

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

No annotations are provided, so the description must convey behavioral traits. It mentions 'Free' but does not disclose whether the operation is read-only, idempotent, requires authentication, or has rate limits. The agent lacks key behavioral context.

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?

The description is extremely concise: one sentence plus the word 'Free' adds a helpful hint. It is front-loaded and wastes no words.

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?

Given the tool has no parameters and has an output schema (which likely documents return values), the description is adequate for basic understanding but lacks broader context such as what constitutes a 'network advisory' or when to invoke this tool.

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?

There are zero parameters and 100% schema coverage, so the description does not need to elaborate on parameters. A baseline of 4 is appropriate as no parameter information is missing.

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?

The description clearly states the verb 'Get' and the resource 'active network advisories' from the Oracle. Among siblings, it is distinct; no other tool appears to fetch network advisories, so its purpose is unambiguous.

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?

No guidance on when to use this tool versus alternatives. The word 'Free' hints at no cost but does not address prerequisites, typical use cases, or exclusions.

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

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

With no annotations, the description carries full burden. It discloses the flow: frontend signs, wheel verifies, relays. It explicitly states no key custody, signature as authorization, and that it's free. Missing details on failure modes or rate limits, but sufficient for core behavior.

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?

The description is relatively concise, with key behavioral points and parameter definitions. The front-loaded sentences explain the process clearly. Minor redundancy in the args section but overall efficient.

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?

The description covers the purpose, parameters, and process well. The output schema exists (not shown) so return values need not be described. Lacks error handling details, but for a publish tool with good parameter descriptions, it is reasonably complete.

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?

The JSON schema has no parameter descriptions (0% coverage), so the description fully compensates. It defines npub as the public key the event must be signed by, and signed_event as a JSON-encoded client-signed kind-0 event. This adds critical meaning beyond the schema.

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?

The description clearly states the tool publishes a client-signed kind-0 profile to relays for an npub. The verb 'publish' and resource 'kind-0 profile' are specific, and the tool is distinct from siblings like authority_get_nostr_profile.

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?

The description explains when to use: when a client-signed kind-0 event is available and needs relaying. It mentions that the signature is the authorization and that the wheel does not hold keys. However, it does not explicitly exclude other scenarios or compare with sibling tools.

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

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

No annotations provided, so description carries full burden. It discloses that it creates a Lightning invoice, requires npub proof, and specifies the dpop_token format in detail, including validation rules. It transparently describes the flow without contradictions.

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?

The description is well-structured with a lead sentence and clear parameter explanations. It is slightly lengthy but every sentence adds value. Could be slightly more concise, but overall very good.

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?

Given that an output schema exists (not shown but context indicates true), the description covers all essential aspects: creation, payment, confirmation, and prerequisites. It is complete for a purchase tool with a follow-up step.

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 0%, so description adds all parameter meaning. It explains npub (Nostr public key), dpop_token (detailed construction rules), and amount_sats (default 1000). This goes far beyond the schema's minimal type info.

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?

The description clearly states 'Buy credits via Bitcoin Lightning' and explains the process of creating a Lightning invoice, paying it, and then calling check_payment. It distinguishes itself from siblings like authority_check_payment by describing the necessary next step.

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?

The description explicitly says when to use this tool ('Buy credits'), mentions prerequisites ('Proof of npub ownership is required'), notes it is free ('No credits required to call'), and advises calling check_payment after payment.

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

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

Describes verification (inline Schnorr bound to sentinel, no relay), durable record (pending row), and side effect (best-effort owner DM). Lacks details on idempotency, duplicates, or error handling, but covers core behavior well given no annotations.

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?

Three concise sentences front-loaded with purpose. Each sentence adds distinct value (who calls, what it does, what it does not do). No redundant or vague phrasing.

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?

Given the tool's complexity (3 params, output schema exists), the description covers key aspects: verification, persistence, notification, and what it does not do. It could mention preconditions (e.g., operator not already adopted) but overall sufficient for correct invocation.

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 coverage is 100% (all three parameters have schema descriptions). The description adds marginal context (e.g., dpop_token bound to adoption sentinel) but does not significantly augment the schema explanations. Baseline of 3 is appropriate.

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?

The description clearly states "record an operator's request to be adopted by this Authority" using a specific verb-resource pair. It distinguishes from sibling tools like authority_approve_adoption and authority_request_adoption by noting it is MCP-to-MCP and complements the approval step.

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 it is called by the operator's request_adoption (MCP-to-MCP), implying not a direct user call. Clearly says "Does NOT provision — provisioning waits for the owner's approve_adoption", giving a when-not-to-use guideline. Context is clear that it is part of a multi-step adoption flow.

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

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

No annotations, so description carries full burden. Details deterministic drain of only the pinned relay, deletion of wrong DMs, first-match acceptance, and result on no match. Also explains credential_card bypass and client reinitialization.

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?

Well-structured with overview, usage notes, and parameter list. Front-loaded with purpose. Slightly verbose but every sentence adds value.

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?

Covers all essential behavior, parameters, and effects. Output schema exists but is not described; however, description is complete for invoking the tool.

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 coverage is 0%, but description adds detailed meanings: sender_npub is required, dpop_token is session phrase, credential_card is optional and bypasses relay. Beyond schema defaults.

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?

Description states 'Pick up credentials from the Secure Courier' and specifies it completes the CREDENTIAL-DELIVERY flow, distinguishing it from the sibling 'receive_npub_proof'. The verb 'receive' and resource 'credentials' are clear.

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 'Call this only after the user confirms they have replied' and 'Do NOT poll, loop, or retry'. Provides deterministic one-shot retrieval behavior and conditions for using the credential_card path.

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

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

No annotations provided, so description carries full burden. Discloses key behaviors: verifies npub via inline Schnorr, records a durable state row, and fires a best-effort notification DM. However, does not mention error handling, idempotency, or failure modes (e.g., what happens if verification fails). Adequate but could be more detailed.

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?

Description is well-structured: opens with a clear purpose, then explains protocol. It is front-loaded with the main action. Slightly verbose with phrases like 'This is how the Authority learns...' but overall efficient and earns its sentences.

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?

Given the tool's complexity (incoming alert with verification and state recording), the description covers purpose, trigger, verification, and consequences. Output schema exists (not shown) but that's acceptable. Does not mention error responses or idempotency, but overall sufficiently complete for an experienced agent.

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 baseline is 3. The description adds context for 'dpop_token' (kind-27235 proof bound to wire name), which adds value beyond schema, but otherwise repeats schema info. No significant enhancement, so score remains at 3.

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?

The description clearly states the tool's purpose: handling an inbound alert from an operator reporting a Neon store 402-locked. It specifies the verb 'receives', the resource 'neon_402_alert', and distinguishes it from sibling tools by describing a specific protocol flow (MCP-to-MCP, verification, state recording, notification).

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 when this tool is used: 'the instant it catches a Neon HTTP 402' and mentions it's called by the operator's runtime. Provides context ('BEFORE a patron files a complaint'), but does not include explicit when-not-to-use or alternatives. Given the tool's specific nature, the guidance is clear.

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

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

Even without annotations, the description details deterministic one-shot retrieval, draining only the pinned relay, stopping at matching DM, deleting mismatched DMs without revealing expected phrase, and that the proof is stored hashed. It also explains the returned dpop_token must be reused and that the tool is free.

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?

The description is well-organized with clear sections and warnings, but it is somewhat lengthy. However, every sentence adds value and the structure is logical, so it earns a 4.

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?

Given the tool's role in a multi-step flow, the description covers prerequisites, flow context, behavioral details, output (dpop_token), and post-actions (remembering the token). With an output schema present, return value explanation is sufficient.

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?

Despite 0% schema coverage, the description's 'Args' section explains both parameters: patron_npub is the patron's npub to receive proof from, and dpop_token is the token returned by request_npub_proof. It also clarifies they are required, adding value beyond the schema.

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?

The description clearly states the tool receives npub ownership confirmation from a patron, completes the npub-OWNERSHIP-PROOF flow, and distinguishes itself from the sibling 'receive_credentials' by noting it is the credential-delivery counterpart.

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?

Explicit guidance to call only after user confirms reply, warnings against polling/looping/retrying, and clear statement that calling before user replies will never find the message. It also references the sibling 'receive_credentials' for contrast.

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

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

With no annotations provided, the description fully discloses behavior: looks up coupon by code, validates window and cap, records redemption row, auto-applies discount, is free, idempotent, and requires npub. No contradictions or omissions.

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?

The description is six well-structured sentences, each adding unique value: core action, process, side effect, cost, prerequisite, idempotency. No wasted words.

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?

With an output schema present, the description does not need to explain return values. It covers input semantics, behavioral details, constraints, and side effects sufficiently for correct tool invocation.

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?

The description explains two of three parameters (code as coupon name, npub as proof of identity) but does not mention dpop_token. Given zero schema description coverage, the addition is substantial but incomplete for one parameter.

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?

The description clearly states the tool redeems a coupon by code, explaining the lookup, validation, and recording process. It distinguishes itself from sibling tools like mint, delete, update, and list coupons by focusing on redemption and its side effects (auto-applied discount).

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?

The description clearly indicates when to use (to claim a coupon) and prerequisites (proof of npub). It does not explicitly mention alternatives or when not to use, but the sibling tool names implicitly cover that ground.

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

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

With no annotations, the description must disclose behavior. It states it sends a Nostr DM challenge, but does not mention if the operation is idempotent, what side effects occur, or what permissions are needed. The return value and state changes are not described.

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?

The description is a single concise sentence that front-loads the step number and action. Every word contributes to understanding; there is no waste.

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?

For a simple tool with one parameter and an output schema, the description covers the basic action but lacks details on return values, preconditions, and whether it can be called multiple times. It is adequate but has gaps.

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 coverage is 100% (one parameter fully described in the schema). The description does not add any additional meaning beyond what the schema already provides for 'candidate_npub'. Baseline score of 3 is appropriate.

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?

The description clearly states the tool's purpose: it is step 1 of 3 in Authority onboarding, sending a Nostr DM challenge to the candidate. This provides a specific verb and resource, but does not explicitly differentiate it from sibling tools like authority_register_operator.

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?

The description implies it is part of a sequence ('Step 1/3 of Authority onboarding') but offers no explicit guidance on when to use it, when not to, or what alternatives exist. There is no mention of prerequisites or conditions.

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

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

With no annotations provided, the description fully discloses behavioral traits: it is idempotent, requires two independent identity proofs, and explains how each proof is generated. This level of detail is highly transparent for a complex tool.

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?

The description is longer than average but well-structured with bullet points and clear sections. Given the complexity of the tool (two proofs, idempotency), the length is justified and not excessive.

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?

The description covers prerequisites, behavioral details (idempotent), parameter context, and next steps. An output schema exists, so not detailing return values is acceptable. It is complete for the tool's complexity.

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?

The schema covers 80% of parameters with descriptions. The description adds significant context for authority_proof (explaining its origin and usage) and the two-proof system, going beyond schema. The dpop_token parameter lacks description but is partially explained in context.

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?

The description clearly states the tool provisions an operator in the Authority ledger, explaining it creates a ledger entry for purchasing credits and certifying purchase orders. It distinguishes itself from sibling tools like authority_purchase_credits and authority_deregister_operator by being the provisioning step.

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?

The description outlines prerequisites (two Schnorr proofs) and mentions the next step (purchase_credits), providing context for when to use the tool. It does not explicitly list when not to use, but the details effectively guide appropriate usage.

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

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

No annotations provided, and the description only mentions rejection with no side effects, notifications, or state changes disclosed. Insufficient behavioral information for a mutation tool.

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?

Single sentence of 7 words, no redundancy, front-loaded with action and object.

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?

Output schema exists but is not described; tool is a mutation with 3 parameters and no context about return values or post-conditions. Incomplete for safe usage.

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 coverage is 100%, so baseline applies. Description adds no extra meaning beyond the parameter descriptions already in the schema.

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?

The description clearly states the action (reject), the resource (pending operator-adoption request), and the context (owner consent), distinguishing it from siblings like authority_approve_adoption.

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?

No guidance on when to use this tool vs alternatives (e.g., approve_adoption, list_adoption_requests). The description lacks context for decision-making.

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

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

With no annotations provided, the description carries full burden. It details the actions (ownership reassignment and grant restoration), what is not done (password rotation, bootstrap DM), and states idempotency. However, it does not explicitly mention potential side effects or prerequisites for the operation, slightly reducing transparency.

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?

The description is concise and well-structured: a one-line summary of the action, followed by a contextual explanation and differentiation from sibling tools. Every sentence adds value, with no redundancy or fluff.

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?

Given the complexity of the repair operation, the description adequately explains the problem, solution, and key behavioral properties (idempotency). The return value is covered by the existing output schema. However, it does not clarify whether parameters are required or how to obtain the authority proof, which could be improved.

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 coverage is 100% with clear parameter descriptions, so baseline is 3. The tool description does not add further meaning to the parameters beyond what the schema already provides, thus scoring a 3.

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?

The description clearly states the tool's action: 'reassign every table in an operator's tenant schema to the operator's own role, then re-grant DML.' It also distinguishes itself from the sibling tool 'register_operator' by explicitly stating what it does not do, providing a clear and specific purpose.

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?

The description explains the problem (operator cannot CREATE INDEX due to ownership issues) and explicitly contrasts with the sibling tool 'register_operator' by noting that this tool does not rotate passwords or send bootstrap DMs. It also states the tool is idempotent, guiding the agent on when to use it and what to expect.

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

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

The description discloses key behavioral traits: the report is public, goes to maintainers, nothing is verified, and a fee is charged to prevent abuse. It also details the dpop_token requirements and the return behavior (issue details or 'not configured' situation). Since no annotations are provided, the description fully carries the transparency burden.

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?

The description is well-structured with a clear purpose upfront, followed by context and parameter details. It is slightly verbose but each sentence adds value. Minor trimming could improve conciseness, but it remains effective.

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?

The description is comprehensive given the tool's complexity: it covers purpose, usage context, behavioral details, return values (issue repo, number, url), error handling, and parameter semantics. The presence of an output schema (confirmed via context signals) further reduces the need for description of return values, but the description already provides that.

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?

Despite 0% schema description coverage, the tool's description contains an 'Args:' section that explains each parameter in detail, including format specifics (dpop_token must be raw JSON, not base64), purpose, and optional status (tool_name). This adds significant meaning beyond the schema's property names and types.

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?

The description clearly states the tool's purpose: filing a field report about this service as a GitHub issue. It uses a specific verb ('file') and resource ('field report as a GitHub issue'), and it distinguishes itself from sibling tools which focus on authority management rather than issue reporting.

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?

The description provides clear guidance on when to use the tool ('Found a tool's metadata or response wrong or confusing?') and explains prerequisites (npub, dpop_token) and conditions (operator must have enabled field reports). However, it does not explicitly mention when not to use it or suggest alternatives, which would improve clarity.

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

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

With no annotations, the description carries full burden. It explains the process (resolves endpoint, mints proof, delivers request) and notes the deferred approval. However, it lacks details on side effects, error states, or permissions beyond ownership proof, leaving some behavioral gaps.

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?

The description is structured with a clear lead sentence, explanatory paragraph, and parameter list. It is slightly verbose with jargon like 'deferred courtship' and 'MCP-to-MCP', but remains efficient and front-loaded.

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?

Given the tool's complexity (4 params, output schema, many siblings), the description covers the workflow well, including linkage to 'adoption_status'. It explains the deferred nature and prerequisite proof. Missing details on error handling or output format, but the output schema exists to fill that need.

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?

Given 0% schema description coverage, the description fully compensates by explaining each parameter's meaning and role, e.g., 'authority_npub: npub of the Authority to request adoption from' and 'dpop_token: operator-npub ownership proof...' This adds essential context beyond the bare schema.

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?

The description clearly states the tool's purpose: 'Ask a chosen Authority to adopt this operator (deferred courtship).' It distinguishes from siblings by focusing on the operator initiating adoption, while related tools like 'authority_adoption_status' or 'authority_approve_adoption' cover other aspects.

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?

The description explicitly restricts usage to the operator ('RESTRICTED to the operator') and mentions required proof. It suggests polling 'adoption_status' for progress. However, it does not explicitly describe when to avoid using the tool or provide direct alternatives beyond implied sibling tools.

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