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

The description discloses key behaviors beyond the readOnlyHint annotation: it returns 'last known balance' from a credential store, performs no network request, and explains the condition for the 'stale' flag (updated more than 5 minutes ago). This adds meaningful context that annotations alone don't provide.

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 concise sentences deliver all essential information: the action, the caching behavior, and the staleness rule. Every sentence earns its place with no redundancy or filler.

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 one-parameter tool with no output schema, the description explains the return concept (balance and stale flag) sufficiently well. It stops short of detailing the full response structure or edge cases (e.g., no cached value), but given the simplicity, this is a minor 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 description coverage is 100% and the only parameter 'origin' already has a clear description with a URI format and example. The description adds no additional parameter-specific meaning, so the 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 states a specific verb and resource: 'Check cached credit balance for a server.' It distinguishes this tool from siblings by emphasizing that it uses a cached value and makes no network request, which sets it apart from other l402 tools like l402-fetch or l402-pay.

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 implies when to use this tool: when you want a fast, cached balance check without network overhead. However, it doesn't explicitly name alternatives or state when not to use it, so it lacks explicit exclusions that would merit a 5.

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?

Annotations already flag destructiveHint=true and openWorldHint=true, so the safety profile is handled. The description adds the mode behavior and the toll-booth restriction, but it does not clarify side effects of a purchase, such as spending funds, irreversibility, or error/response 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?

Three short sentences front-load the purpose and immediately state the key branching behavior. Minor redundancy exists between 'from a toll-booth server' and 'Only works with toll-booth servers,' but overall it is tight.

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 three-parameter tool with no nested objects, core invocation is covered: required URL, optional method, optional amountSats, and the toll-booth constraint. However, there is no output schema and the description does not say what a successful purchase or tier-discovery response contains, which is a notable gap for a financial operation.

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

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

Schema description coverage is 100%, so the baseline is 3. The narrative about omitting/providing amountSats adds a little clarity, but it largely repeats the schema's description of amountSats and does not enrich method or url beyond what the schema already says.

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 opens with a specific action ('Buy credits') and identifies the resource ('a toll-booth server') and a differentiator ('volume discounts'). It distinguishes this from sibling payment tools by restricting it to toll-booth servers, though it never names a sibling explicitly.

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 branching guidance: omit amountSats to discover tiers, provide amountSats to buy a specific tier, and only works with toll-booth servers. This gives clear when-to-use context, but it does not compare against siblings such as l402-pay or l402-discover, so it falls just short of a 5.

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

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

Annotations declare readOnlyHint=true, which the description aligns with by using 'Introspect'. The description adds value beyond the annotation by revealing what kind of read-only data is returned: wallet configuration, spending limits, and credential count. No hidden mutation or side effects are suggested.

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 tight sentences with no filler. The first sentence states exactly what the tool does and its outputs; the second gives actionable usage guidance. Every clause earns its place.

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 no parameters and no output schema, the description sufficiently explains what the tool returns at a categorical level. It could be more explicit about output format or whether any setup is required, but for a zero-input introspection tool it is adequately complete for an agent to call it 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 tool has zero parameters, so there is no schema burden to compensate for. The description accurately describes the tool's no-input introspection behavior, and the baseline of 4 is appropriate since no parameter documentation 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?

Description uses specific verb 'Introspect' with resource 'payment capabilities' and enumerates concrete outputs: wallets configured, spending limits, stored credential count. The instruction to call this first also distinguishes it from sibling tools like l402-pay or l402-fetch, making its role 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?

It explicitly says 'Call this first to understand what payment methods are available', giving clear context for when to invoke it. It does not explicitly list alternatives or when not to use it, but the sequencing guidance and broad discovery purpose sufficiently differentiate it from 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?

The readOnlyHint annotation already marks it safe, and the description adds genuinely useful behavior: balances are cached and possibly stale, and the lastUsed timestamp is the way to judge freshness. This is beyond the annotation and gives the agent a realistic expectation of data reliability. No contradiction exists.

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 tight sentences front-load the action and displayed fields, then add the stale-balance caveat. Every sentence carries operational value, and no redundant filler is present.

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 zero-parameter, read-only listing tool, this description is complete: it says what is listed, what fields are shown, and warns about cache freshness. The lack of an output schema is mitigated by naming the visible fields, and there are no params/options whose behavior would need elaboration.

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 is empty (0 parameters), so there are no parameter semantics for the description to enrich. With schema coverage at 100%, the description cannot add anything parameter-related, and the baseline of 4 applies.

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

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

States the action ('List all stored L402 credentials') and the resource/scope precisely, then names the displayed fields (origin, cached credit balance, server type). This distinguishes it from siblings like l402-store-token or l402-balance by focusing on stored credentials rather than operations or current 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?

Usage is only implied: an agent can infer this is for inspecting stored credentials, and the 'cached/may be stale' caveat hints that l402-balance might be the alternative for fresh numbers. However, it never explicitly states when to prefer this tool or names an alternative, so it stops short of clear routing 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?

With readOnlyHint=true and openWorldHint=true already present, the description adds meaningful behavioral details: no payment is committed, the challenge is cached for later reuse, and responses include pricing and payment-method information. It does not contradict the annotations and gives enough context for safe usage.

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 compact and front-loaded: the core action appears first, followed by return-value highlights and the caching behavior. Every sentence earns its place without fluff or repetition.

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 probe tool with one required parameter and no output schema, the description covers what the tool returns, when to use it, and the relevant caching side effect. It does not specify failure behavior or non-L402 endpoints, but those are minor gaps given the overall clarity.

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 the schema already documents both parameters and their defaults. The description reinforces that 'url' is the endpoint being probed but adds little about 'method' beyond what the schema provides. 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 uses a specific verb ('Probe') and resource ('endpoint') and states the purpose: discover L402 pricing without payment. It also names concrete outputs (cost in sats, payment methods, credit tiers) and distinguishes itself from l402-pay by mentioning challenge caching. This makes the tool's role clear even among many siblings.

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 implies the tool is a pre-payment discovery step: 'without committing to payment' and 'a subsequent l402-pay can reuse it' provide strong context for when to use it. It does not explicitly enumerate exclusions or alternative tools, but the intended workflow is evident.

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?

Annotations only signal openWorldHint and destructiveHint; the description carries the burden and does so well. It discloses that the tool manages credentials, pays automatically when autoPay is true and cost is within budget, retries, and returns different payment artifacts depending on wallet type. This goes far beyond the generic annotations and warns of spending behavior without contradicting them.

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 dense and front-loaded, with each sentence contributing to core behavior or routing. It is longer than strictly necessary—'Set autoPay to true for seamless access' partly repeats the schema—but the extra scenario-based guidance is earned rather than filler.

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 complex, spend-capable tool with no output schema, the description covers the high-risk and non-obvious payment paths: automatic payment, human-wallet returns, x402 verification via txHash, tier handling, and preview flow. It does not explicitly describe the normal successful fetch response body or exact retry/budget limits, but it provides enough context for correct invocation in the main scenarios.

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 the baseline is 3. The description adds value by explaining the behavioral effect of autoPay (automatic payment within budget), txHash (replays the request with X-Payment header), and how responses differ for human wallets vs x402 services. It does not add much for url, body, method, headers, or pubkey, but those are already well-described 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 opens with a specific action: 'Fetch a URL with automatic payment handling' and enumerates the supported payment protocols (L402 Lightning, x402 on-chain, ecash and LUD-25). It also differentiates itself from siblings by routing tiered payments to l402-buy-credits and widget-host flows to l402-fetch-preview, so an agent can distinguish it without opening other tool definitions.

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 gives explicit if-then usage guidance: when a 402 response includes tiers, present pricing and use l402-buy-credits; widget hosts should call l402-fetch-preview first. It also explains when autoPay should be true and distinguishes human-wallet flows from x402 flows, which is strong practical routing 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?

Annotations already declare readOnlyHint=true, so the description's claim of 'without spending any sats' reinforces but adds specific meaning (no financial side effect). It also describes what the tool returns (cost, protocol, payment method) and the intended UI usage, which goes beyond the annotation. However, it does not mention potential errors or connection issues, a minor gap given the annotations cover safety.

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 the primary purpose, and no filler. The usage guidance is embedded efficiently. Every clause earns its place.

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 preview tool with read-only annotations, the description covers the core purpose, return data, and usage context. It does not describe the exact output schema (since none exists), but that is compensated by stating the key fields. Minor gaps like error handling or authentication requirements are not addressed, but given the simplicity, 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?

Schema description coverage is 100%, so each parameter is already documented. The description adds no parameter-specific usage detail beyond what the schema provides. It does not explain how to format arrays or headers, but the schema already covers that. Thus, 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 states a specific verb ('Preview'), resource ('payment requirements for a URL'), and outcome ('without spending any sats'). It clearly distinguishes from l402-fetch by positioning itself as a pre-check. The purpose is unambiguous and actionable.

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 instructs to 'Use this before l402-fetch' and gives the condition (to give the user a chance to approve or cancel payment). Also mentions the widget host context. This directly routes the agent to the correct tool and tells when not to use the alternative.

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?

Beyond the annotations, the description discloses meaningful runtime behavior: it 'polls the payment server for settlement' and can block 'up to 30s for human wallet,' and it stores a credential as a side effect. This adds real context about latency and state mutation without contradicting the openWorldHint/destructiveHint 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?

The description is three sentences with no filler. It front-loads the essential action, then gives the triggering condition, timing behavior, and a human-wallet special case. Every sentence earns its place.

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 consequential payment tool with no output schema, the description covers preconditions, blocking behavior, side effects, and sequencing well. It doesn't describe failure modes or return values, but the annotations and sibling context (l402-fetch, l402-discover) fill most 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 description coverage is 100%, so the schema already documents all four parameters in detail. The description references paymentHash and the cached-challenge flow, but it doesn't add parameter meaning beyond what the input schema provides, so the 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 opens with a clear verb+resource pair, 'Confirm payment and store credentials,' and then anchors the tool's role to a concrete trigger: 'Call this after l402-fetch returns a 402 with a paymentHash.' This specific integration point makes it easy to distinguish from siblings like l402-fetch or l402-store-token.

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 provides explicit when-to-use guidance: after l402-fetch returns a 402, and it adds a temporal nuance for human wallets ('call this immediately after showing the payment URL to the user'). It doesn't enumerate alternative tools or explicit when-not-to-use conditions, so it falls just short of a 5.

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

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

Beyond the annotations, the description reveals an important behavioral trait: it automatically handles the two-step flow of creating an invoice then redeeming the token. It also clarifies that the tool only works against toll-booth servers. It does not detail the destructive consumption of the Cashu token, but destructiveHint=true already signals the mutation risk.

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, front-loaded with the core purpose, and contains no fluff. The only minor inefficiency is repeating the toll-booth-server constraint in both the first and final 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?

For a two-parameter tool with no output schema, the description covers the main selection criteria, the target server type, and the internal two-step flow. It does not specify return values or post-redemption behavior, but the annotations and simple parameter surface make this a minor gap rather than a blocking one.

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 documents both parameters with 100% coverage, so the baseline is 3. The description adds contextual flow details but no additional parameter-level meaning beyond what the schema already 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 opens with a specific verb and resource: 'Redeem Cashu ecash tokens directly on a toll-booth server', and adds a clear differentiator by noting it avoids the Lightning round-trip. It also closes with a scope limitation ('Only works with toll-booth servers'), making it easy to distinguish from siblings like l402-pay or l402-fetch.

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 gives useful context for when to choose this tool: it is for direct Cashu redemption on toll-booth servers, avoids Lightning, and automates the two-step flow. It does not explicitly name alternative sibling tools or state 'use X instead', but the toll-booth-only constraint and direct-vs-Lightning framing provide adequate selection 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?

Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral context: it describes the source (Nostr), the returned data (URLs, pricing, capabilities), and the overall purpose. There is no contradiction, and the description enriches the safety profile by clarifying the read-only nature and what to expect from results.

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, front-loading the purpose and usage condition. It is tightly written with no fluff, and each sentence adds value: the first defines the tool, the second provides usage context and the next step. Excellent structure and economy.

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 (6 parameters, no output schema, openWorld), the description covers the essential aspects: what it does, when to use it, and what it returns. It does not detail the relay mechanism or failure modes, but those are less critical for invocation. The combination of schema and description is sufficient for correct use, so a 4 is appropriate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add much beyond the schema; it echoes the search intent but does not explain individual parameters or their nuances. Since the schema fully documents each parameter, the description's contribution is minimal, so this score is justified.

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 function: 'Search for paid APIs and services' with specific details about discovering services on Nostr and returning URLs, pricing, and capabilities. It uses a specific verb and resource, and the context differentiates it from the fetch tool by emphasizing the search/discovery role.

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 gives explicit guidance on when to use it: 'Use this when the user wants something that might be available as a paid service'. It also mentions a follow-up action ('Then use l402-fetch with the URL'), but it does not explicitly exclude alternatives like l402-discover. Since it provides clear context without full differentiation, a 4 is 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?

The description adds behavioral context beyond the idempotentHint annotation by stating the token is persistently 'stored as a credential' and that this makes subsequent l402-fetch calls authenticated. It does not contradict the annotations; the readOnlyHint=false aligns with the mutation implied by 'Store.'

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 with no wasted words. It front-loads the core action, then provides the usage trigger and downstream benefit, making it easy for an agent to parse quickly.

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 two-parameter store operation, the description covers what the token is, where it comes from, and why it matters. It does not describe the return value or error behavior, but given the simple side-effect model and the idempotentHint annotation, this is a minor gap rather than a blocking omission.

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 with clear descriptions for both parameters, including the token format 'macaroon:preimage'. The description reinforces the token format and purpose but does not add meaningfully beyond the schema's parameter descriptions.

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 a specific verb and resource: 'Store an L402 token (macaroon:preimage) obtained from a payment page.' It also clarifies the token's role as a stored credential for authenticating subsequent l402-fetch calls, making the purpose unambiguous and distinguishable from sibling tools like l402-credentials or l402-fetch.

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 gives an explicit trigger: 'Use this when a user pastes back a token from a toll-booth payment page.' It also explains the downstream effect by noting the token is stored for later l402-fetch authentication, but it does not explicitly mention alternatives or cases where this tool should not be used.

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