runcomfy-mcp

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

Annotations already indicate non-read-only (readOnlyHint=false) and potential side effects (openWorldHint=true). Description adds the example of freeing GPU memory, which implies destructive action, but does not fully disclose all behavioral traits beyond 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?

Concise three sentences, front-loaded with purpose. The technical POST path detail is slightly unnecessary but not harmful. No wasted words.

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 no output schema and moderate annotations, the description covers purpose, prerequisite, and a common use case. Lacks response/error details, but acceptable for a proxy tool whose response depends on the backend.

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?

With 0% schema description coverage, the description adds significant meaning: explains instance_id source, comfy_backend_path as endpoint path, and request_body with a concrete example. Deployment_id is not elaborated, but coverage is high for the most contextual params.

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?

Clearly states the tool calls a ComfyUI backend endpoint on a live instance, with a specific verb ('call') and resource ('backend endpoint'). Distinguishes from siblings by focusing on proxying to instance endpoints, not general request submission or status checking.

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?

Provides a prerequisite (getting instance_id from get_request_status after in_progress status) and a common use case (freeing GPU memory via 'api/free'). However, lacks explicit when-not-to-use guidance or alternatives.

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

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

Adds context beyond annotations by specifying the backing POST endpoint and return values. Consistent with destructiveHint and idempotentHint. No contradiction.

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, front-loaded with the core purpose. The second sentence about backing URL is somewhat redundant but not wasteful. Efficient overall.

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 low complexity (2 required params, no enums, no output schema), the description covers key aspects: what it does, when it's applicable, and return values. Missing error handling or irreversible effects note, but still adequate.

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 0%, and description does not elaborate on parameters. The names 'deployment_id' and 'request_id' are somewhat self-explanatory, but the description misses an opportunity to clarify their roles or format.

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?

Description clearly states 'Cancel a queued or running request', specifying both verb and resource. Distinguishes from siblings like submit_request and get_request_status.

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?

Mentions cancellable states ('queued or running') and expected returns ('cancelled' or 'not_cancellable'), providing guidance on when to use. Could be more explicit about when not to use, but effectively covers the main conditional.

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

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

Annotations already indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true). The description adds parameter constraints but does not disclose idempotency, rate limits, or existence checks.

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 well-structured with a clear first line and a docstring. While it is lengthy due to parameter details, every sentence adds value. Could be slightly more concise but not excessive.

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 creation tool with 8 parameters and no output schema, the description adequately covers all parameters and usage context. Lacks return value description, but schema has no output schema. Overall sufficient for correct invocation.

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 description provides detailed explanations for all 8 parameters, including valid values (e.g., hardware options) and numeric ranges (e.g., min_instances 0..30). This fully compensates for the 0% schema description coverage.

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 'Create a Serverless API (ComfyUI) deployment' and specifies the backing endpoint. It distinguishes itself from sibling tools like delete_deployment and update_deployment by describing a creation action.

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 explicit guidance by noting 'For LoRA deployments, create via the runcomfy.com UI instead,' which tells when not to use this tool. However, it does not compare with other tools like update_deployment.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. The description adds context like 'cannot be undone' and the underlying API endpoint, reinforcing behavior without contradiction.

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 two sentences, front-loading the core action and then providing the alternative. Every sentence is essential and there is no redundancy.

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 simple delete tool with good annotations and a single parameter, the description is complete. It includes the irreversible nature and a viable alternative, covering key decision points.

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 0%, so the description should clarify parameters. However, there is only one parameter (deployment_id) which is self-explanatory from its name and the required status. The description adds no extra meaning, meeting the minimum bar.

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 'Permanently delete a deployment,' identifying the verb and resource. It distinguishes itself from sibling tools by suggesting an alternative (update_deployment to pause), making the purpose unambiguous.

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 explicit guidance on when to use this tool versus alternatives: 'Consider update_deployment(is_enabled=false) to pause instead.' This helps the agent choose correctly.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat those. It adds behavioral context about the include_payload parameter's purpose, which is helpful but not extensive. No contradictions with 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 concise with three sentences, no waste. It front-loads the purpose, then provides the REST endpoint, and finally usage guidance for a key parameter. Every sentence serves a purpose.

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 description lacks details about the return value structure (no output schema), but for a simple get tool, it might suffice. It hints at payload contents but doesn't list other fields. Given the annotations and sibling tools, it feels incomplete for a full understanding.

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?

Despite 0% schema description coverage, the description explains the include_payload parameter in detail, linking it to workflow graph inspection and override building. deployment_id is self-explanatory. However, include_readme is not explained, so the description could be more complete.

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 'Get one deployment by ID,' which is a specific verb and resource. It distinguishes itself from siblings like list_deployments (which fetches multiple deployments) and create/update/delete operations.

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 clear context for when to use the include_payload parameter (inspecting the workflow graph to build overrides for submit_request), which implies a specific use case. However, it does not explicitly mention when to use this tool versus alternatives like list_deployments or when not to use it.

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

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

Annotations indicate readOnlyHint, idempotentHint, openWorldHint. The description adds key behavioral context: the tool only works on completed requests and output URLs are hosted for 7 days. No contradictions.

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?

Two succinct sentences, no unnecessary words, and the most critical information (fetching outputs, URL lifetime) is front-loaded.

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 description covers the core purpose, the prerequisite of completion, and the URL hosting duration. Given no output schema, omitting output structure is a minor gap but overall sufficient for an agent to select and invoke 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?

The schema has 0% description coverage for parameters. The description does not elaborate on what deployment_id and request_id represent, how to obtain them, or their expected format. This leaves the agent with no guidance beyond the names.

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 verb ('Fetch') and resource ('completed request's outputs'), clearly distinguishing from sibling tools like get_request_status which fetch status. The endpoint reference and URL hosting detail add precision.

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 usage when the request is completed by specifying 'completed request's outputs.' However, it does not explicitly state to avoid using for non-completed requests or compare with alternatives like get_request_status, leaving some ambiguity.

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

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

Describes lifecycle states and API route, adding value beyond annotations which already declare readOnly, openWorld, idempotent.

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 concise sentences with key info front-loaded.

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?

Lifecycle is provided, but without output schema, return format is missing. Adequate for a simple poll.

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?

No parameter descriptions in schema or description. Schema coverage 0%, so agent gets no guidance on deployment_id or request_id format.

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?

Clearly states it polls a request's current status. Distinct from sibling tools like cancel_request and get_request_result.

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?

Implies polling usage but doesn't specify when to use vs alternatives or when to stop polling.

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

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

Annotations already declare readOnlyHint=true, which is consistent with the 'list' action. The description adds behavioral details: optional parameters affect response size (include_payload) and content (include_readme). It also notes the API endpoint. This adds value beyond annotations, but no contradictions.

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 concise: two sentences for core purpose and API, then parameter list. Every sentence adds value with no fluff. Front-loaded with action phrase.

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 3 parameters and no output schema. Description covers parameters and purpose but does not describe the return structure or potential pagination. Given the annotations (openWorldHint) and simplicity, it is mostly complete but could mention the return format.

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 0%, so description bears full responsibility for parameter meaning. Each parameter is clearly explained: ids as optional filter, include_payload as inclusion of extra data with larger response, and include_readme for README inclusion. This fully compensates for missing schema descriptions.

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 states 'List Serverless API deployments in the caller's account,' clearly indicating the verb (list) and resource (deployments). While it does not explicitly differentiate from sibling tools like 'get_deployment' (which fetches a single deployment), the naming and action imply a list operation, providing sufficient clarity.

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 usage for listing deployments but does not provide explicit guidance on when to use this tool versus alternatives like 'get_deployment' or 'create_deployment'. No when-not or alternatives are mentioned. Score 3 due to implied usage only.

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

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

Annotations indicate write (readOnlyHint=false) and open world (openWorldHint=true). The description adds value by explaining async submission, wait_for_completion, webhooks, and file input methods. It does not cover rate limits or auth, but given openWorldHint, this is acceptable.

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 well-structured with an intro line, bullet list of parameters, and a separate file input note. While slightly verbose, it front-loads the purpose and uses clear formatting. Every sentence contributes useful 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?

For an 8-parameter tool with no output schema, the description covers all parameters and explains async/sync and webhook behavior. It lacks explicit mention of return values for async submissions (e.g., request ID), but overall it is sufficiently complete for an inference submission tool.

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 compensate. It fully explains each parameter, including overrides structure, workflow_api_json mode, extra_data for API keys, webhook options, and file inputs with examples. This adds significant meaning beyond the bare schema.

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 verb 'Submit' and the resource 'async inference request to a deployment'. It distinguishes from siblings like get_request_result and get_request_status by focusing on submission.

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 usage context, including parameter explanations and two operational modes (overrides vs workflow_api_json, polling vs webhook). However, it does not explicitly differentiate when to use this tool over siblings like call_instance_proxy.

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

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

Annotations indicate readOnlyHint=false, consistent with a write operation. The description adds that it is a partial update (PATCH) and explains the effect of is_enabled. However, it lacks details on authentication, error behavior, or idempotency.

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 concise (3 sentences), front-loads the main action, and provides actionable guidance without unnecessary words.

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 9 parameters, no output schema, and minimal annotations, the description lacks prerequisites, error scenarios, and return value description. It addresses only partial update and is_enabled toggle, leaving many aspects unspecified.

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?

With 0% schema description coverage, the description only explains is_enabled and implicitly deployment_id. The other 7 parameters have no added meaning, merely stating they can be omitted or changed. The description does not compensate for the missing schema descriptions.

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 'Partially update a deployment' and details that it backs a PATCH endpoint. It distinguishes from siblings like create_deployment and delete_deployment by specifying partial update behavior.

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 advises to 'only pass the fields you want to change' and provides specific examples for pausing and re-enabling via is_enabled. While it doesn't list alternatives, the context of sibling tools implies when to use other tools.

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