protocol_health_score

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

No annotations are provided, so the description carries the full burden. It does add real value by enumerating the returned components and score history in the absence of an output schema, but it omits whether the read requires auth, how fresh the score is, or what happens for an unknown slug.

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 text is duplicated verbatim (the sentence appears twice, separated only by a dash), which is pure waste and suggests a generation artifact. Aside from that redundancy the single sentence is reasonably front-loaded.

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 and no annotations, the description is the only source of behavioral context; it partly compensates by listing the returned components, but it says nothing about error cases, freshness, or how it relates to the scoreboard/refresh siblings, leaving meaningful gaps for a two-parameter oracle 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 description coverage is 100% and both parameters are fully documented in the schema (slug as defillama_slug, history with default 10 / max 100). The description adds no parameter-level detail beyond that, 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 resource ('latest health score for one protocol') and enumerates what the score comprises (GitHub activity, TVL trend, treasury, source details, history). It does not, however, distinguish itself from close siblings like protocol_health_scoreboard or protocol_health_list_protocols, so an agent must infer which one returns a single protocol's score.

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?

There is no explicit when-to-use guidance, no mention of alternatives, and no stated preconditions (e.g., that the protocol must first be tracked via protocol_health_track_protocol). The description only says what is returned, leaving selection between the four protocol_health_* siblings to guesswork.

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