rpc / get_health

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating the three returned values (chain ID, block, hash), which matters because there is no output schema. However, it says nothing about network dependency, rate limits, or what happens if the RPC is unreachable, which is relevant for an openWorld health check.

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 tight sentence that front-loads the verb and lists the resources. It borders on being under-specified rather than verbose, and the phrase 'configured Base RPC chain ID, latest block and hash' is slightly ambiguous in how the three items parse.

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?

Listing the returned values compensates somewhat for the absent output schema. However, with a required, entirely undocumented chain_id parameter and no stated failure behavior, the definition is only minimally sufficient for calling 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?

There is one required parameter, chain_id, with 0% schema description coverage, so the schema provides no meaning at all. The description never mentions chain_id or its format, and 'the configured Base RPC chain ID' could even suggest no argument is needed. The description fails to compensate for the coverage gap.

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

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

The description uses a specific verb (Read) and names the exact values returned: chain ID, latest block, and hash. That makes the tool's purpose distinct from most siblings, though it doesn't explicitly name a competing tool like observations.status or history.status, so the differentiation is implicit.

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

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

No guidance on when to call this versus alternatives such as observations.status, history.status, or capabilities.list. There are no exclusions or prerequisites stated. An agent is left to infer that this is a connectivity/health probe from the tool name alone.

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