Ask Hermes fallback (last resort)

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes beyond these by disclosing that it 'writes private artifacts,' 'supports async jobs,' and 'may trigger live/model/tool side effects' (via risk_acknowledgement description). It is openWorld (outbound model calls), which aligns with openWorldHint. This adds meaningful behavioral context beyond annotations, though async/artifact behavior is partially implied by the schema structure.

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, dense sentence packs the purpose, gatekeeping requirements, artifact behavior, async support, and fallback warning into minimal prose. No wasted words. The front-loading ('Last-resort prompt bridge...') immediately orients the agent to the tool's exceptional nature.

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?

For a complex tool with 14 params, asynchronous operations (run/start/status/cancel), conditional required fields via allOf, gatekeeping fields, and behavioral side effects, the description covers the essentials reasonably well. An output schema exists. Gaps remain: it doesn't clearly enumerate the four distinct operations and their select semantics, but the schema's discriminator plus 86% param coverage partially covers this. Given the tool's complexity, slightly more operational guidance would help.

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 86%, so most params are already documented. The description adds value by naming the required gatekeeping params (why_no_typed_tool_fits, docs_resource_consulted, typed_wrapper_checked, risk_acknowledgement, expected_evidence), clarifying their collective purpose as a safeguard checklist. It also clarifies that writes private artifacts and warns when a typed tool would be better, which influences how params like risk_acknowledgement should be filled.

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 this is a 'last-resort prompt bridge' to a Hermes Agent backend used 'after typed tools do not fit.' It names the verb+resource (prompt bridge to configured backend) and conveys its role as an escape hatch. However, it doesn't explicitly distinguish itself from the ~70 sibling typed tools by name, relying on the 'last-resort' framing and 'why_no_typed_tool_fits' requirement to imply differentiation.

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 says it's used 'after typed tools do not fit' and 'warns when a typed tool would be better,' which provides clear context and exclusion guidance. It requires the caller to justify why no typed tool fits (via required params). However, it doesn't name specific alternative tools or give richer when-not-to-use scenarios beyond the generic 'prefer typed tools' framing.

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