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

Annotations cover read-only and open-world behavior, and the description adds real value beyond them: where credentials must live ('x-api-key' / Bearer header in MCP client config), the explicit prohibition on passing keys as tool parameters, and the shape of the response (HTTP status plus JSON body). It does not mention rate limits or error semantics, but the auth/credential-placement warnings are substantive.

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

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

Three sentences, front-loaded with purpose, then auth requirement, then return format. Dense and mostly waste-free, though the authentication sentence carries some parenthetical detail that could be tightened.

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

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

An output schema exists and parameter descriptions are complete, so the description need not explain returns, and it still summarizes them briefly. It covers the critical operational detail (credential placement) and points to the required external contract, missing only guidance on sibling selection and error handling.

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 fully documents chain, path, and query, and the baseline is 3. The description adds only a pointer to the external OpenAPI contract rather than elaborating on parameter usage, so no credit above baseline is earned.

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 (query) and resource (the BlockVectra Data API) with scoping by chain and path. It is clear what the tool does, though it does not explicitly distinguish itself from the similarly generic sibling rpc_call or explain when the Data API is preferable.

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 tells the agent to consult the external OpenAPI contract for endpoint schemas and gives explicit client-configuration requirements for authentication. However, it offers no when-to-use / when-not-to-use guidance relative to siblings like rpc_call or get_status, leaving the choice 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot convey: it works without an API key, it depends on free credit allowances from /v1/plans, and it projects API-key count under key_defaults. It does not discuss latency or rate limits, so a 4 rather than a 5.

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

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

Front-loaded with purpose, then usage scope, then alternatives, then parameter shape — a sensible ordering. The final sentence largely duplicates what the schema already states, making it the one line that does not fully earn 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies everything else an agent needs: no-auth availability, the /v1/plans dependency, the dual input modes, and sibling disambiguation. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% and every parameter is documented in the schema, including the 'single-method mode' wording itself. The description's closing sentence restates the 'lines' array shape and the method/calls_per_day pairing without adding format, defaulting, or precedence rules (e.g. what happens if both modes are supplied). 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 ('Calculate projected daily and billing cycle Compute Units (CU) and USD costs') plus the inputs it consumes (planned call volumes, method weights, free credit allowances). It is immediately distinguishable from sibling tools like get_pricing and get_method_info, which are named explicitly.

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

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

Explicitly routes the agent: 'Use this tool for volume budget calculations and capacity planning. For looking up raw system pricing tables, use get_pricing instead. For checking whether a single method is supported on a specific chain, use get_method_info instead.' Both the when-to-use and the alternatives are stated with the condition that selects them.

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

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

Annotations already establish a safe read-only, closed-world lookup, and the description goes beyond that by enumerating the decision-relevant outputs: billing implications, retryability, retry delay, and recommended agent action. It does not discuss rate limits, auth needs, or behavior when an unknown code is supplied, so it falls short of a 5.

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, no filler, action and scope front-loaded before the return-value inventory. Every clause earns its place; nothing is repeated from the name or title.

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

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

An output schema exists, so the description is not obliged to explain return values, yet it does so constructively to support retry decisions. It is complete for a simple catalog lookup with full schema coverage; the only gap is the unresolved question of how to select among the four optional 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 description coverage is 100%, so the baseline is 3 and the schema already documents code, reason, http_status, and lang with examples. The description adds nothing about parameter semantics — notably it never says whether the four lookup keys are mutually exclusive or which takes precedence, which matters because zero parameters are required.

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 (lookup) and resource (error code/reason/HTTP status in the official error reference catalog), plus the payload it returns. The 'official error reference catalog' scoping cleanly separates it from siblings like search_docs, read_doc, and list_docs, so an agent can pick it without inspecting 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?

The trigger is implied: call this when you hold an error code, reason slug, or HTTP status and need its meaning. There is no explicit statement of when NOT to use it, nor a pointer to an alternative (e.g. search_docs for free-text errors), which the rubric requires for a 4-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?

Adds meaningful behavior beyond the readOnlyHint/openWorldHint annotations: it discloses cost behavior ('free and unbilled'), the exact auth mechanism ('x-api-key' or 'Authorization: Bearer <key>' in client config), and the important constraint never to pass keys in tool parameters or chat. It does not discuss caching, freshness beyond 'balance_as_of_age_ms', or failure modes.

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

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

Front-loaded with purpose and endpoint, followed by cost, auth, and return fields in three efficient sentences. The final enumeration of return fields is somewhat redundant given an output schema exists, costing a little tightness.

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

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

For a zero-param read tool with annotations and an output schema, the definition covers purpose, auth, and cost. The return-field list duplicates what the output schema already provides, but no decision-relevant 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?

The tool takes zero parameters, which is the baseline-4 case; there are no parameter semantics to clarify. The description correctly avoids inventing parameters and reinforces that keys must not be passed as arguments.

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 ('Get the API key's own balance, Compute Units (CU), rate limits, and key parameters') plus the backing endpoint GET /v1/account. This is clearly distinguishable from siblings like get_status, estimate_usage, and get_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?

Gives strong context for when to call it: 'Free and unbilled', which signals it is safe to use for quota/limit checks. It does not, however, explicitly route the agent away from alternatives (e.g., estimate_usage vs this tool), so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely new behavioral context: the API-key authentication requirement and the constraint that transfers must target only the listed networks/tokens, which guards against misuse of the returned address.

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?

A single front-loaded sentence: the auth prerequisite comes first, then the purpose, then the transfer restriction. No filler, 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?

With an output schema present, the description need not explain return values, and annotations cover the read-only nature. Auth and transfer-safety caveats are supplied, so only selection guidance relative to sibling tools 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?

There are zero parameters, so the baseline is 4. The description correctly adds no parameter detail, and there is nothing for it to compensate for.

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

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

The description states a specific verb and resource: retrieving the account's dedicated on-chain deposit address plus the set of open networks for topping up a balance. That combination is distinctive against siblings like get_account or list_chains, so an agent can identify the tool without opening the schema.

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 implies the context (funding your balance) and gives one operational rule ('only transfer to the listed networks and tokens'), but it never says when to prefer this over alternatives such as get_account or list_chains, nor any exclusions. Usage is implied rather than 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it aggregates from /v1/chains, /v1/status, and /v1/plans, and explains that JSON-RPC policy follows methods.allow/deny while Data API coverage follows data_features — non-obvious distinctions an agent would otherwise have to guess.

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 what the tool returns, then policy sourcing, then alternative routing — a sensible ordering. It is dense with cross-references to /v1 endpoints, but each sentence carries distinct information and nothing is padding.

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

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

With an output schema present, the description need not restate return values, and it instead supplies the missing context: where each piece of data originates and which sibling tools to use for adjacent questions. Nothing an agent needs to call this correctly is absent.

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

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

Schema description coverage is 100% and both parameters are already documented in the input schema, including examples of valid method names. The description adds the nuance that 'method' spans both JSON-RPC methods and Data API datasets, but gives no additional syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The first sentence gives a specific verb ('Inspect') and resource ('a single method') and enumerates exactly what is returned: chain-by-chain availability, CU weight, price per million calls, and a documentation link. This is precise enough to separate it from get_pricing and estimate_usage without opening any schema.

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

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

Explicitly routes the agent: 'For the full system-wide pricing schedule and rate card, use get_pricing instead' and 'For calculating projected bills... use estimate_usage instead.' It also states which upstream sources govern each policy dimension, so the agent knows what this tool does and does not cover.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that values are live from GET /v1/plans plus interpretive caveats such as promo.ends_at being a sign-up coverage cutoff rather than the offer's end. It doesn't mention auth or caching/refresh behavior, so it stops short of a 5.

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?

Purpose and usage are front-loaded and every clause carries meaning, but it is a single unbroken paragraph mixing lookup rules and field-level semantics that the output schema may already carry. Dense rather than wasteful, but not optimally 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?

For a zero-parameter, read-only lookup with an output schema, the description supplies the unit definitions, method-weight resolution fallback rules, and sibling routing an agent needs to interpret and act on the result. Nothing material 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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate.

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+resource ('Live prices and plan limits') and even names the source endpoint (GET /v1/plans), making it immediately distinguishable from siblings like get_method_info and estimate_usage.

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

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

Gives explicit triggers ('Use before estimating cost or when asked about free credits, rate limits or per-method prices') and explicit exclusions routing to alternatives: get_method_info for a single method's chain support/docs and estimate_usage for cycle-cost projection.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: it enumerates the data_status states and explains that 'syncing' is still queryable and billed normally but indexes behind the latest block, which materially affects how an agent should interpret the result.

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

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

Three compact sentences, front-loaded with the core purpose before the prerequisite and the status-value detail. The parenthetical about 'syncing' is slightly dense but its billing/indexing nuance earns the space.

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

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

For a zero-parameter status endpoint with an output schema and read-only annotations, the definition supplies everything needed: what it reports, the prerequisite check, the adjacent tool for static info, and the interpretation of the status states.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly makes no claims about inputs.

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 ('Live operational status and network health') and grounds it in a concrete endpoint (GET /v1/status). It also differentiates itself from the sibling list_chains by contrasting live status against static chain capabilities and method policies.

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

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

Gives an explicit prerequisite ('Confirm chain status is "ok" before calling methods') which tells the agent exactly when this call is warranted, and routes to the correct alternative (list_chains) for a different need. Both the when-to-use and the alternative are named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully discloses that the response contains instructions, endpoints, auth header and URL formats, which goes beyond the annotations. It stops short of stating that it is static/purely informational content with no side effects or live key generation.

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?

A single dense sentence that front-loads the purpose and appends the useful extra content (auth headers, URL formats). It is efficient, though the trailing clause makes it slightly crowded.

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

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

With an output schema present, the description need not explain return values, and it still summarizes the content returned. For a read-only helper tool this is largely complete; only explicit guidance on choosing between the two sign-up paths 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 a single enum-constrained 'lang' parameter fully documented in the schema, so the baseline is 3. The description adds no extra meaning about the language parameter or its default beyond what the schema provides.

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

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

The description states a specific verb ('Get instructions and endpoints') and a precise resource ('obtaining a BlockVectra API key'), naming the two acquisition paths (programmatic SIWE sign-up or browser handoff) and the extra payload (auth header and URL formats). It does not explicitly differentiate itself from doc-oriented siblings like read_doc or search_docs, but the resource is specific enough to identify the 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?

Usage is implied — an agent would call this when it needs an API key — but there is no explicit when-to-use statement or routing versus alternatives such as search_docs or read_doc. The mention of 'preferred programmatic SIWE sign-up or browser handoff' hints at choice, yet the description never tells the agent how to select between the two paths.

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 provide readOnlyHint and openWorldHint, so the bar is lower, yet the description goes far beyond them. It documents wildcard pattern semantics with deny precedence, the state_window_blocks null case, the inclusive max_logs_block_range constraint and its logs_range_too_large failure, and the keyless public endpoint's method/history scoping — rich operational context an agent cannot infer elsewhere.

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?

Purpose is front-loaded in the first clause, and the remaining sentences are dense with field semantics rather than filler. It is long and somewhat wall-of-text, but every sentence carries operational meaning, so it stays on the right side of 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?

For a single-optional-parameter read tool with an output schema, the description is essentially complete: it covers the filter parameter, error behavior, and the semantics of the key returned fields. Explaining returned fields is arguably redundant given the output schema, which is the only minor excess.

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, but the description adds real value: it confirms the slug format ('base_mainnet'), the exact-match filter behavior, and that unknown slugs return an error listing valid ones. It complements the schema rather than merely restating it.

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 ('Fetch supported blockchain networks and static parameters from GET /v1/chains'), which is immediately distinguishable from siblings like list_docs or get_method_info. An agent knows exactly what this tool returns without opening the schema.

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

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

The description explains the `chain` narrowing behavior ('Pass chain to return only that chain') and what an unknown slug does, but it never contrasts this tool with alternatives or states when it should be preferred over siblings. Usage is implied by context rather than spelled out.

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 establish readOnlyHint=true and openWorldHint=false, and the description adds real value beyond them by disclosing that the index is static and requires no API key. However, it says nothing about pagination, result size, or whether the language filter changes the listing, so behavioral coverage beyond the annotation layer is thin.

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?

Everything is packed into one sentence, which is front-loaded with the useful scoping clause. The appended topic enumeration ('including webhook push subscriptions, signatures, delivery and billing') is unexplained and reads like content leaking in from a different tool, diluting an otherwise tight definition.

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 list tool with an output schema and a fully documented parameter, the description covers what it returns and the auth posture. It is nearly complete; the only omissions are result-size/pagination behavior and any pointer to search_docs as the alternative.

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%: the single 'lang' parameter is fully documented in the schema with its enum, case-insensitivity, English default, and error behavior for unavailable languages. The description adds nothing about parameters, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List all available documentation pages, relative paths, and titles from the static documentation index'), so the agent knows exactly what it returns. It does not distinguish itself from the sibling search_docs, and the trailing topic list ('webhook push subscriptions, signatures, delivery and billing') reads as scope noise that muddies rather than sharpens the purpose.

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

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

No explicit when-to-use or when-not-to-use guidance, and the obvious alternative (search_docs) is never mentioned. The only routing signal is the implicit list-vs-search distinction plus 'Available without an API key', which at least tells the agent this works pre-auth.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that the return value is raw Markdown, which is useful beyond the annotations, but says nothing about missing-page errors, size limits, or caching 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?

Two sentences, no filler, with the resource and route front-loaded followed by the path constraint. Every clause earns its place.

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

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

With no output schema, the description correctly states what is returned (raw Markdown), and the parameter contract is fully documented by the schema plus annotations. Minor gaps remain around error handling for unavailable languages or missing paths, which the schema only partially covers.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value by showing how lang and path compose into the URL template (/md/{lang}/{path}.md) and by providing an extra path example not in the schema. It reinforces rather than merely repeats the constraints.

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 ("Read") and resource ("raw Markdown content of a documentation page") and even exposes the underlying route (/md/{lang}/{path}.md). This clearly distinguishes it from siblings like list_docs and search_docs, which enumerate or query rather than fetch a specific page's raw content.

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

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

Usage is only implied: the agent can infer it should call this to fetch one known page's raw text, but no explicit when-to-use or when-not-to-use guidance is given, and no alternatives (search_docs, list_docs) are named. The path-format constraint is parameter guidance, not usage routing.

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

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

Even though annotations already declare readOnlyHint and openWorldHint, the description adds substantial context: auth via 'x-api-key' or 'Authorization: Bearer <key>' headers set in MCP client config (not tool params), the keyless endpoint's method-list restriction, the exclusion of write methods, and that raw JSON-RPC responses are returned.

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

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

Front-loaded with purpose and constraints, then auth and references. Some redundancy between the keyless-endpoint explanation and the schema's chain description, plus two external URLs, but every sentence carries actionable 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?

Covers auth model, endpoint selection, write-method exclusion, and error-avoidance routing, and an output schema already exists so return-value explanation isn't required. Nothing an agent needs to invoke this correctly 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 the schema already documents chain slug format, method naming, and optional params defaulting to []. The description reinforces slug format ('base_mainnet', take from list_chains) but adds no new parameter semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource+constraint: 'Execute a read-only JSON-RPC 2.0 method on a specified blockchain network'. It also explicitly distinguishes itself from sibling send_raw_transaction ('Write methods ... are not supported in rpc_call; use send_raw_transaction instead'), so an agent can route correctly 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?

Gives explicit when-to-use rules: with an API key for full access, without a key only the keyless `/v1/{chain}/public` endpoint and only that chain's `public.methods`. It names the alternative tool for writes and points to list_chains for valid slugs.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description doesn't contradict them; it adds value by naming the searched fields (titles, nav titles, paths, summaries), the returned shape, and that the tool is available without an API key. It stops short of describing pagination or ranking behavior, which is a minor gap for a search 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?

Four tight sentences, front-loaded with the use case and search scope, followed by sibling routing, parameter conventions, and failure handling. No filler or redundancy; each sentence changes what the agent would do.

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

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

An output schema exists so return values need not be explained, yet the description summarizes them anyway; combined with sibling routing, lang coordination, limit defaults, auth requirements, and empty-result recovery, an agent has everything needed to call this correctly on the first attempt.

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, but the description adds cross-tool parameter semantics the schema cannot convey: lang must match the lang used in read_doc, and 'omit lang for English' with limit bounds restated for the agent's convenience. It goes beyond restating the schema even though the enum values themselves come from 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?

States a specific verb+resource (find documentation by topic/task keywords) plus the precise condition that motivates it ('when the page path is unknown'), and enumerates the searched fields and returned fields. It is clearly distinguishable from sibling read_doc (known path) and list_docs (browse catalog).

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

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

Explicitly routes between siblings: use this when the path is unknown, use read_doc directly for a known path, use list_docs to browse the catalog, and read results back with read_doc using the same lang. It also gives a no-results fallback ('try broader keywords or browse list_docs'), leaving nothing 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 already declare destructiveHint=true and openWorldHint=true, so the mutation/open-world profile is covered. The description adds real value beyond that: the auth mechanism ('x-api-key' or Bearer header vs keyless public endpoint), the explicit prohibition on passing keys in parameters, and the broadcast/error return behavior. It stops short of describing irreversibility or mempool rejection 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?

Front-loads the core action in the first clause, then layers auth and return info. Three sentences with little waste, though the auth sentence is dense and slightly packed with parenthetical conditions.

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

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

Output schema exists, so return values need not be explained (the brief mention of tx hash/JSON-RPC error is a bonus). Annotations carry safety, and the description covers the non-obvious auth requirements. Minor gaps: nothing on chain-validity failure or transaction-rejection semantics.

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% – both 'chain' (slug, must exist in GET /v1/chains) and 'raw_tx' (0x-prefixed RLP hex with pattern) are fully documented in the schema. The description restates 'signed raw transaction' but adds no format or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource (broadcast a signed raw transaction) and names the underlying mechanism (eth_sendRawTransaction), which implicitly separates it from the generic rpc_call sibling. An agent can identify this tool without opening the schema.

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 establishes the action and the auth context, so the use case is implied (broadcasting pre-signed transactions). It never states when to prefer this over rpc_call, nor any exclusions or prerequisites beyond the header requirement, leaving alternative routing to inference.

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