Run Hermes eval suite

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

With no annotations carrying behavioral safety info (readOnlyHint=false, destructiveHint=false), the description carries the burden and does disclose meaningful behavior: it is synchronous, writes artifacts (request/result/summary/stdout/stderr/report), requires specific environment/policy gates for live eval. It doesn't mention whether it leaves persistent state or what happens to prior artifacts, but it covers the key behavioral surface.

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?

Three sentences, zero padding. The most important operational constraints (synchronous, artifact-producing, live-eval gating) are front-loaded. Every sentence 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?

There is an output schema present, which relieves the description of return-value documentation. However, given 12 parameters with 0% schema coverage and no annotation support, the description leaves significant gaps: it doesn't explain which parameters matter for which use cases, what 'bounded' means for time/resource limits, or how backend options differ. For a complex eval-run tool, this is adequate but not thorough.

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 0%, so the description must compensate for 12 parameters. The description references live_eval and the harness but doesn't explain semantics for parameters like backend, workers, judge_model, profile, home, or timeout_seconds. It adds minimal parameter-level value beyond identifying that live_eval gates behavior.

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 clearly states it runs a bounded Hermes eval suite synchronously through the configured harness. It distinguishes itself from related siblings like hermes_eval_start (non-synchronous start) and hermes_skill_eval_start. However, it doesn't explicitly contrast with the sibling eval tools, and 'bounded' is a term that isn't further clarified.

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 provides clear prerequisites for live evals (live_eval=true, HERMES_TOOLKIT_MCP_ALLOW_LIVE_EVAL=1, and the policy gates), and notes that dry/structural suites don't require live-model opt-in. This gives agents practical when-to-use guidance, though it doesn't explicitly name alternative tools for the non-live case or exclude when not to use it.

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