import_workflow

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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, which is a thin behavioral profile for a tool that mutates session state. The description compensates by disclosing the mutual-exclusion constraint and the cost tradeoff (name preferred for large files, no pasting), plus the accepted JSON shapes. It stops short of stating what happens on import failure or whether the session is replaced, so it is strong but not exhaustive.

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 opening sentence states the action; the middle is a scannable bullet list of mutually exclusive options; the closing sentence states intended uses. No filler, and the critical exactly-one constraint is front-loaded before the options.

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?

An output schema exists, so return values need no explanation, and the description covers the source-selection logic and accepted formats well. What is missing is failure behavior: what happens if none or more than one source is provided, or if the JSON is malformed. Given four optional parameters with no required fields, that enforcement detail is the one thing an agent most needs, so the definition is complete but not airtight.

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 carries the full burden, and it does: each of the four parameters' roles is explained, including two accepted JSON formats for workflow_json (UI nodes/links vs API {id: {class_type, inputs}}) and the source of name (ComfyUI's workflow browser, cross-referenced to list_workflows). Only the 'title' parameter is left unexplained, which is a minor gap against an otherwise complete mapping.

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?

States a specific verb and resource ('Import an existing workflow into the session') and immediately distinguishes the action from siblings like create_workflow or find_workflow by scoping it to loading existing work. It even names downstream uses (beautifying/diagnosing/porting), which helps the agent place it against inspect_workflow, diagnose_workflow, and port_workflow.

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?

Explicitly enforces the exactly-one-source rule with 'Provide exactly ONE source' and enumerates the three mutually exclusive options, including which is preferred for large files. This is far more than implied guidance and directly prevents a class of invocation errors.

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