Smoke-test Hermes API server

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

Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true, but no safety hints about network side effects or auth requirements. The description adds useful behavioral disclosure (it 'writes redacted artifacts' and separates multiple concern dimensions), but doesn't disclose whether this makes external network calls, whether it requires credentials/keys, whether it's expensive or slow, or what 'gated' means operationally. For a test tool that may invoke models, more behavioral context would help.

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 is a single dense sentence that front-loads the core purpose (smoke-test). It's not verbose, but the sentence packs several ideas ('separates endpoint reachability, auth acceptance, model invocation, and assistant answer evidence, writing redacted artifacts') which could be clearer as structured phases. It earns its place but could benefit from slight restructuring.

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 6 params at 0% schema coverage and an output schema present, the description does not explain parameter semantics at all, which is the biggest completeness gap. It also doesn't describe failure modes, exit codes, artifact locations, or how the 'gated' behavior manifests. Given the tool's apparent complexity (multi-phase checks, artifact writing) and zero parameter documentation, the description is incomplete.

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 the description names zero parameters. The six parameters (home, model, prompt, profile, toolkit_root, timeout_seconds) have no explanation in the description about their purpose or interaction. The agent must infer from bare schema titles like 'Home', 'Toolkit Root', and 'Profile' what values to provide. With 0% schema coverage and zero parameter mention in the description, this is a significant gap that forces the agent to guess.

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 it's a 'smoke test' of the Hermes API that 'separates endpoint reachability, auth acceptance, model invocation, and assistant answer evidence, writing redacted artifacts.' This gives a reasonably specific verb (smoke-test) and resource (Hermes API) with the distinct sub-checks enumerated. However, it doesn't clearly distinguish itself from sibling tools like hermes_api_health or hermes_api_health_detailed, which could be confused as overlapping health check tools.

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 term 'gated' implies there's some access restriction to using this tool, and 'smoke' implies running a startup verification, giving some implied usage context. But there's no explicit when-to-use, when-not-to-use, or mention of alternatives. It doesn't clarify whether this is for post-deployment verification versus continuous monitoring, nor does it distinguish the smoke test from health checks performed by sibling tools.

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