This server provides 26 paid tools for Bitcoin mempool intelligence and sovereign on-premise AI inference, with automatic payment via Lightning (L402) or USDC on Base (x402).
Bitcoin Mempool Intelligence (from a real Bitcoin Core full node):
get_fees — Fee estimates (next-block, 30-min, 1-hour) with trend analysis (10 sats)
get_whales — Whale alerts for large transfers, consolidations, and distributions in the mempool (40 sats)
get_mempool_state — Live mempool state: tx count, byte size, and fee histogram (5 sats)
get_mempool_history — Rolling 24h snapshots of mempool size and fees (50 sats)
predict_fees — EMA-based fee predictions with confidence scores and direction (rising/falling) (50 sats)
get_recent_blocks — Recent block data: heights, tx counts, and timestamps (10 sats)
tx_status — Look up any Bitcoin transaction by txid for confirmations, fee, block height, and mempool ETA (15 sats)
fee_quote — Exact fee quote for a planned transaction given inputs, outputs, and target blocks (15 sats)
Sovereign AI Inference (Qwen3 on dedicated GPU, no third-party APIs, no data leakage):
ai_summarize — Summarize text at short/medium/long lengths (20 sats)
ai_sentiment — Sentiment analysis with a confidence score (10 sats)
ai_translate — Translate between 100+ languages (20 sats)
ai_grammar — Fix grammar, spelling, and punctuation (15 sats)
ai_code_review — Review code for bugs, security, and performance issues (50 sats)
ai_code_generate — Generate code from natural-language specifications (40 sats)
ai_extract — Extract structured data (entities, contacts, dates, or custom schema) from text (25 sats)
ai_classify — Classify text into user-provided categories (10 sats)
ai_rewrite — Rewrite text in a different style or tone (15 sats)
ai_explain — Explain any topic at ELI5, beginner, intermediate, or expert level (25 sats)
ai_agent — General-purpose AI agent for any text task (30 sats)
ai_scrape — Scrape and extract clean readable text from any URL (15 sats)
ai_embed — Generate 768-dim embedding vectors for RAG (single or batch) (2 sats)
ai_vision — Visual question answering over an image URL (40 sats)
ai_ocr — Extract all visible text from an image URL (25 sats)
ai_transcribe_table — Convert a table image into structured JSON rows (35 sats)
ai_longform — Summarize huge documents (~50K words) in a single flat-fee call (75 sats)
ai_research — Multi-step web research with cited synthesis (100 sats)
Payment options: Lightning Network sats (L402), USDC on Base (x402), or a pre-funded API key (BITCOIN_BENJI_API_KEY). Pricing ranges from 2–100 sats (or USD equivalent) per call.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@bitcoinbenji/mcp what are current Bitcoin fees?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Bitcoin Benji API — 26 paid tools for Bitcoin mempool intelligence + sovereign on-prem AI inference.
No third-party APIs. No data leakage. Dual payment rails: Lightning sats (L402) or USDC on Base (x402) — with automatic payment.
Set X402_PRIVATE_KEY to an EVM private key holding USDC on Base and every tool
call pays for itself automatically — no Lightning wallet, no API key, no manual
steps. The server signs an EIP-3009 USDC authorization for each 402 challenge
and retries; gas is sponsored by the facilitator, funds go directly seller-side.
{
"mcpServers": {
"bitcoinbenji": {
"command": "bitcoinbenji-mcp",
"env": { "X402_PRIVATE_KEY": "0x<key holding USDC on Base>" }
}
}
}Related MCP server: @powforge/captcha-mcp
Mempool intelligence (from a real Bitcoin Core full node):
get_fees — fee estimates with trend
get_whales — whale/consolidation alerts
get_mempool_state — live mempool state
get_mempool_history — 24h rolling snapshots
predict_fees — EMA-based prediction
get_recent_blocks — recent blocks
tx_status — lookup any txid
fee_quote — exact fee for a planned tx
AI inference (Qwen3 on dedicated GPU, no third-party APIs):
ai_summarize, ai_sentiment, ai_translate, ai_grammar
ai_code_review, ai_code_generate, ai_extract, ai_classify
ai_rewrite, ai_explain, ai_agent, ai_scrape
ai_embed, ai_vision, ai_ocr, ai_transcribe_table
ai_longform (~50K-word docs flat-fee), ai_research (multi-step + cited)
Pricing: 2–100 sats per call (or the USD-equivalent in USDC: 10 sats = $0.01). See api.bitcoinbenji.com/pricing.
npm install -g @bitcoinbenji/mcpEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"bitcoinbenji": {
"command": "bitcoinbenji-mcp"
}
}
}Restart Claude. Ask: "What are current Bitcoin fees?" — Claude will call get_fees, hit a 402 challenge, return a Lightning invoice. Pay it with any wallet, paste the preimage back, and Claude completes the call.
Same idea — point your MCP-compatible client at the bitcoinbenji-mcp binary.
Pre-fund a key once, then every call auto-debits in the background:
# Get a key (one-time): visit https://api.bitcoinbenji.com or curl /api/key/create
# Then:
export BITCOIN_BENJI_API_KEY="bb_live_..."
bitcoinbenji-mcpOr in Claude Desktop config:
{
"mcpServers": {
"bitcoinbenji": {
"command": "bitcoinbenji-mcp",
"env": { "BITCOIN_BENJI_API_KEY": "bb_live_..." }
}
}
}Most AI inference APIs require a credit card, an account, and a SaaS subscription. This one runs on a sovereign solar-powered AMD Strix Halo box, accepts payment in sats over Lightning, and never leaks your prompts to OpenAI/Anthropic/Google.
github.com/ocbenji/bitcoinbenji-mcp
MIT
General-purpose AI agent — handles any text task. [30 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| context | No | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It mentions a cost of 30 sats per call but fails to disclose other traits like idempotency, authentication requirements, or the significance of preimage and macaroon parameters. The description is too brief for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it omits critical behavioral and parameter details, making it less effective. Every sentence should earn its place, but here one sentence is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is notably incomplete. It lacks guidance on usage scenarios, parameter behavior, and return values, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only preimage and macaroon have descriptions). The description adds no additional meaning beyond the schema; it does not explain 'task' or 'context'. With moderate coverage and no compensatory detail, the value is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'General-purpose AI agent' that 'handles any text task', which is a specific verb-resource combination. Among sibling tools like ai_classify, ai_summarize, etc., it stands out as the general option, providing clear distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used for any text task but does not explicitly state when to use it versus specialized siblings. No exclusions or alternatives are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text into your provided categories. [10 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| categories | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description only notes a cost per call. It does not disclose any behavioral traits such as whether it returns confidence scores, handles unknown categories, or requires internet access. Insufficient for a mutation-like AI tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is not conciseness but under-specification. Important details (e.g., category format, return structure) are missing. Every sentence must earn its place, and this one does not provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 4 parameters, the description is wholly inadequate. It does not explain return format, error handling, or authentication flow for L402 mode. An agent cannot reliably invoke this tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (preimage and macaroon have minimal descriptions). The tool description adds no extra meaning beyond the schema. The key parameters 'text' and 'categories' lack any description or usage hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: classifying text into user-provided categories. It also includes a cost note. However, it could be more specific about the nature of classification (e.g., multi-label, single-label).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like ai_sentiment or ai_extract. No prerequisites, 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.
Generate code from a natural-language spec. [40 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| language | No | ||
| context | No | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral information is the cost (40 sats per call). With no annotations, the description should disclose more about side effects, authentication, or failure modes; it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but mixes purpose and pricing. It is not verbose, but could be structured better (e.g., separate usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks essential context: parameter roles, when L402 fields are needed, and what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters. Schema coverage is low (40%), and the description adds no parameter-level detail. The cost note is unrelated to parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate code) and the input (natural-language spec). It distinguishes from many siblings (e.g., ai_summarize) but not from ai_code_review, which is a related code-focused tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (like ai_code_review). The cost is mentioned but not the context for using L402 parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Code review for bugs, security, and performance issues. [50 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| language | No | programming language (optional) | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the cost (50 sats per call) and indicates the tool checks for bugs, security, and performance issues. However, it does not mention whether the operation is read-only, what the output format is, or any state changes. Given no annotations, more detail on behavioral traits would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a cost note, with no extraneous information. It is front-loaded with the core purpose and is appropriately sized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and four parameters, the description fails to explain the return value (e.g., list of issues, score), language support, or invocation details like whether multiple files can be submitted. It is too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% but the description adds no parameter details. The required 'code' parameter lacks a description in both schema and description, which is a significant gap. The description does not clarify how parameters like language or payment tokens affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs code review for bugs, security, and performance issues, using specific verbs and resources. It distinguishes from sibling tools like ai_code_generate (code generation) and ai_explain (explanation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or when not to use it. It only states what it does, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
768-dim embedding vector for RAG (single text or batch). [2 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | single string OR pass `texts` for batch | |
| texts | No | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
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 a cost of 2 sats per call, which is helpful, but does not explain how authentication works via preimage/macaroon parameters, rate limits, or behavior when both text and texts are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus cost note) and front-loads the key information. Every word is meaningful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not specify the return format (e.g., array of floats). Given the complexity of the tool (4 parameters, payment mechanism), the description lacks completeness for proper agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, which is high. The description adds a small summary ('single text or batch') that overlaps with existing parameter descriptions but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a 768-dim embedding vector for RAG, handling single text or batch input. It uses specific terminology and distinguishes from sibling AI tools (no other embedding tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use for RAG but does not provide explicit when-to-use or when-not-to-use guidance. Among siblings, it is the only embedding tool, so selection is implicit, but prerequisites like payment (L402) are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain any topic at the requested level. [25 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| level | No | beginner | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is the cost of 25 sats per call. No annotations are present, and the description omits information about rate limits, destructiveness, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and a cost note. Every word serves a purpose, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and limited annotations, the description fails to explain the L402 mode parameters, level options, or expected response format. It is too minimal for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning to the parameters 'topic' or 'level' beyond what the schema provides. The preimage and macaroon have descriptions in the schema, but the tool description itself offers no additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Explain' and resource 'any topic' with a modifier 'at the requested level'. It distinguishes from siblings like ai_summarize or ai_rewrite, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites, preferred use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from text (entities/contacts/dates/custom schema). [25 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| schema | No | predefined schema: entities|contacts|dates | |
| custom_fields | No | custom field names to extract | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions cost (25 sats per call). It does not disclose any side effects, required permissions, or other behavioral traits beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one clear sentence and a cost note. It is front-loaded but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain the output format or how custom_fields work. It covers the main purpose but lacks completeness for a tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), and the description adds a bit by listing example extraction types, but it does not significantly elaborate on the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts structured data from text, listing specific types (entities, contacts, dates, custom schema), which distinguishes it from sibling tools like ai_summarize or ai_translate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like ai_classify or ai_research, nor does it specify 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.
Fix grammar, spelling, and punctuation. [15 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions cost per call but does not disclose authentication methods, error handling, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but could benefit from a bit more structure without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and no output schema, the description fails to explain the L402 mode or overall behavior, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but the description adds no additional meaning to parameters; the 'text' parameter lacks even a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fixes grammar, spelling, and punctuation, distinguishing it from sibling text tools like ai_rewrite or ai_summarize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize huge documents (~50K words) in one flat-fee call. [75 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| url | No | alternative to text — fetches & summarizes a URL | |
| focus | No | specific focus area (optional) | |
| max_length | No | medium | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions flat-fee and cost but does not disclose behavioral traits like how summaries are generated, limitations, error handling, or return format. L402 payment mode is hinted but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise with key info: purpose and cost. No wasted words, but could benefit from a brief usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (none required), no output schema, and no annotations, the description is too sparse. Missing guidance on payment (L402), how to choose between text/url, and what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and description adds context about large documents and cost. However, it does not clarify the relationship between 'text' and 'url' parameters or how 'focus' affects output. Baseline 3 with moderate added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Summarize huge documents (~50K words) in one flat-fee call', which specifies the action (summarize), resource (huge documents), and differentiates from siblings like ai_summarize by emphasizing scale and pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for large documents but does not explicitly state when to use this tool over alternatives like ai_summarize, nor when not to use it. No direct guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all visible text from an image URL. [25 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure. It mentions the cost and the L402 payment mode, giving some insight into payment requirements. However, it does not disclose side effects, error behavior (e.g., invalid URL), or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence plus a cost hint. It is front-loaded and efficient, though it could benefit from a bit more structure (e.g., separate sections) for clarity. Still, it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should cover behavior, usage, and return format. It addresses cost and L402 mode but omits details about return values (presumably extracted text), error conditions, and limitations. The description is somewhat incomplete for an agent to fully understand the tool's capabilities without assumed knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with 67% coverage (preimage and macaroon have descriptions in the schema). The tool description adds no additional parameter semantics beyond what is already in the schema. The required 'image_url' parameter lacks a description both in schema and description, leaving its format or constraints unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract all visible text from an image URL,' which is a specific verb+resource combination. It distinguishes the tool from siblings like ai_vision (image analysis) and ai_extract (general extraction) by specifying OCR functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a cost hint '[25 sats per call]' which implies usage context but does not explicitly state when to use this tool over alternatives or provide guidance on when not to use it. No comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-step web research + cited synthesis. [100 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| max_sources | No | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It mentions 'multi-step' and 'cited synthesis,' indicating iterative web searches and citation output. However, it omits details such as how many steps, what happens on failure, authentication requirements (preimage/macaroon in schema but not described), or output format. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one line plus cost note, front-loading the core purpose. Every word earns its place. While slightly terse, it remains effective and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (multi-step web research with citations) and lacks an output schema. The description does not explain the output format, limitations, or typical usage context. This leaves significant gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (preimage and macaroon described in schema). The description adds no parameter explanations; it does not clarify 'question' or 'max_sources' beyond their types/defaults. With no added parameter context, and baseline 3 reduced due to missing coverage, a score of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Multi-step web research + cited synthesis,' which is a specific verb-resource combination. It distinguishes well from sibling tools like ai_scrape (single-page scraping) and ai_summarize (summarization of provided text) by emphasizing multi-step research and citation generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives like ai_agent or ai_scrape. It provides no when-to-use or when-not-to-use guidance, and no mention of prerequisites or context. The cost hint is useful but insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text in a different style/tone. [15 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| style | Yes | e.g. casual, formal, concise, friendly | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions a cost ('15 sats per call'), but does not disclose mutability, side effects, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences front-loading the main action and then the cost. Every sentence adds value, though some depth is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description is insufficient. It does not explain return format, error behavior, or any constraints beyond cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params described). The description adds no new information beyond the schema. Baseline 3 applies as schema covers most parameters, but the missing text parameter description is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rewrite') and resource ('text'), and specifies the action ('in a different style/tone'). It clearly distinguishes from sibling tools like ai_summarize or ai_extract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, limitations, or 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.
Scrape & extract clean readable text from any URL. [15 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It fails to disclose behavioral traits like payment flow (L402), read-only nature, or handling of invalid URLs. Only cost is hinted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, effectively front-loading the core action and cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations; the description omits return format, error handling, and details about the extraction process (e.g., JavaScript rendering, output format). Insufficient for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (67%) with preimage and macaroon already explained in schema. The description adds 'clean readable text' but no extra meaning for the 'url' parameter beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scrape & extract') and resource ('clean readable text from any URL'), clearly distinguishing the tool from siblings like ai_research or ai_explain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a cost ('15 sats per call') but provides no guidance on when to use this tool versus alternatives (e.g., ai_research for academic content) or 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.
Sentiment analysis with confidence score. [10 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks disclosure of behavioral traits such as authentication requirements (L402 explained in schema but not description), error handling, or what happens with empty inputs; cost mentioned but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded with purpose and cost, but omits critical details like authentication and output format, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Incomplete for a tool with no output schema and moderate schema coverage; missing context about input constraints, output format, and auth flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no extra meaning to parameters beyond schema; the required 'text' parameter has no description in either, and L402 fields are only partially explained in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool performs 'sentiment analysis with a confidence score', which is specific and distinct from siblings like ai_classify or ai_summarize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other AI tools like ai_classify for sentiment tasks; no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize text (short/medium/long). [20 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| max_length | No | medium | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds cost information ('20 sats per call'), but with no annotations, it fails to disclose other behavioral traits such as idempotency, state modification, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus cost note) and front-loaded with the primary action, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and the need to explain L402 payment mode (preimage/macaroon), the description is incomplete and assumes prior knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters with descriptions (preimage, macaroon), but the description does not explain the 'text' or 'max_length' parameters beyond mentioning length options, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Summarize text') and hints at output length options ('short/medium/long'), distinguishing it from siblings like ai_extract or ai_rewrite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., ai_extract, ai_rewrite), nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a table image into JSON rows. [35 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose behavioral traits beyond cost. No info on auth, rate limits, error handling, or output format. No annotations provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short, front-loaded with purpose and cost. Could include more helpful guidance without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not explain return format (JSON rows structure). Lacks context for a tool with 3 params and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%. Description adds no new meaning beyond schema; image_url is implied but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Convert'), resource ('table image'), and output ('JSON rows'). Distinguishes from siblings like ai_ocr and ai_vision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. Only mentions cost (35 sats) but not context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate between 100+ languages. [20 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| target | Yes | target language code or name | |
| source | No | source language (optional, auto-detect) | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral trait: the cost of 20 sats per call. However, it lacks disclosure about the L402 payment flow (preimage/macaroon parameters), no confirmation of whether translation is synchronous or what happens on failure, and no annotation support. The cost note is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a cost note, which is front-loaded and avoids unnecessary verbosity. However, given the complexity of the input schema (5 parameters, including L402 fields), a slightly more detailed explanation could be justified without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for the tool's complexity (5 parameters, no output schema, no annotations). It does not explain the L402 payment mechanism, the difference between optional and required parameters, or the expected output format. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters have descriptions). The tool description does not add any further meaning beyond what the schema already provides for those parameters. The undocumented 'text' parameter is not clarified. Baseline 3 is appropriate as the schema carries most of the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Translate') and the scope ('between 100+ languages'), making it distinct from sibling tools like ai_grammar or ai_rewrite which focus on grammar or rewriting rather than general translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose translation over other language tools, nor does it specify conditions like language support or cost implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vision QA over an image URL (Qwen3-VL, sovereign). [40 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| question | No | optional question about the image | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions sovereignty and cost but does not disclose whether the tool is read-only, what happens on invalid URLs, authentication requirements (beyond optional L402 params), or output format. This is insufficient for a tool that may involve payment and remote API calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus cost, which is appropriately concise for a simple tool. It front-loads the purpose and cost. However, it could be more informative without losing brevity, hence a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's relative simplicity, the description omits crucial context such as how to use the L402 authentication parameters (preimage/macaroon), expected output format, and error handling. Given no output schema, the description should provide more guidance on return values or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (only image_url lacks description in schema). The description mentions 'image URL' which adds context for the required parameter. However, it does not elaborate on any parameters, and the schema already describes question, preimage, and macaroon adequately. No extra value beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a Vision QA tool over an image URL using Qwen3-VL, which distinguishes it from sibling tools like ai_ocr (text extraction) or ai_classify. The verb 'QA' implies answering questions, and the resource is an image URL. However, it does not explicitly state that the user can ask questions about the image, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., ai_ocr for text extraction, ai_classify for classification). The cost mention (40 sats) might influence usage but does not constitute clear when/when-not guidance. There are no exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact fee quote for a planned tx: {inputs, outputs, target_blocks, input_type}. [15 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | ||
| outputs | Yes | ||
| target_blocks | Yes | ||
| input_type | No | p2pkh | p2wpkh | p2tr | p2wpkh |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the cost and required parameters, but does not detail other behaviors such as rate limits, idempotency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with the core purpose and a cost note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required), no output schema, and no annotations, the description covers the essential aspects for a fee quote, though it could include more on the return format or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description lists parameter names (inputs, outputs, target_blocks, input_type) but adds no meaningful detail beyond the schema. The optional preimage and macaroon parameters are not highlighted in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Exact fee quote for a planned tx' and enumerates key parameters (inputs, outputs, target_blocks, input_type), distinguishing it from sibling tools like 'get_fees' or 'predict_fees' which offer different fee calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exact fee quotes and notes a cost ('15 sats per call'), but does not explicitly state when to use this tool versus alternatives or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bitcoin fee estimates with trend analysis (next-block, 30-min, 1-hour) from a full node mempool. [10 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the mempool source and cost per call but does not disclose rate limits, authentication requirements (beyond L402 mode), error behavior, or response details. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus a cost note. It is front-loaded and has no wasted words. A slightly more structured format could improve scannability, but it is already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers core functionality and cost. However, it lacks details on output format, prerequisites (API key or L402 preimage/macaroon), and error handling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (preimage, macaroon) for L402 mode. The description adds no extra meaning to parameters beyond what the schema provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides Bitcoin fee estimates with trend analysis for specific timeframes (next-block, 30-min, 1-hour) from a full node mempool. This is specific and distinguishes it from sibling tools like 'predict_fees' or 'fee_quote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (need Bitcoin fee estimates) but does not explicitly state when not to use it or mention alternatives. The cost indication is helpful but lacks guidance on alternatives like 'predict_fees' or 'fee_quote'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rolling 24h snapshots of mempool size and fees. [50 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the tool provides historical snapshots (rolling 24h) and mentions cost. However, it fails to disclose termination behavior (e.g., what happens if no payment or API key is missing), rate limits, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with key information (rolling snapshots, cost). No wasted words; front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with optional parameters and no output schema, the description covers primary function and cost. However, lacks detail on snapshot count, granularity, and expected response, leaving some gaps for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The description adds a tiny bit about 'only needed if no API key set' but does not significantly extend beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Rolling 24h snapshots of mempool size and fees', specifying the resource (mempool snapshots) and attributes (size, fees). It distinguishes from siblings like get_mempool_state (current state) and get_fees (current fees) by indicating historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_mempool_state or predict_fees. The only note is a cost hint ('50 sats per call'), but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live Bitcoin mempool state: tx count, byte size, fee histogram. [5 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions a cost of 5 sats per call but omits other behavioral details such as rate limits, authentication requirements (beyond optional L402 params), or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a cost note, no wasted words. It is efficiently front-loaded with key output information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the output data (tx count, byte size, fee histogram) but lacks details on response format or structure. Since there is no output schema, more completeness would help an agent process the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description. The tool's description adds no additional parameter information beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live Bitcoin mempool state including tx count, byte size, and fee histogram. This distinguishes it from siblings like get_fees or predict_fees which focus on fee estimation, and get_mempool_history which is likely historical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings like get_fees and predict_fees are related but no comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent Bitcoin block data: heights, tx counts, timestamps. [10 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States data returned but not behavior like default number of blocks, rate limits, or side effects. Cost mentioned adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with one sentence and a cost note. No wasted words, but could be better structured with additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description is insufficient. Sibling tools exist for alternative data, but this tool's description lacks completeness about retrieval scope and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema's parameter descriptions and the cost note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies data returned (heights, tx counts, timestamps) with a clear verb 'get'. Differentiates somewhat from siblings like get_mempool_history by focusing on recent blocks, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. Mentions cost but not context for choosing this over other block data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent whale alerts: large transfers, consolidations, distributions in the mempool. [40 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| since_seconds | No | Filter alerts within last N seconds (optional) | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the cost ('40 sats per call') and the type of alerts, but fails to disclose whether the tool is read-only, whether it modifies state, or any prerequisites beyond the L402 mode hinted in parameters. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a cost note. It is extremely concise, front-loads the core purpose, and every character adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the response looks like. It does not mention return format, pagination, or limitations. For a simple listing tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds minimal value beyond the schema; it mentions L402 mode which is already in the schema. No additional meaning is provided for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states what the tool does: 'Recent whale alerts: large transfers, consolidations, distributions in the mempool.' This provides a specific verb-resource combination (get whale alerts) and distinguishes it from sibling tools (which are mostly AI or mempool state tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only explains what it does, not when to invoke it or when to avoid it. Sibling tools are diverse but no explicit comparisons or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EMA-based fee prediction with confidence + direction (rising/falling). [50 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the cost (50 sats per call) but does not clarify authentication requirements or what happens if no preimage/macaroon is provided. Since no annotations exist, the description carries the full burden but only provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core purpose and cost. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information on authentication setup (API key vs L402), expected confidence range, and data format of predictions. For a prediction tool with no output schema, more detail on return values would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the descriptions for preimage and macaroon are already clear in the schema. The tool description adds the cost context ('50 sats per call') which is not parameter-specific, so it does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool's purpose is clearly stated as 'EMA-based fee prediction with confidence + direction (rising/falling)'. It specifies the method (EMA), the output (confidence and direction), and distinguishes from siblings like get_fees (current fees) and fee_quote (quotes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_fees or fee_quote. The description implies use for prediction but does not provide context on prerequisites or 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.
Lookup a Bitcoin transaction by txid: confirmations, fee, block height, mempool ETA. [15 sats per call]
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Bitcoin transaction id (64-char hex) | |
| preimage | No | (L402 mode) Preimage from paid Lightning invoice — only needed if no API key is set | |
| macaroon | No | (L402 mode) Macaroon from the previous 402 challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost (15 sats per call) and specifies returned fields. Does not mention rate limits, authentication details, or error handling, but is adequate for a simple lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a clear list of return fields and cost. Every word is necessary, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description lists return fields. Covers main purpose and cost. Could include more on response format or errors, but sufficient for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond the schema's parameter descriptions. The cost note is tool-level, not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Lookup' and resource 'Bitcoin transaction by txid', listing specific return fields (confirmations, fee, block height, mempool ETA). This distinguishes it from sibling tools like get_fees or get_mempool_state, which focus on aggregate data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for individual transaction status but does not explicitly state when to use or not use this tool vs. alternatives. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ai_agentai_classifyai_code_generateai_code_reviewai_embedai_explainai_extractai_grammarai_longformai_ocrai_researchai_rewriteai_scrapeai_sentimentai_summarizeai_transcribe_tableai_translateai_visionfee_quoteget_feesget_mempool_historyget_mempool_stateget_recent_blocksget_whalespredict_feestx_statusAll AI tools have distinct purposes (e.g., classify, summarize, translate) and are clearly delineated by the 'ai_' prefix. The Bitcoin tools are also distinct from each other and from the AI tools, leaving no ambiguity.
The AI tools consistently use 'ai_' prefix, but the Bitcoin tools mix 'get_' (get_fees, get_mempool_state) with other patterns (fee_quote, predict_fees), creating an inconsistent overall naming convention.
26 tools is on the high side but reasonable given the dual domain (18 AI + 8 Bitcoin). Each tool appears justified, and the count is not excessive for the scope.
The AI toolset covers many common tasks (generation, review, embedding, OCR, research, etc.). The Bitcoin toolset covers mempool, fees, and transaction status, though it lacks some operations like broadcasting.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
L402 MCP: 5 paid BTC/Lightning tools + fiat credits, 10-25 sats/call.
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ocbenji/bitcoinbenji-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
