Start Hermes eval suite job

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

Annotations only declare readOnlyHint=false, destructiveHint=false, leaving safety profile undisclosed. The description adds the async in-process behavior and the dry/live gate equivalence to hermes_eval_run, along with poll/cancel lifecycle. This is useful but doesn't disclose side effects, state changes, or what happens to the environment during the job, and no output format is described (though an output schema exists).

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?

Single sentence, front-loaded with the primary action, and efficiently references the sibling tool for gates instead of re-explaining them. Zero filler words. The cross-referencing to hermes_eval_run is a good compression technique.

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?

The tool is moderately complex (12 params, async job lifecycle). The description covers the key behavioral aspects: async, bounded, in-process, gates equivalent, and lifecycle via poll/cancel. It doesn't detail the output schema structure, but an output schema is present so the description needn't explain returns. The main gap is parameter semantics, but for an async launcher tool with a rich schema, the description is reasonably complete.

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% and there are 12 parameters, so the description carries the burden. The description adds nothing about any parameter's meaning (home, model, backend, profile, workers, base_url, live_eval, hermes_bin, judge_model, toolkit_root, timeout_seconds). While parameter names are somewhat self-explanatory, the description doesn't explain distinctions like live_eval vs dry, or how backend/workers interact. The output schema exists but parameters remain under-documented.

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?

Specific verb+resource ('Start one bounded Hermes eval suite as an in-process async job') with clear scoping ('bounded', 'in-process'). Distinguishes from siblings by naming hermes_job_status and hermes_job_cancel for polling/cancellation. The async nature is clearly stated, differentiating it from the synchronous hermes_eval_run sibling.

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?

States it's an async job variant with the 'same dry/live gates as hermes_eval_run', which pairs it against a known sibling. Explicitly names the two companion tools for follow-up (hermes_job_status, hermes_job_cancel). However, it doesn't give explicit when-to-use vs when-not-to-use guidance versus the synchronous hermes_eval_run (e.g., large/long-running suites vs quick ones).

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