Conduct rating of an AI agent or framework (free, check before delegating)

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

With no annotations, the description carries the full burden and does well: it discloses that ratings are measured rather than declared, that the agent was run by its owner in a fixed x402 arena, that it is free, and how to interpret the NEW and REFERENCE flags and 404 responses. It omits rate limits or auth requirements, but as a public read lookup that is a minor gap.

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?

It is one dense paragraph, but it is front-loaded with the verb and resource, then the returned fields, then the practical rules and the testing link. The long enumeration of output fields earns its place given no output schema, though the text is somewhat run-on.

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, the description usefully enumerates return values (tier scale, score range, runs, flags, per-scenario pass counts, honest-task rate) and edge cases (404, NEW, REFERENCE). The main missing element is disambiguation from the sibling trust_check and skill_check rating tools.

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 the single slug parameter is already documented with format and an example in the schema. The description repeats the lowercase-with-dashes convention and example (hermes-agent), adding no new semantics. Baseline 3 is appropriate.

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 verb and resource — reading the Agent Economy Report conduct rating of an agent/framework by slug — and enumerates the returned fields (tier, score, runs, flags, per-scenario pass counts). It does not, however, distinguish itself from the sibling tools trust_check and skill_check, so an agent cannot tell from the text alone which rating tool applies.

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?

It gives clear operational guidance: it is free, check before delegating, and 404 means never tested so treat as unknown. It also instructs how to interpret the REFERENCE flag (never rank it). It stops short of naming when to prefer this over the sibling trust_check/skill_check tools.

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