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

With no annotations, the description carries the burden and does well: it discloses freshness ('measured this minute from our server'), the metrics returned per endpoint, and that the tool is free of charge. It stops short of saying how many endpoints are probed or whether results are cached, but the read-only, no-side-effect nature is implicit in the measurement framing.

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 tight sentences with the outcome first and the routing rationale second; the quoted error string is the only 'extra' and it earns its place by letting an agent pattern-match the exact symptom. Nothing is padded.

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?

There is no output schema, so the description usefully sketches what comes back (latest block, lag, response time per RPC) and how current it is. For a zero-parameter diagnostic call that is largely sufficient, though it never states the response shape or whether one endpoint or many are returned.

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 is an empty object, so there are no parameters whose meaning needs elaborating; the baseline for a zero-parameter tool applies. Nothing in the description conflicts with or needs to supplement 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?

It names a specific resource (Arc RPC endpoints) and states exactly what it reports: latest block, per-endpoint lag, and response time. The framing 'which Arc RPC is answering right now' immediately separates it from every sibling, none of which deal with RPC health.

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 a concrete trigger for use: when the official RPC returns 'Request exceeds defined limit', call this to pick another endpoint. That is a clear when-to-use condition tied to a real symptom. It doesn't state any when-not conditions or a follow-up step such as retrying the chosen endpoint, which keeps it from a 5.

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