comfyui_history

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds value beyond that by disclosing ordering behavior ('newest first') and scope (it includes web-UI-run jobs, not just API runs). It does not cover secondary behaviors like whether failed jobs are included or how far back history extends, but with the annotation burden already handled, the added context is meaningful.

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?

Two sentences, zero filler. The purpose with ordering and scope is front-loaded in the first sentence, and the second sentence earns its place by connecting the tool to a concrete downstream action (comfyui_save_workflow). Nothing extraneous.

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?

This is a low-complexity tool — one optional parameter, an output schema present (so return values need no explanation), and annotations covering read-only behavior. The description covers what is listed, the ordering, the inclusion scope, and a key downstream use. The only notable gap is ambiguity over whether 'finished' includes failed/canceled runs, but for a simple list tool this is minor.

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 makes no mention of the single `limit` parameter, so it fails to compensate for the gap the rubric requires at low coverage. The parameter is salvageable only because the name 'limit' with default 10 is self-evident and the list context makes its role apparent, but the description itself adds no semantics to the schema.

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 a clear purpose: listing recent finished jobs, newest first, with an explicit scope qualifier ('including ones run from the ComfyUI web UI'). The verb is implied rather than explicit ('Recent finished jobs' instead of 'List recent finished jobs'), and while the coverage qualifier helps set it apart from API-only histories, it never explicitly names a sibling it is not — differentiation from comfyui_job_status and comfyui_status is left to inference.

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 gives clear, actionable context: this tool is the source of prompt_ids for turning past runs into workflows via comfyui_save_workflow, which tells an agent exactly when and how to chain the tool. However, it provides no exclusions or explicit comparison against sibling tools like comfyui_job_status (single-job status) or comfyui_status (server status), so it stops short of full when/when-not guidance.

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