run_template

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that some templates contain partner-API paid nodes that spend the account's Comfy credits, that a paid template fails CLOSED with spend_consent_required and spends nothing without consent, that wait=False submits --async and returns a prompt_id, and that a missing model surfaces as a per-node error. No contradiction with annotations (none supplied).

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?

Front-loaded with a one-line purpose, then cleanly organized into Args and Gotchas sections, with nearly every sentence carrying non-obvious information. It is slightly redundant — the fail-closed consent point appears both in confirm_spend and in the first Gotcha — but the length is proportionate to the tool's risk profile (credit spend, async execution, slot addressing).

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 high-complexity tool with zero annotations and no output schema, the description covers the execution pipeline, consent gating, sync vs async return contracts, timeout behavior, and failure modes. The one real gap: it says wait=False returns 'a prompt_id to poll' but never names the sibling that would consume it (e.g., job or fetch_outputs), which would fully close the loop for an agent.

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 must carry the meaning for all five parameters, and it does: name via the CLI form, params with concrete slot-addressing syntax ("6.text", "prompt", "A/B.name" for subgraph interiors), confirm_spend with a strict consent rule and fail-closed behavior, wait with sync-vs-async return contracts, and timeout_seconds with its default and wall-clock meaning. This goes far beyond the bare schema titles and defaults.

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 opening line states a specific verb and resource — 'Run a gallery template' — and spells out the internal pipeline (fetch, fill params, execute). It further distinguishes itself from siblings by naming itself as the one-command alternative to the search_templates -> fetch_template -> run_workflow chain, so an agent can differentiate it without opening other schemas.

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?

Names the alternative multi-step pipeline explicitly and gives strong conditional guidance: wait=False is 'preferred for long (video) runs', and confirm_spend is only to be set when the user has actually agreed, never to clear an error. However, it never states an explicit when-not case, such as 'use fetch_template when you need to inspect or modify slots before running', so the exclusion is implied rather than stated.

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