apps

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It does so extensively: read-only actions are marked, run returns prompt_id and patches values, unknown keys fail loudly, omitted inputs use defaults, import does not install deps and re-importing conflicts, and registry_url has SSRF concerns. This is model-level transparency.

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 long but well-structured with a clear introduction and action-by-action bullets. Each sentence provides unique value: no redundancy, and every behavioral nuance (read-only flags, defaults, conflict warnings) earns its place. The format makes it easy for an agent to scan and extract needed information.

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?

Given the tool's high complexity (5 actions, 7 params, nested objects) and the absence of an output schema, the description is remarkably complete. It specifies return values for each action (manifests, prompt_id, status/outputs), covers edge cases (deps not installed, SSRF, unknown keys), and leaves no major gaps. The agent has everything needed to invoke the tool correctly.

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 coverage is 100%, but the description adds substantial meaning beyond the schema. It explains that values are keyed by '<nodeId>.<widget>' with an example, that app_id has different requirements per action, and that registry_url must be allowlisted to avoid SSRF. This enriches the schema and provides operational context.

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 opens with a specific definition: 'Micro-apps on this ComfyUI (panel Apps feature): named workflows packaged for one-click runs.' This clearly distinguishes it from sibling workflow tools like enqueue_workflow or save_workflow. The five actions are each described with specific verbs and resources, fully specifying the tool's purpose.

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 provides detailed guidance for each action, including which parameters are required and the behaviors of list/get/run/run_status/import. It does not explicitly say 'when not to use' or compare to sibling tools, but the action-based structure gives clear context for when to invoke each operation. It also warns about import conflicts and missing deps, which informs user decisions.

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