Check Base network health: retrieve chain ID, latest block, gas price, and native token USD price in a single call. Pay per call via USDC without an API key.
base network health: chain id, latest block, gas price and native token USD price. Pay-per-call ($0.002 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional comma-separated subset of fields to return |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add value by disclosing the pay-per-call cost ($0.002 USDC), which is a meaningful operational trait. However, it does not disclose failure behavior, data freshness, or how the optional fields parameter affects output, so transparency is partial.
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 with zero waste: the core purpose and returned fields are front-loaded, and the cost disclosure follows. Every word 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?
Adequate for a simple one-optional-parameter read-only tool: the description covers what data is returned and the cost, with no output schema or annotations present. Gaps include exact field name syntax for the 'fields' parameter (only implied) and output format, but these are minor for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3, but the description adds value by enumerating the data fields (chain id, latest block, gas price, token USD price), which effectively documents the valid values for the optional 'fields' parameter beyond the schema's generic 'comma-separated subset of fields' wording.
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 resource ('base network health') and enumerates exactly what it returns: chain id, latest block, gas price, and native token USD price. This clearly differentiates it from siblings like base_block, base_gas, and base_balance, which each cover a narrower slice of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or explain when an agent should choose this consolidated health snapshot over siblings like base_gas (gas price) or base_block (block data). Usage must be entirely inferred from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.