Check Hermes Toolkit job status

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety/profile via structured data. The description adds the process-local scope constraint and the fact it returns artifact/result status, useful context. However, it does not disclose polling semantics (timeout behavior, whether it blocks, polling rate) or what happens if the job_id is unknown.

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?

A single efficient sentence that states verb, resource, scope, and return value with zero filler words. It is appropriately front-loaded with the action and resource.

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 has a rich output schema and four parameters, including three optional configuration params (home, profile, toolkit_root) that are wholly unexplained. With an output schema present, return-value documentation is less critical, but the polling semantics, process-local scope detail, and optional parameter purpose are gaps. For a tool of this complexity, the description is adequate but not 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%, so the description carries the full burden for the 4 parameters. The description names job_id/run_id, which maps to the required parameter and confirms it's the ID to poll. However, the three optional parameters (home, profile, toolkit_root) receive no explanation of what they configure or when they're needed. With 0% coverage and only one of four params implicit, this is partial but not complete.

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 uses a specific verb ('Poll') with a clear resource ('process-local Hermes Toolkit MCP async eval job') and states what it returns ('current artifact/result status'). It distinguishes from siblings reasonably — hermes_api_jobs_get is a generic REST API job getter, while this one is process-local async eval status. However, it doesn't explicitly differentiate from hermes_api_runs_get or the kanban run getters, and the 'process-local' qualifier may be ambiguous.

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 implies polling/status-checking context ('Poll... and return current status'), which gives the agent a sense of when to use it (after an async job is launched). But it does not state when NOT to use it or name alternative tools, such as hermes_api_jobs_get for REST jobs or hermes_api_runs_get for runs. No prerequisites are mentioned (e.g., that the job must be process-local).

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