Blink MCP Server

Official

by blinkbitcoin

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation4/5
Tools are mostly distinct by resource and action, with clear descriptions for similar operations like invoice creation and payment. Some pairs (get_account_info vs get_wallets, send_to_wallet vs send_to_username) overlap slightly, but their descriptions specify exact use cases, minimizing misselection. Overall, an agent can reliably pick the correct tool.
Naming Consistency4/5
The tool names consistently use snake_case with a verb_noun pattern (get_, create_, pay_, send_, estimate_, subscribe_, cancel_). Minor inconsistencies include list_webhooks vs get_wallets for retrieval, and check_username_available/lookup_user_wallet using non-get verbs. These are understandable but break the pattern slightly.
Tool Count2/5
With 55 tools, the server has an extremely large surface area. While the domain (Lightning wallet, invoices, onchain, L402, subscriptions) is broad, 55 tools exceed the 'too many' threshold and can overwhelm agents. Many tools are variants (e.g., create_invoice, create_invoice_usd, create_invoice_no_amount), making the set feel bloated.
Completeness5/5
The server provides comprehensive coverage of the wallet domain: account management, invoice lifecycle, payment methods, on-chain operations, intraledger transfers, fee estimation, webhooks, real-time subscriptions, and L402 paywalled access. There are no obvious gaps or dead-end operations; all critical workflows are supported.
Average 3.6/5 across 55 of 55 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on March 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses no behavioral traits such as irreversibility, fees, required balance, or authentication requirements, making it impossible to anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified. It conveys the core action but omits essential guidance, making it more sparse than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and many payment-related sibling tools, the description is incomplete. It lacks context on when to use this tool, prerequisites, and expected outcomes, leaving significant gaps for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters clearly (lnurl, amount, wallet_id) with 100% coverage, so the baseline is met. The description adds no additional meaning beyond the schema, but the schema itself is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Pay') and resource ('LNURL'), clearly identifying the tool's function. However, it does not explicitly distinguish it from similar sibling tools like pay_lightning_address or pay_invoice, which limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention contexts or alternatives, leaving the agent to infer when this tool is appropriate compared to sibling payment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the tool 'estimate[s]' a fee, implying a read-only operation, but provides no details on what the estimate is based on, return format, or side effects. This is insufficient for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main verb and resource. It is concise, with no redundant or irrelevant information, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema and no annotations. It fails to specify the fee unit (e.g., satoshis), mention whether the estimate is for the total fee or fee rate, or distinguish it from estimate_onchain_fee_usd, which is a sibling. Given the many similar payment-related tools, a more detailed description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents wallet_id, address, and amount with descriptions (75% coverage). The description adds no parameter-specific information and does not clarify the speed enum (FAST/MEDIUM/SLOW) which lacks a description. However, the schema is mostly self-explanatory, so the description's lack of contribution is not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates on-chain transaction fees for Bitcoin, using a specific verb ('estimate') and resource ('on-chain transaction fee'). It distinguishes from lightning fee tools but does not differentiate from the sibling estimate_onchain_fee_usd, which likely has a different output currency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives like estimate_lightning_fee or estimate_onchain_fee_usd. It doesn't mention any prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 reveals pagination support but doesn't disclose other important behavioral aspects: whether the wallet_ids parameter is required (it's optional per schema), what happens when omitted, the default behavior, rate limits, authorization requirements, or return format. For a tool that likely performs reads across potentially multiple wallets, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with key details front-loaded: what the tool returns and that it supports pagination. Every word is functional, and the description is appropriately sized for the tool's complexity. It loses a point for not adding usage guidance, but the conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, zero schema descriptions, no annotations, and no output schema, the description should provide more context. While it identifies the core purpose and pagination, it omits critical details like how wallet_ids works when omitted, whether the cursor is opaque, result ordering, and any limits or caveats. The tool likely needs stronger documentation to be invoked correctly by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'for one or more wallets' implies wallet_ids is the primary parameter, but it doesn't explain the cursor or limit parameters beyond the schema's default value. The description adds minimal meaning beyond the schema field names, leaving the semantics of cursor and limit under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns transaction history for one or more wallets, using specific verbs ('Get') and resource ('transaction history'). It is distinct from sibling tools like get_transaction_by_id (single transaction lookup) and get_wallets (wallet list), though it doesn't explicitly name them as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions supports pagination, implying use for large result sets, but doesn't explicitly clarify when to prefer get_transaction_by_id or other transaction-related tools. The usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states that a subscription ID is returned for tracking/canceling, but it does not disclose how real-time updates are delivered (e.g., webhook vs. polling), whether a webhook must be configured, any permission requirements, or the side effect of creating a persistent subscription. This is a significant gap for a subscription tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and return value. Every phrase earns its place ('Subscribe to real-time updates', 'Returns a subscription ID to track or cancel'). It contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a subscription ecosystem (siblings include add_webhook, list_subscriptions, cancel_subscription), but the description omits how updates are actually received, whether a webhook endpoint is required, and what the agent should do with the subscription ID beyond 'track or cancel'. With no output schema and no annotations, these are important gaps that make the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the sole parameter (payment_request) with the description 'The bolt11 payment request to monitor'. The tool description adds no extra meaning beyond the word 'Lightning invoice', which is already implied. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe to real-time updates') and the resource ('Lightning invoice payment status'), and mentions the key return value (subscription ID). However, it does not explicitly differentiate from the closely-related sibling subscribe_invoice_status_by_hash, which monitors the same status by hash; the distinction (payment_request vs. hash) is only in the schema, not the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_invoice_status for one-time checks or subscribe_invoice_status_by_hash when a payment hash is available. The description simply describes the action without any context or exclusions, leaving the agent without direction on choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action and gives no information about authentication, error states, or behavior when the transaction is not found, relying on the tool name to imply a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately sized for the tool's simple purpose and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation, the description is adequate but minimal. It lacks any indication of return format or error behavior, and no output schema or annotations exist to fill that gap, though the tool's low complexity mitigates the omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the schema fully documents wallet_id and transaction_id. The description adds no extra meaning beyond the schema, which 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('details of a specific transaction'), clearly conveying the tool's purpose. It distinguishes itself from list-style tools like get_transactions, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_transactions or get_invoice_status. There are no conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. The verb 'Get' and the word 'estimation' convey a read-only, approximate result, but it does not disclose whether authentication is required, whether both conversion directions are supported, or what rates/fees apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the tool's purpose immediately, with no filler or repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should clarify the return value and conversion direction; it does neither. The phrase 'between fiat and Bitcoin' leaves ambiguous whether the input is fiat converted to BTC or BTC converted to fiat, and the expected output format is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with amount and currency already documented in detail, so the baseline is 3. The description adds the fiat/Bitcoin context but does not clarify conversion direction or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('currency conversion estimation') and clearly names fiat and Bitcoin. It is clear and distinguishable from siblings like get_realtime_price, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_realtime_price or get_supported_currencies. It simply states what it does without any when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description states 'Get list', which implies a read-only operation, but it doesn't disclose whether authentication is required, whether results are live or cached, the response format, or any potential failure modes. This is a minimal disclosure that falls short of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the action 'Get' and the resource 'list of all supported display currencies'. Every word earns its place, and there is no unnecessary detail or redundancy. It exemplifies concise, effective writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description still leaves some open questions, such as the exact return format (e.g., array of currency codes?) and whether these currencies correspond to the values accepted by set_display_currency. Given the simplicity, the description is adequate for basic understanding but lacks enough context to be considered fully complete without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so by the rubric baseline, this dimension earns a 4. The description adds no parameter information, but none is needed. The schema also confirms no properties, and the description fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a list of all supported display currencies, using the specific verb 'Get' and identifying the resource. It distinguishes itself from sibling tools like set_display_currency and get_realtime_price by focusing on the list of supported display currencies. However, it is a simple sentence without additional scope or caveats, so it doesn't reach the level of the highest examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is only implied by the function name and description—use it when you need the supported display currencies—but there is no explicit 'when to use' or comparison with related tools like set_display_currency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action and fails to mention important traits like irreversibility, fees, balance requirements, or failure behavior. This is a significant gap for a payment operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a concrete example. Every word earns its place, and it is appropriately concise for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description should cover return values, error handling, and usage context. It does none of these, leaving the agent without critical execution details. For a payment tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description's example for ln_address duplicates the schema's example and adds no new meaning. Baseline 3 is appropriate given the schema handles semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send Bitcoin') and the specific target (Lightning Address), with an example format. It distinguishes from sibling payment tools like pay_invoice and pay_lnurl by specifying the address type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as pay_invoice or pay_lnurl. The description does not mention contexts, prerequisites, or exclusions, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavioral details. It only states 'Subscribe' but does not disclose side effects (e.g., persistent subscription, potential costs), authentication requirements, or what the response contains. This is insufficient for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the tool's purpose without any unnecessary words. Every word contributes meaning, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a subscription operation with no annotations or output schema, and the description fails to address the subscription lifecycle, how updates are delivered, or how to manage/cancel the subscription. This is a significant gap for an agent to invoke and handle the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'in a specified currency', which adds meaning to the 'currency' parameter by specifying it is the target currency for the price updates. However, schema coverage is 0%, and the description does not detail allowed values, default behavior, or formatting, leaving the agent partially informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes to real-time Bitcoin price updates in a specified currency, with a specific verb and resource. It distinguishes from siblings like get_realtime_price (fetch current price) and get_price_history (historical data) by emphasizing 'subscribe' and 'real-time'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or mention of alternatives. It does not clarify when to choose this over get_realtime_price or how it relates to webhooks or other subscription tools. The context is minimal and implied only by the word 'subscribe'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states the action without explaining side effects, required permissions, idempotency, or error behavior. It adds no behavioral context beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence of five words, front-loaded with the verb, containing no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but has gaps: no usage guidance, no behavioral transparency, and no explicit distinction from cancel_all_subscriptions. Without annotations or an output schema, more context would help the agent fully understand the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents subscription_id with the description 'The subscription ID to cancel' and 100% coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'cancel' and identifies the resource as 'an active real-time subscription', indicating a single subscription. This clearly distinguishes it from sibling tools like subscribe_* and cancel_all_subscriptions, which cancels all subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as cancel_all_subscriptions or list_subscriptions. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only explains the concept of an open invoice but does not mention return value, expiry behavior, or any side effects of creating an invoice. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every word contributes. It front-loads the primary action and provides a one-sentence elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, plus low parameter coverage, the description is too sparse. It explains what an open invoice is but leaves users guessing about the response format, parameter interactions, and differences from other invoice tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only wallet_id is described). The tool description does not add any meaning for memo, expires_in, or external_id. The only implicit parameter information is the absence of an amount, which is already evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action: creating a Lightning invoice without a fixed amount. The phrase 'open invoice' and 'payer can choose how much to send' differentiate it from sibling tools like create_invoice and create_invoice_usd.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the use case: when an open invoice is needed. It does not explicitly name alternatives or exclusions, but the 'without a specified amount' qualifier gives clear context for when to choose this tool over fixed-amount invoice tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention the return format, potential delays, authentication requirements, or any errors. For a read-only price tool, this minimal description lacks transparency about what the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. It is front-loaded and contains no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. However, the description does not explain what the tool returns (e.g., numeric price, object with price/currency). It does not address whether the price is in fiat or crypto, or any edge cases. Given the absence of an output schema, the description is incomplete for an agent to understand the resulting data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only says 'in a specified currency' without naming the parameter or providing constraints. While the schema shows 'currency' with type string and default USD, the description does not clarify allowed values, format (e.g., ISO 4217), or that it is optional. It adds no meaning beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current real-time Bitcoin price in a specified currency, using a specific verb (Get) and resource (current Bitcoin price). It is distinguishable from siblings like get_price_history (historical data) and convert_currency (currency conversion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for real-time pricing through the word 'current', but does not explicitly state when to use this tool versus alternatives like get_price_history or get_supported_currencies. There is no exclusionary guidance or mention of contexts where this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the search sources but does not clarify whether the operation requires authentication, whether it has side effects, what the output looks like, or any rate limits. For a read-only search tool, the lack of such context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two sentences. It front-loads the primary purpose, then provides source-specific detail. Every sentence adds useful information, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the description should explain result format, filter options, and any limitations. It omits details about the 'query', 'category', and 'status' parameters, and does not describe what a successful result looks like. This leaves the tool under-specified for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter semantics. It indirectly explains the 'source' parameter by mapping it to l402.directory and 402index.io, but it provides no meaningful guidance for 'query', 'status', or 'category'. The description adds only minimal value beyond the schema's enum definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') and resource ('L402 service directories'), and explains the purpose: finding paid APIs accessible with Lightning payments. It also differentiates the tool by naming specific sources (l402.directory and 402index.io), which helps distinguish it from sibling tools like l402_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on choosing between the two 'source' options (default vs. alternative with coverage differences), but it does not explicitly state when to use this tool versus other L402-related tools or when not to use it. The usage context is implied rather than explicitly framed with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the 'default wallet' nuance but does not disclose return format, error behavior, authorization requirements, or whether the lookup is public.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that contains no fluff – it states the action and object efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter lookup tool, the description covers the core purpose, but the lack of output schema and lack of wallet_currency explanation make it incomplete for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (username has a description, wallet_currency does not). The tool description mentions only username and does not explain the optional wallet_currency parameter, leaving its semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Look up'), resource ('a user's default wallet'), and method ('by their Blink username'). This distinguishes it from sibling tools like get_wallets, which target the current user's wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies usage when you have a Blink username and need their default wallet, but does not exclude alternatives or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must self-disclose. It only mentions the satoshi unit but omits critical behavioral traits such as irreversibility, fee implications (speed), and confirmation behavior. The FAST/MEDIUM/SLOW speed parameter is unexplained, and there is no warning about spending funds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant fluff, and the core action is front-loaded. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, this description is insufficient. It doesn't explain the speed parameter, memo, or the nature of on-chain transactions (irreversibility, broadcast). It also doesn't clarify the difference from send_onchain_all or send_onchain_usd, so an agent may select the wrong tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover wallet_id, address, and amount, and the description merely repeats the satoshi unit already present in the schema. It adds no new information about the optional memo or speed parameters, which lack schema descriptions. With 60% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('Bitcoin on-chain to a Bitcoin address'), and clarifies the amount unit (satoshis), which distinguishes it from USD or full-balance variants like send_onchain_usd/send_onchain_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for direct BTC on-chain payments but does not provide explicit guidance on when to use this vs sibling tools like send_onchain_all, send_onchain_usd, or Lightning options. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It states the action but does not indicate whether the change is persistent, account-wide, reversible, or how it affects other operations (e.g., price displays). No return value or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the purpose clearly with no redundant words or information. It is appropriately concise for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 parameter, no output schema), the description is minimally adequate. However, it lacks behavioral context (persistence, side effects) and does not reference related tools like get_supported_currencies to guide the user on currency selection. This leaves gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes the 'currency' parameter. The description adds an extra example (BTC) but no additional semantic details such as whether the code must match a supported list or case sensitivity. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a clear resource ('display currency for the account'). It distinguishes from siblings like set_default_wallet by explicitly naming the target resource, and includes concrete examples (USD, EUR, BTC) that clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_supported_currencies or set_default_wallet. There is no mention of prerequisites (e.g., checking supported currencies) or exclusions. Usage is only implied by the verb 'Set'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention whether removal is permanent, requires authentication, or has side effects. The word 'registered' hints at existing endpoints but provides no practical detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler words. It efficiently states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description states the basic action but omits critical context such as consequences of removal, success/failure indicators, or any prerequisites. For a destructive operation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'id' parameter with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('webhook callback endpoint'), clearly distinguishing it from sibling tools like add_webhook and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or provide alternatives. It implies usage through the verb 'Remove' but lacks guidance on when to prefer it over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Subscribe to real-time updates' without explaining how updates are delivered (e.g., webhook, websocket), whether the subscription is long-lived or requires cancellation, or what the response looks like. This is insufficient for a subscription tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. It contains no redundant or extraneous information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the existence of a very similar sibling tool (subscribe_invoice_status), the description is too sparse. It does not clarify delivery mechanisms, subscription lifecycle, or how to disambiguate from similar tools, leaving critical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of the single parameter with a clear description ('The payment hash to monitor'). The tool description adds no additional semantic detail beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe to real-time updates') and the resource ('Lightning invoice by payment hash'). It differentiates from sibling tools like subscribe_invoice_status by explicitly specifying the hash-based subscription, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring invoice status via payment hash, but does not explicitly state when to choose this over the similar sibling tool subscribe_invoice_status, nor does it mention any prerequisites or exclusions. It provides no direct guidance for selecting this tool among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action without disclosing side effects, authentication requirements, idempotency, or error behavior. This is insufficient for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, directly front-loading the action and purpose. It earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema), but the description lacks information about return values, event specifics, or prerequisites. It covers the basic purpose but leaves gaps typical of a minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description of the 'url' parameter (100% coverage). The tool description adds context that events are payment notifications, slightly enriching the parameter meaning, but does not provide additional format or syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register a new webhook callback endpoint to receive payment notifications', using a specific verb and resource. It distinguishes itself from sibling tools like list_webhooks and remove_webhook by indicating creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for registering webhooks for payment notifications, but it does not explicitly state when to use this tool versus alternatives like subscribe_invoice_status or subscribe_account_updates. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action and a condition ('unpaid') without mentioning side effects, reversibility, error conditions, or permissions. For a state-changing operation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the tool's purpose without unnecessary detail, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of the tool (2 fully described parameters, no output schema), the description is minimally sufficient to convey the core action. However, as a mutation tool with no annotations, it would benefit from additional context about what 'cancel' actually does (e.g., whether it fails on paid invoices, what happens afterward), which prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (wallet_id and payment_hash), covering 100% of parameters. The description text adds no additional parameter-specific meaning, so it does not improve upon the schema's baseline coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel an unpaid Lightning invoice' clearly identifies the action (cancel) and the resource (Lightning invoice), with a specific qualifier (unpaid) that distinguishes it from sibling tools like create_invoice, pay_invoice, or cancel_subscription. This is a specific verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for canceling an invoice that has not been paid, which gives a clear context. However, it does not explicitly state when to use it versus alternatives or mention any exclusions, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not specify the return format (e.g., boolean), whether the check is case-insensitive, or any error conditions. This leaves the agent uncertain about the tool's output and edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly communicates the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the basic purpose but lacks details on return values and behavioral nuances. Given no output schema and no annotations, the agent may not know what to expect from the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter ('username') with 'The username to check', and the description adds no additional meaning beyond that. Baseline 3 applies since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking if a Blink username is available. It uses a specific verb ('check') and resource ('username availability'), distinguishing it from sibling tools like 'set_username' and 'lookup_user_wallet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use as a pre-check before setting a username but does not explicitly state when to use it versus alternatives. No 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.
Behavior2/5
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 only states the action and unit clarification, but does not disclose side effects (e.g., invoice expiry behavior), prerequisites (e.g., wallet must be active), or failure modes. There is no mention of how optional parameters like expires_in or memo affect the created invoice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and including only essential detail. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description is minimal. It does not explain how optional parameters work, nor does it explicitly differentiate from sibling invoice creation tools. The agent lacks guidance on behavior, permissions, or what the created invoice looks like, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (only amount and wallet_id have descriptions). The description's note that amount is in satoshis duplicates the schema's amount description, and wallet_id is already described as BTC wallet. The other three parameters (memo, expires_in, external_id) are entirely undocumented, and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('Lightning invoice') with a clear scope: receive a specific amount of Bitcoin. The mention of 'specific amount' and 'satoshis for BTC wallet' distinguishes it from siblings like create_invoice_usd and create_invoice_no_amount, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a fixed-amount BTC invoice is needed, with units in satoshis. It does not explicitly list alternatives or exclusions, but the 'specific amount' wording hints at differentiation from no-amount or USD-based invoice tools. Clear context, but no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a new address is generated, without mentioning output format, address reuse, or whether the previously generated address remains valid. Key behavioral details are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and a clear action, the description plus schema are minimally adequate. However, the lack of an output schema and any mention of the return value or behavior changes leaves gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'wallet_id' is well-described in the schema. The tool description adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('new on-chain Bitcoin address to receive funds'), clearly stating the action and distinguishing it from siblings like get_current_onchain_address, which retrieves an existing address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (receiving funds) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. It is adequate as a basic purpose statement but lacks explicit usage guidance compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't state whether the operation is read-only, requires authentication, or has side effects. The word 'estimate' suggests non-mutating, but the description provides no specifics about rate limits, permissions, or other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly conveys the tool's purpose without unnecessary words or repetition. It earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, but since there is no output schema, the description should explain what the returned fee estimate looks like (e.g., units, format). It also doesn't clarify how this differs from estimate_lightning_fee_no_amount, leaving a small gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (wallet_id and payment_request) already documented in the input schema. The description itself adds no additional parameter meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates Lightning network fees for paying an invoice, with a specific verb ('estimate') and resource ('Lightning network fee'). It distinguishes itself from the sibling tool estimate_lightning_fee_no_amount by specifying 'for paying an invoice', implying it handles invoices with an amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (before paying an invoice, to estimate the fee) but provides no explicit guidance on when not to use it or how it compares to estimate_lightning_fee_no_amount. There are no alternative tool names or exclusions mentioned, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Check' implies a read-only operation, but the description does not disclose the return format, whether it polls, error behavior, or explicitly state that no state changes occur. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose and includes the key differentiator (bolt11) without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is minimally viable. However, with no output schema and no annotations, it should at least mention what the status response looks like (e.g., 'paid'/'unpaid') to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the payment_request parameter. The description only restates 'bolt11', adding no new semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and clearly identifies the resource ('payment status of a Lightning invoice') and the lookup key ('by payment request (bolt11)'). This distinguishes it from sibling tools like get_invoice_status (which likely uses an invoice id) and subscribe_invoice_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is implied: use it when you have a bolt11 payment request and want its status. However, it does not explicitly state when not to use it or mention alternatives, which would be helpful given the many invoice-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the core action. It omits details about the response format, data granularity, or whether the returned history includes current data, leaving the agent with limited understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and effectively communicates the essential purpose without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description is adequate but leaves gaps. It does not explain what the price history output looks like or how the time range maps to data frequency, and with no output schema or annotations, the agent may lack sufficient context to fully understand the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single 'range' parameter, including an enum and description. The description's phrase 'specified time range' adds no new semantic detail beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving Bitcoin price history for a specified time range. The verb 'Get' and resource 'Bitcoin price history' are specific, and the scope differentiates it from sibling tools like get_realtime_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when historical price data is needed, but it does not explicitly mention when to use this tool versus alternatives such as get_realtime_price or subscribe_price_updates. There is no guidance on exclusions or selection criteria beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses valuable behavioral details: 'Checks the token cache first to avoid re-paying' and 'Returns the response data from the protected resource after successful payment.' However, it omits important side effects (significant financial transaction), behavior of optional parameters like force and dry_run, and error handling (e.g., payment failure, cached token expiration). This is partial transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes only essential behavior (cache check, return response). No filler or redundant information. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is incomplete. It provides a high-level flow but lacks details on optional parameters (force, dry_run, max_amount_sats), expected return format, and edge-case behavior. The presence of related sibling tools (l402_discover, l402_payment_verify) is not leveraged to clarify integration context. An agent invoking this tool would need to infer critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only url and wallet_id have descriptions). The tool description does not add any meaning for the undocumented parameters (force, method, dry_run, max_amount_sats), and for url and wallet_id it merely restates what the schema already says. The description fails to compensate for the low schema coverage, leaving agents without guidance on the optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Access an L402-protected URL by automatically paying the Lightning invoice.' It also specifies the caching behavior and the return value, distinguishing it from sibling tools like pay_invoice (which only pays) and l402_discover (which finds L402 resources). The verb 'access' plus the resource makes 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when accessing L402-protected URLs, but it does not explicitly state when to prefer this over alternatives (e.g., pay_invoice, l402_payment_verify) nor when not to use it. It provides context but no explicit exclusions or comparisons, resulting in an implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that it lists active subscriptions, but does not mention side effects, return format, pagination, or authorization requirements. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without any fluff. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description is adequate but not fully complete. There is no output schema, so the return structure is unspecified. The description implies a list but does not detail the content of the subscriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. There is no parameter information to add because the schema is empty, and the description offers no confusing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all active real-time subscriptions' clearly states the verb (list) and the specific resource (active real-time subscriptions). It distinguishes itself from sibling tools like list_webhooks by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of exclusions or prerequisites, though the simple nature of the operation makes it somewhat self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does convey the key behavior of sweeping the entire balance, which is a significant trait. However, it omits details about fees, irreversibility, balance requirements, or failure modes, which are particularly important for a mutating financial tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and concise sentence that immediately states the action and scope. It contains no redundant words or filler, and the parenthetical 'sweep' adds valuable clarification without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, including an enum, and a mutating financial action), the description is too brief to be fully complete. It lacks context about parameter usage, especially memo and speed, and does not mention return values or side effects. The absence of annotations and output schema increases the need for a more thorough description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with wallet_id and address described in the schema. The description adds little beyond that: 'entire wallet balance' restates the wallet_id purpose and 'Bitcoin address' restates the address purpose. It provides no insight into the memo or speed parameters, which lack schema descriptions. Thus, the description does not compensate for the parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Send'), resource ('entire wallet balance'), and destination ('Bitcoin address'), and the parenthetical 'sweep' reinforces the all-balance semantics. This clearly distinguishes it from sibling tools like 'send_onchain' which likely send a specified amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for sweeping the full wallet balance to a Bitcoin address, but it does not explicitly state when to use it over alternatives like send_onchain or send_to_wallet. There is no mention of exclusions or scenarios where other tools would be more appropriate, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It fails to mention side effects (e.g., that this changes the default for future transactions), permission requirements, return value, or whether the change is persistent. This is a mutation tool with no disclosure beyond the basic effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the action and scope without redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description covers the core purpose. However, it lacks information about what the tool returns, whether the operation requires authentication, and what happens if the wallet_id is invalid. This leaves gaps for an agent to confidently invoke the tool in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter wallet_id as 'The wallet ID to set as default', so schema coverage is 100%. The description adds marginal context about wallet types (BTC or USD) but does not provide any additional syntax, format, or validation details beyond what the schema gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and identifies the resource as 'default wallet for the account', with the explicit parenthetical '(BTC or USD wallet)' which adds helpful context. It clearly distinguishes from sibling tools like set_display_currency or set_username.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the action obvious but provides no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. Sibling tools like set_display_currency are related but distinct, and no guidance is given for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 neither mentions whether the change is permanent, whether it requires special permissions, nor what side effects may occur. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description is adequate but not complete. It lacks details on outcomes, validation errors, or the relationship to check_username_available, which would be helpful for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'username' parameter fully with 'The new username', and the tool description aligns with that. No additional constraints or format details are given, but schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set or update') and targets a clear resource ('username for the current user'), which distinguishes it from sibling tools like get_account_info or check_username_available. It clearly states the action's scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when changing one's own username, but it does not mention prerequisites (e.g., checking availability with check_username_available) or when not to use it. No explicit alternatives or exclusions are given, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'estimate' which implies no actual transaction is sent, but it does not explicitly confirm non-mutating behavior, nor does it mention any prerequisites, auth requirements, or that the fee depends on the 'speed' parameter. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose with no unnecessary words. It is appropriately sized for a tool whose parameters are already well-documented in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description does not explain that the fee varies by the 'speed' parameter, nor does it hint at the return format (e.g., a fee amount). Given the existence of sibling tools like estimate_onchain_fee, the description also fails to explicitly differentiate its behavioral context beyond the USD wallet qualifier. This leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (three of four parameters have descriptions). The description adds no parameter-specific meaning, but the schema already documents wallet_id, address, and amount well. The speed parameter lacks a description but has an enum and default, so the schema handles it adequately. Thus, the description does not significantly enhance parameter understanding, and a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'estimate' with the resource 'on-chain transaction fee' and scopes it to 'sending from USD wallet'. This clearly distinguishes it from sibling tools like estimate_onchain_fee (likely for BTC) and estimate_lightning_fee, as the 'USD wallet' qualifier makes the resource unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for estimating fees when sending from a USD wallet. It does not explicitly name alternative tools or provide exclusions, but the 'from USD wallet' phrasing implies the relevant use case, which is sufficient for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It reveals the cache file location, the local scope, and that listing shows masked sensitive data. However, it does not detail side effects of clearing (e.g., file deletion), the exact format of responses, or how 'expired_only' affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and lists the operations efficiently. It avoids unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters but no output schema, and the description does not explain the 'expired_only' parameter or adequately specify return formats for each operation. Given the low schema coverage and lack of annotations, the description should provide more detail about inputs and outputs to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'command' has a description). The description adds meaning to 'command' by mapping the enum values to operations and clarifies that 'domain' is used for getting tokens. However, it does not explain 'expired_only' at all, leaving a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing the local L402 token cache at a specific path. It enumerates three specific operations (list, get, clear) and explicitly distinguishes itself from sibling tools like l402_pay and l402_search by focusing on cache management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to manage cached L402 tokens) but provides no explicit when-not-to-use guidance or references to alternatives. The context signals show distinct sibling tools, but the description itself does not mention them or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the amount requirement and does not disclose potential side effects like wallet debit, irreversibility, or authentication requirements, making it insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the core action. No filler or redundant wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal, lacking information about return values, error conditions, prerequisites such as sufficient balance, or guidance on when to use this tool versus the many sibling payment tools. While the schema covers parameters, the tool's behavioral aspects are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for wallet_id and payment_request (67% coverage), and the description adds a constraint about the invoice amount. The memo parameter remains completely undocumented, and the description does not clarify its purpose or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pay' and the resource 'Lightning invoice', making the action unmistakable. It also distinguishes from siblings like pay_invoice_with_amount by noting the invoice amount must be included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'The invoice amount must be specified in the invoice' provides a clear prerequisite, implying this tool is for fixed-amount invoices rather than amountless ones. However, it does not explicitly name alternative tools or describe when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action and does not mention side effects, reversibility, required permissions, or failure modes. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and condition, with no filler or redundancy. It is easy to parse and directly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It does not explain return values, prerequisites, or error behavior. For a payment tool, this leaves important gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the schema already describes amount, wallet_id, and payment_request. The tool description adds only the rationale for specifying the amount, not additional syntax or constraints. No extra meaning is provided for the memo parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pay' and a specific resource 'Lightning invoice that has no amount specified (open invoice)', and adds 'You specify the amount to send.' This clearly distinguishes it from sibling tools like pay_invoice, which handles invoices with a fixed amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition for using this tool (invoices without an amount), which gives clear context. It does not name alternatives but implies that other tools are used for fixed-amount invoices. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states 'subscribe' without disclosing how updates are delivered (e.g., webhook, streaming), whether the subscription is persistent or one-time, authentication requirements, or side effects such as creating a managed subscription.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool involves subscription management (evidenced by sibling tools like list_subscriptions, cancel_subscription), the description lacks essential context about the subscription lifecycle, how updates are received, and how to stop them. With no annotations or output schema, this is a significant gap for a tool that likely has side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter details, but none are needed since the schema is empty and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'subscribe' and the resource 'all real-time account updates', specifying the scope as including incoming/outgoing transactions and price updates. This distinguishes it from sibling tools like subscribe_invoice_status and subscribe_price_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for receiving account-level real-time updates but provides no explicit guidance on when to prefer it over alternatives like subscribe_price_updates or subscribe_invoice_status. There are no exclusions or conditional usage notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It states the action but does not mention reversibility, confirmation, scope limitations (e.g., only current session vs. all sessions), or what happens to individual subscription feeds. The description is too terse to convey the operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and object. It contains no extraneous words and is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but with no output schema and no annotation, the description provides only the basic action. Missing details such as return value, whether it confirms cancellation, and the exact scope of 'active real-time subscriptions' leave the agent with unanswered questions for a mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers everything (100%). According to the rubric, a baseline of 4 applies for zero-parameter tools. The description adds no parameter details because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') and resource ('all active real-time subscriptions'), clearly distinguishing it from the sibling tool 'cancel_subscription' which targets a single subscription. The scope is unambiguous and the purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a bulk cancellation action, contrasted with the singular 'cancel_subscription' sibling, but it does not explicitly state when to choose this over alternatives or mention any prerequisites or side effects. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavioral traits. It only says 'Check the payment status' with no mention of read-only behavior, possible return statuses, error handling, or whether any side effects occur. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and object. Every word is essential, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects, no output schema). The description clearly states its purpose and parameter, but since there is no output schema, it does not explain what the response contains (e.g., status values like settled/pending). For a straightforward status check, this is adequate but leaves some ambiguity about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter (payment_hash) with a clear meaning. The description's phrase 'by payment hash' reinforces that the parameter is the identifier, but adds no new information beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'payment status of a Lightning invoice', with the specific lookup method 'by payment hash'. This distinguishes it from sibling tools like get_invoice_status_by_request, which likely uses a different identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a payment hash and need to check status, which is clear context. However, it does not explicitly mention alternative tools like get_invoice_status_by_request or subscribe_invoice_status, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the output (WWW-Authenticate header for HTTP 402) and the creation of invoice and macaroon, but does not mention side effects, persistence, auth requirements, or potential state changes. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and output. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description is too sparse. It omits parameter explanations, output format details, prerequisites, and how the challenge integrates with verification tools, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 20% description coverage (only amount_sats is described). The description does not compensate by explaining the other four parameters. It references 'resource' in the purpose but not its parameter semantics, leaving most parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create an L402 payment challenge (invoice + signed macaroon)' with a specific purpose 'to protect a resource behind a Lightning paywall.' It also names the return value, distinguishing it from sibling payment tools like l402_pay and l402_payment_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when protecting a resource behind a Lightning paywall, which provides clear context. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses the key non-obvious behavior: the invoice is denominated in satoshis but credited as USD. This is critical for user expectations and goes beyond a simple 'create invoice' statement. It lacks details about authentication, reversibility, or failure modes, but the core behavioral nuance is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the action and subject. It avoids redundant phrasing and every sentence contributes substantive information: the creation action, currency-specific amount, and the satoshi-to-USD credit nuance. No fluff or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description covers the core create-invoice behavior and a key conversion detail, but omits return value expectations, optional parameter meanings, and any operational constraints like expiry or amount limits. It is adequate for basic invocation but leaves gaps for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (amount and wallet_id have descriptions). The description adds meaning for 'amount' by specifying USD cents, and for 'wallet_id' indirectly via 'USD wallet ID' in the schema. However, it does not explain memo, expires_in, or external_id, and with low coverage the description should compensate more. Optional parameters remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Lightning invoice for receiving a specific USD amount in cents, and distinguishes it from sibling tools like create_invoice or create_invoice_no_amount by explicitly mentioning Stablesats and USD-centric behavior. The verb 'create' is specific and the resource ('Lightning invoice', 'USD cents') is well defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for USD-denominated invoices, providing context that it converts USD cents into a satoshi-denominated invoice. However, it does not explicitly contrast with sibling tools such as create_invoice or create_invoice_no_amount, nor does it state when to prefer this over alternatives. The usage context is clear but not exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It mentions 'current user' (implying authentication context) and lists the data categories, but it does not explicitly state that this is a read-only operation, whether it requires specific authorization scopes, or any rate-limit or side-effect considerations. The description carries only a minimal burden for a simple getter, but still lacks meaningful behavioral disclosure beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose without waste. It includes just enough detail (wallets, balances, settings) to clarify the scope, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read tool with no output schema, the description is largely complete: it identifies the subject (current user) and the major data categories returned. It could go further by stating that this is an aggregate or high-level endpoint, especially given the many sibling tools, but the current text is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty object). Per the rubric, 0 params merits a baseline of 4; the description correctly avoids inventing parameter details and focuses on the returned data scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the current user account information including wallets, balances, and settings.' It uses a specific verb ('Get') and resource ('account information'), and the 'including' clause distinguishes it from narrower sibling tools like get_wallets or get_wallet_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current user account information' implies this is for a high-level account snapshot, and the inclusion of wallets, balances, and settings suggests use when multiple account facets are needed. However, there is no explicit guidance about when to choose this over siblings like get_wallets or get_account_limits, nor any stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral detail about return units (satoshis or cents), but it does not disclose error handling, authentication needs, or when each currency is used. With no annotations, the description carries the transparency burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy. It front-loads the primary action and includes a valuable return-unit detail, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple getter, but it lacks the response shape and the conditions for when BTC vs USD is returned. Since there is no output schema, these details would improve completeness, but the core purpose is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the wallet_id parameter with a description, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the balance of a specific wallet by ID, with a specific resource (wallet balance) and scope (by wallet ID). It effectively distinguishes from sibling tools like get_wallets (which lists all wallets) and get_account_info (account-level details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage: use when you have a wallet_id and need its current balance. It does not explicitly mention alternatives or exclusions, but the context is unambiguous given the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does add useful context like 'from a USD (Stablesats) wallet' (implying a conversion step) and 'Amount is in cents.' However, it omits important behavioral traits such as network fees, confirmation expectations, or whether the operation requires special permissions. Given the mutation nature and zero annotation support, this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, front-loaded with the core action and then the critical unit note. Every word carries meaning; there is zero redundancy or filler. This is a model of efficient description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description covers the essential purpose but leaves several contextual gaps: no mention of return values, failure modes, or differentiation from send_onchain_all. Given the complexity and the lack of structured safety/return information, this is a minimum viable description but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% with descriptions for amount, address, and wallet_id. The description's 'Amount is in cents' merely repeats the schema description for amount. It does not clarify the 'memo' or 'speed' parameters, which have no descriptions in the schema. The description adds no unique parameter semantics beyond what the schema already provides, but it does not conflict with it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send on-chain Bitcoin from a USD (Stablesats) wallet.' It specifies the resource (USD wallet) and the destination (on-chain Bitcoin), distinguishing it from sibling tools like send_onchain (presumably from BTC wallet) and send_onchain_all. The addition of 'Amount is in cents' further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when sending on-chain Bitcoin from a USD-denominated wallet, as opposed to a regular Bitcoin wallet. However, it does not explicitly name alternative tools or state when not to use this tool, which would make the guidance stronger. The context is clear enough for an agent to infer usage in typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses useful traits: the tool looks up the recipient's wallet and performs an intraledger transfer (free, instant). However, it does not mention that funds will be deducted from the sender's wallet, that the operation is irreversible, or that authorization is required. These are significant gaps for a payment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and adds one key benefit (intraledger, free, instant). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for basic selection but incomplete for a financial tool: it does not mention that the transfer supports USD (despite wallet_currency in schema), lacks any return value expectation (no output schema), and omits potential failure modes. Given the tool's complexity, a bit more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes wallet_id, username, and amount (60% coverage). The description adds value by clarifying that the username triggers a wallet lookup, but it does not explain memo or wallet_currency. Given medium schema coverage, the description is adequate but not heavily compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send Bitcoin to a Blink user by their username.' It also distinguishes itself from sibling tools by emphasizing the intraledger transfer mechanism (free, instant), which differs from sending to a wallet ID or via onchain/invoice methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a Blink username to send to. It does not explicitly compare with alternatives like send_to_wallet or pay_invoice, but the username focus provides clear context. Lacks exclusionary guidance but is not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description carries full burden. It discloses cost (free), speed (instant), and transfer type (intraledger), plus unit (cents). But doesn't mention prerequisites, failure modes, or what happens on insufficient balance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and key context. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 4 params, no output schema. Description covers main purpose and transfer type but omits return value or error behavior. Adequate minimal description but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 3 of 4 parameters with descriptions; memo lacks description. The description reinforces the amount unit but adds little beyond schema. Baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Send' with explicit resource 'USD (Stablesats)' and target 'another Blink wallet'. Distinguishes from sibling onchain and Lightning transfer tools by noting 'free, instant, intraledger transfer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for direct Blink wallet-to-wallet transfers. Mentions intraledger specificity, which excludes onchain and Lightning. However, it doesn't explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' strongly implies a read-only operation, and the listed categories add specificity. However, it does not disclose potential nuances such as whether limits are current cumulative usage or maximum thresholds, any authentication requirements, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that starts with the action verb and immediately communicates the resource and scope. No redundant words or filler; it is optimally structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the tool's complexity is low. The description adequately states what the tool does. It could further specify the meaning of 'limits' (e.g., daily vs. lifetime) or mention that no input is required, but for a simple getter it is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage vacuously. Per the guidelines, 0 params earns a baseline of 4. The description correctly adds no parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'account limits' and explicitly enumerates the scope (withdrawals, internal sends, currency conversion). This distinguishes it from siblings like get_account_info, which likely provides broader account information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when account limits are needed, but it does not explicitly state when to prefer this tool over alternatives like get_account_info, nor does it provide exclusions or prerequisites. The context is clear but not explicit about differentiating from overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the operation is a read ('Get') and scopes are tied to the current API key, but it does not explicitly disclose whether the operation is side-effect-free, requires authentication, or may return an empty list. Some additional context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any filler or redundant information. Every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is mostly complete. It states what the tool does and the relevant context (current API key). However, it does not mention the return format or further details about the scopes, which could be useful but is not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the instructions. The description adds context about the API key but does not introduce any parameter-specific semantics since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving permission scopes for the current API key, which is a specific and distinct purpose compared to sibling tools like get_account_info or get_wallet_balance. The verb 'Get' and resource 'permission scopes' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when needing to know available scopes for the API key) but does not explicitly state alternatives or exclusions. No guidance is given on when not to use it or how it relates to other tools, though this is a simple informational getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 tool returns the 'most recent' address rather than generating a new one, which is a key behavioral trait distinguishing it from address creation tools. However, it does not mention authorization requirements, side effects, or error behavior, but for a simple getter this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with the key information front-loaded. Every word earns its place, and the parenthetical '(most recent)' adds crucial clarity without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema or annotations, the description is reasonably complete. It clearly identifies what the tool does and the meaning of 'current'. However, it could explicitly state that no new address is created, but the parenthetical already implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of wallet_id (100% coverage), and the description adds no additional meaning beyond referencing 'a wallet'. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource 'current (most recent) on-chain Bitcoin address' and scope 'for a wallet'. It distinguishes from sibling tools like create_onchain_address and send_onchain by focusing on retrieval of the existing latest address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve the wallet's latest on-chain address, but it does not explicitly contrast with alternatives such as create_onchain_address (which creates a new address) or state when not to use it. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds useful context: 'free, instant, intraledger transfer'. However, it does not mention potential failure conditions, reversibility, or prerequisites like authentication. The disclosed traits are helpful but incomplete for a money-movement tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action. Every word earns its place: 'free', 'instant', 'intraledger', and 'satoshis' all communicate critical scope and behavior. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool (4 params, no output schema), the description covers the main use case and key constraints. It provides enough context for an agent to select it among many siblings. Missing explicit guidance on memo or edge cases, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params described). The description reinforces the satoshi unit for amount, but that is already in the schema. It adds no new parameter-level meaning for wallet_id or recipient_wallet_id, and memo remains undocumented. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send Bitcoin') and the target ('another Blink wallet'), with additional scope qualifiers ('free, instant, intraledger transfer') that differentiate it from external or on-chain sends. It distinguishes from sibling tools like send_onchain and send_to_wallet_usd by specifying the internal nature and satoshi unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for direct, internal Blink wallet transfers. It does not explicitly name alternatives like send_to_wallet_usd or send_to_username, but the intraledger framing and satoshi mention provide clear context. Absence of explicit 'when not to use' prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The word 'estimate' implies it merely calculates a fee without sending payment, but it does not explicitly state this or describe any side effects, required permissions, or return format. It provides the core action but lacks broader 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the return value (presumably a fee estimate) and doesn't clarify that the amount parameter is required specifically because the invoice lacks one. Given the lack of annotations and output schema, this prevents a higher score, though the description is not entirely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that the payment_request is an open (no-amount) invoice, which explains why the amount parameter is required. This contextual addition goes beyond the schema descriptions, elevating the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to estimate Lightning network fees for open (no-amount) invoices. The verb 'estimate' and resource 'fee' are specific, and the qualifier 'no-amount' distinguishes it from the sibling estimate_lightning_fee tool, which presumably handles amount-based invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for invoices without a fixed amount, providing clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, such as using estimate_lightning_fee for invoices with an amount, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The verb 'Get' indicates a read-only operation and the content is disclosed (network info, Lightning node details, fee information). It doesn't mention side effects or auth requirements, but for a simple global getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and includes specific details without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema, the description covers the essential expectations (network information, node details, fee info). It could be more detailed about response structure, but given the simplicity, it is contextually sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. No parameter explanation is needed; baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('global network information') with specific inclusions ('Lightning node details and fee information'), which distinguishes it from siblings like get_account_info or get_wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for network-wide information but does not explicitly mention when to prefer this over alternatives like estimate_lightning_fee for payment-specific fees. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read-only operation but does not explicitly state that it causes no side effects, nor does it mention response format, pagination, or rate limits. For a simple list operation, this is acceptable but leaves some behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place, with no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description provides a clear picture of what the operation does. It does not detail the exact return structure, but for a list operation the expected outcome (a list of endpoints) is sufficiently implied. The overall context is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description is consistent with that (no parameter details omitted). Per the rubric, a zero-parameter tool receives a baseline of 4 because there is no additional parameter semantics to add beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('webhook callback endpoints') scoped to 'the account'. It clearly distinguishes itself from sibling tools like add_webhook and remove_webhook by indicating it is the read-only listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is self-evident: use this when you need to see all registered webhooks. It does not explicitly state alternatives or exclusions, but the clear scope and the presence of add_webhook/remove_webhook make the usage context unambiguous. There is no need to mention alternatives for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It transparently explains the non-payment behavior ('without paying') and the nature of the operation ('probe'), which is a lightweight read. It lists the returned data (invoice, price, format). It does not disclose error handling or edge cases, but for a simple read-only probe, the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every sentence earns its place: the first explains what it does and returns; the second gives a practical usage directive. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers the essential aspects: purpose, when to use, and what is returned (invoice, price, format). It does not detail potential errors or network behavior, but given the simplicity and the clear usage guidance, the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'url' is described). The description mentions 'URL' but does not explain the 'method' parameter at all. The schema provides enum values (GET/POST) and a default, but the description adds no further semantics, such as when to use POST vs GET. This leaves the method parameter under-specified, and the description does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Probe a URL for L402 payment requirements without paying.' It specifies the verb (probe), the resource (URL), and the purpose (discover L402 payment requirements). It also names distinct outputs (invoice, price in sats, format), which distinguishes it from sibling tools like l402_pay and l402_payment_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'Use this before l402_pay to check the cost of accessing a resource.' This names the primary alternative (l402_pay) and specifies that this tool is a precondition. It clearly implies this is for checking cost before committing to payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains the three verification layers (preimage, HMAC, caveats) and states the return value ('valid: true/false'). It doesn't mention error handling or side effects, but for a verification operation this is adequate, though not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured with a numbered list. It front-loads the purpose and avoids extraneous detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: purpose, verification logic, and return type. It lacks details on failure modes or how the resource parameter aligns with caveats, but for a verification tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are no parameter descriptions, so the description must compensate. It links parameters to their roles: 'preimage proves payment', 'HMAC signature proves authenticity' (macaroon), and 'caveats (expiry, resource) are satisfied'. However, it doesn't explicitly clarify how the 'token' parameter relates to the others, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Verify an L402 payment token submitted by a client.' It uses a specific verb ('verify') and resource ('L402 payment token'), and is well-distinguished from sibling tools like l402_pay (which creates tokens) and l402_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for verifying tokens submitted by clients. It doesn't explicitly mention alternatives or when not to use, but the purpose is unambiguous given the verb and the token type. Since it lacks explicit exclusions or alternative mentions, it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds valuable detail about units ('Balance is in satoshis for BTC wallet and cents for USD wallet'), which goes beyond the basic function and helps the agent interpret results correctly. No mention of read-only safety, but 'Get' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action ('Get all wallets') and immediately provides essential unit information. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter read tool with no output schema, the description covers what the tool does and the units of the returned balances. It is complete enough for an agent to select and use the tool without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds no parameter info (there are none to describe), but it does provide useful context about return units, which is tangential to parameters. No gaps here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all wallets (BTC and USD) with their current balances.' It specifies the resource (wallets), scope (all), and asset types (BTC and USD), distinguishing it from singular wallet tools like get_wallet_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for retrieving all wallets at once, which is implicit usage context. It does not explicitly mention alternatives or exclusions, but the name and description make the intended use clear enough without such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![blink-mcp MCP server](https://glama.ai/mcp/servers/blinkbitcoin/blink-mcp/badges/card.svg)](https://glama.ai/mcp/servers/blinkbitcoin/blink-mcp)

Score Badge

Copy to your README.md:

[![blink-mcp MCP server](https://glama.ai/mcp/servers/blinkbitcoin/blink-mcp/badges/score.svg)](https://glama.ai/mcp/servers/blinkbitcoin/blink-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blinkbitcoin/blink-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server