BlockRun MCP

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries some burden. It adds meaningful behavioral context: mode-to-model mappings, the '1M context' claim for frontier models, and the cost implication via 'free' (no cost) plus the pointer to pricing. It does not disclose output format, rate limits, or that this is a live paid API call, but it does not contradict the annotations.

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

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

The purpose is front-loaded in the first sentence, followed by a scannable bulleted mode list, then direct model picks, then a single pointer to the sibling for pricing. Every sentence earns its place; there is no filler or repetition. The length is justified by the routing information it conveys.

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

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

This is a complex tool (11 parameters, nested messages/thinking objects) with no output schema, so the description should explain return values and edge conditions. It covers model routing well but does not describe what the response looks like (e.g., text vs. thinking blocks) or explicitly route non-text tasks to media siblings. The schema's 100% parameter coverage compensates for some gaps, but the lack of output guidance leaves the definition incomplete.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds significant value by mapping the 'mode' parameter to concrete model pools and listing valid 'model' IDs like 'anthropic/claude-opus-5' and 'moonshot/kimi-k3'. These examples and mode→model mappings go beyond the schema's brief descriptions. Other parameters (stop, temperature, thinking) are already well-covered by the schema.

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

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

The description opens with a specific verb and resource: 'Get a second opinion from another AI model, or use a specialized model for a specific task.' This clearly identifies the tool as the LLM text-generation/chat member of the blockrun family, distinguishing it from the image, music, video, wallet, and search siblings. The mode list further pins down the scope without 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?

The description gives explicit routing guidance by mapping modes to use cases (powerful/reasoning for frontier models, coding for code-specialized, cheap for budget, free for no-cost) and tells the agent to 'Run blockrun_models to see all available models with pricing,' naming the sibling for model discovery. It does not explicitly state when not to use this tool versus media-generation siblings, but the mode guidance and context make the intended usage clear.

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

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

Beyond the readOnly/openWorld annotations, the description adds meaningful behavioral detail: GET-only requests, per-path pricing in USDC, no API key required, and the caveat that the yields response is large and should be filtered client-side. It also discloses the external data source (DefiLlama). These details materially change how an agent budgets and handles responses.

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

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

The description is front-loaded with purpose and cost, then uses a scannable bullet list for the endpoints, followed by concrete examples and sibling routing. Every section contributes either to choosing the tool or calling it correctly; there is no filler.

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

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

For a multi-endpoint read tool with no output schema, the description is unusually complete: it lists all endpoints, their costs, example paths, response characteristics ('TVL history + chain breakdown', 'yields with APY + TVL'), and call-size caveats. It also names alternatives so the agent can decide when not to use it. Nothing essential for selection or invocation is missing.

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

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

The input schema already documents path and agent_id with examples, so coverage is 100%. The description goes further by explaining endpoint syntax variants like protocol/{slug} and prices/{coins}, giving the coin identifier format ('base:0x833589...,coingecko:ethereum'), and noting per-path costs. This gives the agent enough context to construct valid path values beyond what the schema lists.

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

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

The description opens by specifying exactly what the tool does: 'DeFi fundamentals via DefiLlama — protocol TVL, chain TVL, yield pools (APY), token prices.' It then enumerates the five concrete GET paths and gives representative examples. It also names the sibling tools it is not, making distinction immediate.

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

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

The description explicitly routes usage: 'Use blockrun_price (free) for plain spot quotes, blockrun_dex (free) for DEX pairs, blockrun_surf for labeled on-chain data — this tool is for protocol/TVL/yield fundamentals.' This is a clear when-to-use vs when-not-to-use instruction, reinforced by exact path examples for each call shape.

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

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

Annotations already mark the tool as read-only and non-destructive, so the description does not need to cover safety. It adds useful context about being real-time and free, but does not disclose response format, pagination, rate limits, or external API dependencies. This is acceptable given the annotations 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 well-organized with a purpose statement, bulleted use cases, and examples that are easy to parse. The 'FREE - no payment required' line is somewhat extraneous but does not hurt, and the examples justify their place.

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

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

Given the simple read-only nature, optional parameters, and full schema coverage, the description covers the main usage scenarios and gives enough example invocations for an agent to call the tool. It lacks output-shape guidance, but that is less critical for a data query tool with no output schema.

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

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

Schema description coverage is 100%, so the schema already documents chain, query, token, and symbol. The examples add small usage clarity but mostly restate what the schema already says, so the description adds little semantic value beyond the structured fields.

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 gets real-time DEX data from DexScreener and lists specific use cases like token prices, liquidity, volume, and finding pairs. It does not explicitly contrast with siblings like blockrun_defi or blockrun_price, so it is clear but not fully differentiated.

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 'Use for' section gives concrete contexts for when the tool applies, and the examples show typical invocation patterns. It does not explicitly say when not to use it or name alternative sibling tools, so it stops short of full routing guidance.

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

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

Annotations already mark this as readOnly, openWorld, and non-destructive, so the description only needs to add extra context. It adds useful behavioral detail: all calls are POST, each endpoint has specific pricing, contents is capped at 100 URLs, and search categories are listed. It does not cover errors or rate limits, but the annotation coverage lowers that burden.

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

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

The description is front-loaded with the value proposition and then uses a compact, scannable bullet list for endpoints and body shapes. It is longer than a single-purpose tool description, but the multi-endpoint surface justifies the length; the 'documented in skill' note is slightly redundant with the inline shapes.

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 multi-endpoint tool with no output schema, it covers request bodies, path choices, categories, and pricing, and points to the exa-research skill for full response shapes and workflows. The main gap is that response semantics are deferred to an external skill rather than summarized inline.

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?

Even though every schema property has a description, the tool description adds substantial value beyond the schema by listing the four valid path values, the exact body shape for each, optional fields such as numResults and includeDomains, accepted categories, and pricing. An agent can construct a correct request without needing to open the external skill.

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

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

The description clearly identifies Exa as the resource and names the core capability ('Neural web search... understands meaning'), then enumerates four concrete endpoint paths. It stops short of explicitly differentiating itself from sibling tools like blockrun_search beyond the 'not just keywords' hint.

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?

'Great for research' provides a clear context for when this tool is appropriate, and the endpoint/pricing breakdown helps an agent choose the right path. However, it does not explicitly state when to prefer blockrun_exa over sibling search tools 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.

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

With all annotation hints false, the description supplies the real behavioral burden: costs USDC on the active chain, requires no API key, supports specific input formats/array constraints, and exposes per-model price and capability differences. It also discloses the inline-preview env default and limitation that masks are openai/gpt-image-* only and exclude multiple source images.

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 long but effectively structured: front-loaded action summary, then actions, then models, then input-format constraints. Some details such as mask/source-image formats repeat the schema, so it is not maximally concise, but every large block adds non-obvious information.

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

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

Given the tool's nine parameters and no output schema, the description covers almost everything an agent needs before invoking: payment, model selection, input formats, multi-image limits, size constraints, and inline preview behavior. It routes chain/wallet setup to blockrun_wallet, leaving no critical parameter or action unexplained.

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, yet the description goes well beyond it by attaching prices, quality tiers, and recommended use cases to each model and by clarifying size/model compatibility and multi-image rules. This materially improves parameter choice for prompt, model, action, image, mask, size, and inline.

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 identifies the tool as image generation/editing via BlockRun, with distinct 'generate' and 'edit' actions and a concrete resource. The first sentence tells the agent exactly what it does, so it cannot be confused with image-unrelated siblings like blockrun_music or blockrun_video.

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?

Descriptions of the default action, edit action, and model trade-offs give concrete selection guidance. It names blockrun_wallet for payment/chain context and lists model-specific use cases such as 'renders on-image text best' and 'for 4K photorealism', though it does not spell out 'use X instead of this tool' exclusions.

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

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

Although annotations already declare readOnly/openWorld/non-destructive, the description adds substantial behavioral detail: flat pricing per call, endpoint-specific requirements such as polymarket/orderbooks needing token_id plus Unix-millisecond start/end_time, smart-money needing a criterion beyond 'window', and candlestick interval behavior that varies by market. This far exceeds what the annotations convey.

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 long, but it is well structured with tiered sections, bullet lists, and a dedicated request-contract block, making the content navigable. The opening states the resource and pricing immediately; however, the sheer volume and some redundancy in endpoint listings prevent it from being truly 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?

For a multi-endpoint aggregator with no output schema, the description is unusually complete: it covers endpoint categories, filters, pagination, request sequencing, required params per endpoint, pricing, and POST exceptions. An agent has enough context to select an endpoint and invoke it correctly even without knowing exact response shapes.

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 already documents all four parameters, but the description meaningfully enriches them with endpoint path examples, a concrete params example, correct filter names ('search' vs 'q'), status conventions, and the GET/POST body contract. This tells an agent exactly how to populate path, params, and body in practice.

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

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

The description opens with 'Prediction market + derivatives data via Predexon aggregator' and immediately frames the tool as a 'CANONICAL CROSS-VENUE (Tier 1) — Predexon v2 unified data layer', which clearly identifies what resource the tool operates on. It is much more than a tautology, but it is structured as an endpoint catalog rather than a single verb+resource statement, and it does not explicitly contrast with sibling Polymarket-focused 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?

The 'REQUEST CONTRACTS' section gives concrete sequencing guidance — use markets/search to discover, then resolve via polymarket/markets/keyset — and explains GET vs POST usage and filter naming quirks across endpoints. This is clear operational context, but there is no explicit guidance on when to use this tool versus blockrun_polymarket or blockrun_polymarket_read, so no exclusions/alternatives are stated.

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

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

Annotations already indicate this is a mutating, open-world, destructive tool. The description adds crucial behavioral context beyond annotations: timeout is the billed lifetime, charged upfront with no refunds, sandboxes terminate on timeout/budget reset, and GPU access is capped at H100. This is fully consistent with readOnlyHint=false and destructiveHint=true.

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?

Despite being long, the description is front-loaded with purpose and usage guidance, then uses compact bullet lists for pricing and endpoint schemas. Every sentence earns its place, espacially the billing warning, which is essential for correct invocaation and cost awareness.

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 multi-endpoint, high-stakes billing tool with no output schema, the description is nearly complete: it covers paths, request bodies, pricing, GPU limitations, termination behavior, and budget replan. The main gap is that it never explicitly states what responses look like, e.g., that sandbox/create returns a sandbox_id needed for subsequent calls, though the endpoint list implies this chaining.

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 only describes 'body' as a JSON POST body, so the description adds real semantic value by specifying per-endpoint body shapes such as { image?, timeout, cpu?, memory?, gpu?, setup_commands? } for sandbox/create and { sandbox_id, command, timeout? } for sandbox/exec. It also clarifies path examples and the billing meaning of timeout, going well beyond the thin schema descriptions.

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

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

The description opens with a specific verb and resource: 'Run isolated code in a BlockRun-hosted Modal sandbox — disposable remote container, optional GPU.' It then lists concrete endpoints under /v1/modal/, making the tool's scope unmistakable and clearly distinct from sibling tools like blockrun_image or blockrun_chat.

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

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

It explicitly states when to use the tool ('clean ephemeral environment', 'GPU access', 'safer place for untrusted code') and when not to ('Prefer local tools for normal repo work'). It also enumerates the available POST paths, helping the agent choose the right operation within the tool.

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

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

Annotations already mark this as read-only and non-destructive, lowering the burden on the description. The description adds useful context by noting that results include pricing and that the tool supports discovery and cost comparison. There is no contradiction with the annotations, and no hidden side effects are implied.

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

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

Two concise sentences with no wasted words. The core purpose is front-loaded, and the usage guidance is immediately actionable. Every sentence earns its place.

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

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

For a simple read-only listing tool with two optional parameters and no output schema, the description provides sufficient context: it names what is listed, includes pricing, and states the intended use. The schema covers filtering, and annotations cover safety, so no critical information is missing.

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 both parameters (category and provider) are already fully documented in the schema. The description adds no parameter-level detail, but based on the high schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific action and resource: 'List available AI models with pricing.' It clearly communicates that this tool is for discovery and cost comparison, which distinguishes it from siblings like blockrun_chat or blockrun_image that execute model tasks rather than list them. It does not explicitly name a sibling alternative, but the purpose is unambiguous.

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

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

The description gives clear context: 'Use to discover models and compare costs.' This tells an agent when the tool is appropriate, although it does not explicitly state when not to use it or mention alternatives. Still, for a simple listing tool this level of guidance is sufficient.

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

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

Description discloses important behavioral traits beyond annotations: async submission with polling, time range, failure/no-charge semantics, model and cost, track length, and permanent URL return. Annotations are sparse, so this richness is valuable and fully covers what an 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.

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

Front-loaded with the core purpose, followed by compact high-value details on timing, payment, cost, and output. Every sentence contributes useful information, with no repetition or filler.

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

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

The description is complete for an async media-generation tool with no output schema: it covers behavior, cost, timing, failure conditions, model, and return value. The schema covers parameter specifics, so nothing required for correct invocation is missing.

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%, with each parameter already documented (prompt, lyrics, instrumental, agent_id). The description adds cost and duration context but does not provide parameter-level meaning beyond the schema, so 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?

States a specific verb and resource: 'Generate music tracks via BlockRun x402'. This clearly identifies the tool as the music-generation sibling among image, video, and speech tools, so an agent can distinguish it without opening schemas.

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?

Clear contextual guidance is provided: async client-polled operation, 1-3 minute completion time, payment only on success, and no charge on failure. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description goes further by disclosing costs, 30-day leases, release-to-pool side effects, and the wallet-ownership requirement. It also marks which operations are free, which are paid, and what the flat call rate is.

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

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

The description is dense but well structured: a one-line summary, a compact bulleted endpoint list with pricing, and short requirement/format sections. Every line carries actionable information with no filler. The critical requirement about wallet-owned numbers 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?

The definition covers all main endpoints, prerequisites, costs, number format, and voice presets, which is strong for a multi-endpoint tool. However, it defers 'full body shapes' for voice/call to an external `phone` skill and leaves the semantics of `task` undefined, so an agent may need additional information to construct a fully valid voice call request.

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 only describes path generically and body as a JSON object, but the description maps specific path strings to endpoints, lists exact body key shapes, marks `from` as required for voice/call, and gives E.164 formatting. This is far more semantically useful than the schema alone.

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

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

The description opens with a precise summary: 'Phone-number intelligence, US/CA number provisioning, and outbound AI voice calls.' It then enumerates eight distinct endpoints with method, body, and purpose, making its scope and resource clear and separating it from sibling tools.

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

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

Provides explicit endpoint routing under 'Common paths', states the prerequisite that voice/call 'from' must be a wallet-owned number provisioned via phone/numbers/buy, and explains when to use the free GET poll instead of a POST. This gives clear when-to-use and prerequisite guidance.

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

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

Beyond the annotations, the description discloses real-money spending, local key signing, gasless wallet creation, fees, non-custodial bridging, dry-run behavior, per-order caps, and geoblock routing. This gives the agent an unusually complete picture of side effects and operational constraints.

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

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

The description is long but earned: the first sentence establishes purpose and risk, followed by a mandatory setup note, a clean bulleted action reference, and closing notes on pricing, region handling, and compliance. There is no filler.

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

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

Given 15 parameters, real-money transactions, and no output schema, the description covers prerequisites, funding flow, order mechanics, cancellation, redemption, withdrawal, fees, safety gates, and jurisdiction notes. An agent has enough context to call this tool correctly and safely.

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?

Although the schema covers all parameters at 100%, the description adds action-specific meaning: token_id or condition_id+outcome resolution, price+size vs amount_usd semantics, confirm:true as a required side-effect gate, order_type defaults, and withdraw defaults for amount_usd and to_address. This materially exceeds the schema documentation.

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

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

The description opens with a concrete verb and resource: 'Trade on Polymarket prediction markets (CLOB V2, Polygon)'. It then lists all nine actions with one-line semantics, making the tool's scope unmistakable and distinguishing it from discovery tools like blockrun_markets.

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

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

It gives explicit sequencing guidance: 'Run action: "setup" FIRST (and again after funding)' and tells the agent to 'discover markets/prices/token IDs with blockrun_markets first'. It also clarifies when confirm:true is required versus when a dry-run preview is returned, and explains market vs limit order parameter combinations.

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

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

Annotations already mark readOnlyHint and destructiveHint false, and the description reinforces them with concrete commitments: 'This action never accepts confirm and never signs or submits an order.' It also discloses the data sources, CLOB book and Data API, and clarifies that previews are live but non-mutating.

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, bulleted by action, and front-loaded with the all-important safety statement. Every sentence adds functional value, and sibling routing is compressed into one clear sentence.

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 exists, but the action bullets summarize what each call returns: Holdings, value, PnL, and redeemable status; open CLOB orders; and live order previews. Combined with a l00% schema-described parameters, the description gives the agent enough context 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.

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

Schema coverage is 100%, but the description adds critical combination logic beyond the schema: preview requires side plus token_id or condition_id+outcome, market buys use amount_usd, limit orders use price+size, and condition_id filters orders. These cross-parameter requirements are not inferable from the individual parameter descriptions alone.

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 opening line specifies a read-only verb and resource with a clear safety boundary: 'Read or preview Polymarket state without signing or changing anything.' The action list explicitly names positions, orders, and preview, making the tool's scope unambiguous and distinct from the funds-affecting sibling.

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 final sentence gives explicit routing guidance: 'Use blockrun_polymarket only for setup and funds-affecting operations' and enumerates confirmed buy/sell, cancel, redeem, fund, or withdraw. This directly tells the agent when to use this tool versus its sibling.

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

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

Annotations already mark the tool read-only and non-destructive, and the description adds substantial behavioral context on top: per-category pricing, free list discovery, Pyth as the data source, session being ignored for non-equities, and unix timestamp requirements. This goes well beyond the safety profile conveyed by annotations.

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

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

The description is well-organized into a summary, action list, pricing section, market list, and examples. Every section earns its place, and the examples are compact yet illustrative. There is no vague filler, despite covering multiple actions, categories, and cost models.

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

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

Given the tool's complexity (11 parameters, 5 enums, 3 actions, no output schema), the description covers the required category/action pairing, all market codes, pricing, and example payloads. A minor gap is the lack of response-shape details for the returned quotes or OHLC bars, but this isn't essential for selecting and invoking 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?

With 100% schema coverage, the baseline is 3. The description adds real semantic value through examples that show valid parameter combinations, the stocks/market dependency, default resolution behavior, and action-specific fields. It doesn't document every parameter beyond the schema, but it clarifies how to use them together.

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

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

The description opens with a precise statement of what the tool returns: realtime quotes and OHLC history for crypto, FX, commodities and 12 stock markets, Pyth-backed. It enumerates three concrete actions (price, history, list) and provides examples, making its scope distinguishable from sibling market/data tools without 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?

The description gives clear conditions for each action, pricing tiers, and the market requirement for stocks, so an agent knows when to invoke which action. It stops short of naming sibling tools to avoid, and doesn't explicitly enumerate when-not-to-use cases, but the action-level guidance is strong.

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

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

Annotations only indicate the tool is not read-only, but the description adds substantial behavioral context: multi-step liveness enrollment, free vs. paid actions, H5 link expiration (~120s), polling for active status, and privacy guarantees that BlockRun does not store face/liveness data. This goes far beyond what annotations provide and does not contradict them.

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

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

The description is long, but every section earns its place given the multi-step workflow. It is front-loaded with the core purpose, uses bullet-style sections for actions, and includes a typical flow that converts complex sequencing into an easy-to-follow pattern. The privacy note is a useful closing detail rather than fluff.

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

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

For a complex paid/free multi-step tool with no output schema, the description is remarkably complete: it explains init/status/enroll/portrait/list, costs, liveness requirements, expiration behavior, model compatibility, and expected results (ta_xxxx asset ids). An agent has enough context to invoke all five actions correctly and route to blockrun_video afterwards.

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?

Although the schema already covers all parameters, the description adds critical semantics: which actions require which parameters, group_id can refresh an expired link, image_url must be the same person as the liveness check, and action-specific behavior. It also clarifies that name is required for init, enroll, and portrait, which is not obvious from the top-level schema alone.

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

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

The description opens with a specific verb-resource statement: enrolling a real person's face as a BytePlus RealFace asset and using it to drive Seedance 2.0 video. It clearly distinguishes the tool from siblings by explaining what it feeds into (blockrun_video real_face_asset_id) and separating real-person vs. portrait enrollment.

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

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

The description gives explicit when-to-use guidance for each action, including when to use portrait versus the liveness flow for real people. It also states model compatibility constraints (seedance-2.5 does not accept ta_ assets) and provides a typical end-to-end flow, making it easy for an agent to select and sequence calls correctly.

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

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

Annotations already signal openWorldHint and destructiveHint, and the description adds useful context on cost, no-node/no-API-key auth, unknown network slug pass-through, and raw chain-native methods. It doesn't explicitly warn that some methods can change state, but the destructiveHint annotation and 'raw JSON-RPC' framing cover that.

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

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

The description is front-loaded with the core value proposition and pricing, followed by use case, network list, examples, and alternatives. Every section contributes actionable information, and the examples make it easy for an agent to mimic the call shape.

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 broad raw-RPC tool with no output schema, the description provides enough to call it correctly: networks, examples, batch usage, pricing, and alternatives. It does not describe the JSON-RPC response/error shape, but that is fairly standard and inferable from the protocol and examples.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema with concrete examples mapping network, method, params, and a batch body example, plus clarifying that body overrides method/params. It doesn't add examples or explanation for agent_id, but the schema already documents that.

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 a specific purpose: raw JSON-RPC access to 40+ blockchains via one endpoint, with explicit examples showing usage. It also distinguishes itself from higher-level sibling tools by noting it is for data those tools don't cover.

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

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

The description explicitly says when to use this tool ('use when you need data the higher-level tools don't cover') and when not to use it ('Prefer blockrun_price, blockrun_dex, or blockrun_surf when they cover the question'). It names concrete alternatives, making routing unambiguous.

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

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses pricing, cost calculation, defaults, lower/upper bounds on max_results, and source behavior. This gives an agent crucial cost and scope information before invocation.

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

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

The description is front-loaded and most sentences carry useful cost or request-shape information. However, it ends with an incomplete sentence ('Full request shape + worked examples in the') and the pricing block is longer than strictly necessary.

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

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

An agent can construct a valid call: body shape, sources, max_results bounds, and date formats are all provided, and the readOnly annotations cover safety. It falls short of full completeness because the promised full request shape/examples are cut off and the return payload is only vaguely described as AI-summarized results with citations.

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 but terse; the description adds real semantics for the body parameter: query, sources array choices, max_results range/default, and date format. It effectively documents the nested request body that the schema leaves implicit.

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 opening line identifies a specific function: real-time web/X/Twitter/news search with AI-summarized results and citations. It does not explicitly name sibling search tools like blockrun_exa, so it falls just short of full sibling 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?

Provides practical guidance: use ['x'] for tweet-only searches, set max_results to control cost, and 3 sources is often enough for a plain fact. However, it never explains when to prefer this tool over blockrun_exa/surf or when not to use it, leaving cross-tool routing mostly to inference.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure. It goes far beyond annotations by specifying pricing, per-model latency and characteristics, the prompt-directed behavior of bytedance/seed-audio-1.0 (voice parameter ignored), and that the returned hosted URL requires immediate download. This is rich, non-obvious 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 long but every sentence delivers useful information: purpose, actions, pricing, models, aliases, behavioral caveats, and return-value guidance. It is logically organized with line breaks and no filler, making it dense yet easy to scan.

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 9 parameters, 3 enums, no output schema, and minimal annotations, the description is remarkably complete. It covers return value behavior, pricing, model selection, voice handling, parameter constraints, and action differences—everything an agent needs to invoke 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?

Although schema description coverage is 100%, the description adds substantial meaning: it expands the voice aliases, explains when the voice param is ignored, gives model-specific billing details, clarifies action-specific parameter usage, and describes the output as a hosted audio URL. This far exceeds the baseline for fully covered schemas.

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 purpose: 'AI voice via BlockRun x402 — speak text aloud (ElevenLabs or ByteDance Seed Audio), generate sound effects, list voices.' It enumerates distinct actions, models, and voice aliases, giving agents a concrete understanding of what the tool does and how it differs from non-speech siblings like image, music, or video 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?

The description provides clear action-level guidance: use 'speak' for text-to-speech, 'sound_effect' for cinematic effects, and 'voices' to list voices. It does not explicitly name sibling tools to contrast with, so while the usage context is strong, it lacks the explicit when-not-to-use-alternative statements that would earn a 5.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds worthwhile behavioral detail: pricing settled in USDC per call, method auto-routing based on body presence, and pre-validation behavior that returns a 400 rather than a charge for missing required fields. This goes beyond annotations and helps the agent understand side effects and error behavior.

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

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

The description is longer than average, but the structure is effective: purpose, coverage, pricing, common paths, and routing behavior are clearly separated. The extra details about cost and error handling are relevant for a paid API gateway. Minor redundancy exists, but no sentence feels wasted.

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 broad 83-endpoint gateway with no output schema, the description covers the essential operational context: what data domains are available, how to route methods, what parameters look like, cost implications, and where to find the full endpoint catalog. It could include output-shape guidance, but that is not required given its absence from output schema and the explicit catalog link.

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%, giving a baseline of 3. The description adds value by showing concrete endpoint path examples such as 'market/price?symbol=BTC' and the onchain/sql body shape, clarifying how path, params, and body interact. This materially helps an agent construct valid calls.

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

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

The description clearly identifies the tool as a unified crypto data gateway via Surf, listing concrete coverage areas (CEX, on-chain SQL, prediction markets, social mindshare) and example paths. It lacks an explicit contrast with sibling data tools, so it is clear but does not fully disambiguate among similar siblings.

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

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

The description gives common paths and method auto-routing, which implies when to use the tool for data lookups. However, it does not provide explicit when/when-not guidance relative to sibling tools like blockrun_markets, blockrun_price, or blockrun_polymarket. The usage context is present but not stated as a decision rule.

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

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

Beyond the minimal annotations, the description discloses async waiting times, hard caps, failure/no-charge behavior, permanent GCS-backed URL, payment inclusion, and per-model resolution/audio behavior. It gives the agent an accurate mental model of side effects and cost consequences.

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?

Long but deliberately structured and front-loaded: purpose and async behavior first, then model bullets and caveats, then return value. Given 10 parameters and seven provider models, the density is justified and no sentence is filler.

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

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

For a complex paid generation tool with no output schema, the description is unusually complete: it covers invocation, polling, costs, model differences, constraints, failure semantics, and says the return is a permanent MP4 URL. Nothing critical is left for the agent to guess.

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%, but the description adds substantial semantics: per-model duration ranges and defaults, resolution multipliers and per-model ceilings, aspect-ratio handling by provider, RealFace prerequisites/mutual exclusion, and last-frame requirements. It goes far beyond the schema's generic property descriptions.

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

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

The description opens with a specific verb and resource: generate short AI videos via BlockRun x402, and clearly distinguishes the output (short MP4 clip) from sibling image/audio tools. It also names the async client-polled behavior up front, so an agent knows exactly what operation this tool performs.

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

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

Provides explicit model-selection guidance with tradeoffs (quality, price, resolution, RealFace, duration ceilings), including when to choose 2.0 vs 2.5 and when RealFace requires blockrun_realface first. It states when image-to-video is not cheaper, when audio should be disabled, and which models ignore certain parameters.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses significant behavioral side effects: deposit 'mints a one-time Coinbase Onramp link and opens it in the browser,' chain switch 'provisions + activates the Solana wallet,' and budget/delegate/revoke actions modify spending state. It also reveals the two-wallet architecture and active-chain behavior that annotations cannot express.

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 long but highly structured with clear section headers (Actions, Budget controls, Multi-agent orchestration, Usage pattern) and front-loaded critical guidance in the first three sentences. Every section earns its place given the tool's 9 actions, 6 parameters, and multi-chain behavior. The formatting makes it scannable despite its length.

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

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

No output schema exists, but the description compensates by describing what status reports ('both addresses/balances and which is active' and 'session spending'). It covers the full action matrix, cross-chain provisioning steps, Base-only restrictions for sibling tools, budget controls, multi-agent delegation, and the recommended usage pattern. Nothing an agent needs to correctly invoke this tool is missing.

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?

Although the schema already documents all 6 parameters (100% coverage), the description adds substantial meaning: it explains each action value with usage examples (e.g., 'chain + chain:"base"|"solana" → Switch the active payment chain'), clarifies defaults ('status (default)'), states that agent_limit is required for delegate, and describes the effect of omitting chain ('omit chain: to just see the current one'). This goes well beyond the schema's terse 'What to do'.

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 opens with a specific verb and resource: 'manage the BlockRun payment wallet and control agent spending budgets.' It distinguishes itself from the 19 sibling blockrun_* tools by immediately stating what it is for and ends with an explicit exclusion: 'Do NOT call this for actual AI queries — use blockrun_chat for that.' This leaves no ambiguity about its purpose relative to siblings.

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

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

The description gives concrete when-to-use rules: call first on payment/balance errors, before expensive operations, and before spawning child agents. It also names alternatives and exclusions ('Base-only... need Base: blockrun_music...' and 'use blockrun_chat for that'), making the routing decision explicit.

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