start_comfyui

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

With no annotations, the description carries full burden and discloses key behaviors: using saved process info, supporting two installation types, and polling the API for bounded readiness before reporting ready. It does not mention potential timeout or resource usage but is transparent about the startup process.

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?

Three sentences, each adding distinct value: purpose+constraint, compatibility, and behavior. No redundancy, front-loaded with core action.

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 parameterless start tool, the description fully covers what the tool does, its prerequisite, supported environments, and readiness checking. No output schema needed as action is complete upon reporting ready.

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?

The input schema has zero parameters, so schema description coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter info as none exist, but it clarifies the tool's behavior sufficiently.

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 the action 'start ComfyUI', the resource 'ComfyUI process', and the unique behavior of using saved process info from stop_comfyui and polling for readiness. It distinguishes from sibling tools like install_comfyui and restart_comfyui.

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 explicitly states the prerequisite 'using process info saved from a previous stop_comfyui call' and compatibility with Desktop app and manual Python installs. It does not mention when not to use or provide alternatives like restart_comfyui, but the context is clear.

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