blockrun_rpc

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.