comfy_get_artifact

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

The description greatly expands on the annotations by revealing path-resolution restrictions: absolute paths, '..' traversal, and symlink escapes are rejected. It also discloses that inline bytes are opt-in and capped at 25 MiB, giving the agent valuable safety- and limit-related behavior beyond the readOnlyHint/idempotent annotations.

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 short, front-loaded, and every sentence carries useful information. It avoids fluff and jargon while communicating key behavioral constraints in a compact format.

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?

The tool has four parameters and no schema parameter descriptions, but the description only fully covers relative_path behavior and vaguely mentions inline bytes. It provides good security context and core purpose, but an agent would still need inference about include_data, include_sha256, and max_inline_bytes handling. The existence of an output schema helps but does not compensate for incomplete parameter semantics.

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 explain the parameters. It meaningfully explains relative_path resolution and mentions the inline bytes cap, but it does not connect include_data to base64 bytes, explain include_sha256, or clarify how max_inline_bytes relates to the stated cap. Optional parameters are left underspecified.

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 uses a specific action ('Get') and explicit resource ('metadata ... for one output file'), clearly stating the tool's purpose. It also distinguishes itself from list/download siblings by scoping to a single file and emphasizing metadata/bytes retrieval.

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 implies when to use it (one output file, metadata, optional bytes) but does not provide explicit when-not-to-use guidance or name alternative tools such as comfy_list_artifacts, comfy_get_output_image, or comfy_download_batch. Usage context is clear enough, but alternative selection guidance is absent.

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