runcomfy-mcp
Server Details
Remote MCP server for RunComfy Serverless API (ComfyUI): deployments and async inference.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 10 of 10 tools scored. Lowest: 3.1/5.
All 10 tools serve clearly distinct purposes: deployment CRUD, request lifecycle management (submit, cancel, status, result), and instance proxy. No overlap or ambiguity.
Every tool follows a consistent verb_noun snake_case pattern (e.g., create_deployment, get_request_status). The verbs are imperative and the nouns clearly indicate the resource.
With 10 tools, the server is well-scoped for managing ComfyUI deployments and requests. It covers essential operations without being excessive or sparse.
The tool surface covers full CRUD for deployments, complete request lifecycle (submit, cancel, status, result), and additional proxy functionality. No obvious gaps for the intended domain.
Available Tools
10 toolscall_instance_proxyAInspect
Call a ComfyUI backend endpoint on a live instance.
Backs ``POST /prod/v2/deployments/{deployment_id}/instances/{instance_id}/proxy/{path}``.
Get the instance_id from ``get_request_status`` once the status is
``in_progress``. Common target: ``api/free`` with
``{"unload_models": true}`` to free GPU memory.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes | ||
| request_body | No | ||
| deployment_id | Yes | ||
| comfy_backend_path | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (writes) and openWorldHint=true (side effects). Description adds context that it backs a POST endpoint and can free GPU memory, which implies destructive potential. Adds value 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?
Three sentences: purpose, API reference, usage example. Front-loaded and no filler. Every sentence provides value.
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?
Provides enough for common use case (freeing memory), but missing details on error handling, return value, or other possible endpoints. Acceptable for a proxy tool but could be more complete.
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%, but description partially explains instance_id (where to get it) and gives example for comfy_backend_path and request_body. Does not describe deployment_id. Adds some meaning beyond schema but not full compensation.
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 'Call a ComfyUI backend endpoint on a live instance', specifying verb and resource. Distinguishes from sibling tools which manage deployments/requests, not proxy into instances.
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 explains when to use: get instance_id from get_request_status when status is in_progress. Provides a common target (api/free) with example request body. Lacks explicit alternatives or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_requestADestructiveIdempotentInspect
Cancel a queued or running request.
Backs ``POST /prod/v1/deployments/{deployment_id}/requests/{request_id}/cancel``.
Returns ``cancelled`` if accepted, ``not_cancellable`` if already done.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| deployment_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return values ('cancelled' or 'not_cancellable') and the condition for failure (already done), adding context beyond annotations that already indicate destructive and idempotent behavior.
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 extremely concise—two short sentences plus a code reference—with no unnecessary words or repetition.
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 tool's action, scope, and return values adequately for a simple cancel operation, though it lacks mention of any side effects or prerequisites.
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 does not explain the two required parameters (`deployment_id`, `request_id`), leaving them purely defined by the schema; with 0% schema description coverage, this is a gap.
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 'Cancel' and the resource 'request', specifying it applies to queued or running requests, which distinguishes it from sibling tools like `submit_request` or `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?
The description indicates the tool is for 'queued or running' requests, providing a condition for use, but does not explicitly exclude already completed requests or mention alternative tools like `get_request_status` for checking state first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_deploymentAInspect
Create a Serverless API (ComfyUI) deployment.
Backs ``POST /prod/v2/deployments``. For LoRA deployments, create
via the runcomfy.com UI instead.
Args:
name: Human-readable name.
workflow_id: UUID of the ComfyUI workflow.
workflow_version: Version label, e.g. "v1".
hardware: One of TURING_16, AMPERE_24, AMPERE_48, ADA_48_PLUS,
AMPERE_80, ADA_80_PLUS, HOPPER_141.
min_instances: 0..30. Warm instance floor (billable if > 0).
max_instances: 1..60. Concurrency ceiling.
queue_size: >= 0. Pending requests before scaling up.
keep_warm_duration_in_seconds: >= 0. Idle timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| hardware | No | AMPERE_48 | |
| queue_size | No | ||
| workflow_id | Yes | ||
| max_instances | No | ||
| min_instances | No | ||
| workflow_version | Yes | ||
| keep_warm_duration_in_seconds | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context (e.g., billing for min_instances > 0) beyond the annotations, but lacks details on side effects, error conditions, or what happens after creation (e.g., response format). With readOnlyHint=false and openWorldHint=true, the description partially compensates.
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 brief summary, an important usage note, and a detailed Args list. Every sentence is informative and front-loaded, with no waste.
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 8 parameters, no output schema, and minimal annotations, the description covers all parameter constraints, billing, and an alternative use case. It lacks response details, but the creation action is sufficiently specified for agent 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?
Schema description coverage is 0%, so the description provides full meaning for all 8 parameters, including ranges, enum values, default explanations, and billing implications. This adds significant value beyond the schema's titles and defaults.
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 'Create a Serverless API (ComfyUI) deployment' with a specific verb and resource. It distinguishes itself by noting that LoRA deployments should use the runcomfy.com UI instead, providing clear differentiation from sibling tools.
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 tool (to create a deployment) and explicitly states an alternative for LoRA deployments. It does not discuss exclusion of other sibling tools like update_deployment, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_deploymentADestructiveIdempotentInspect
Permanently delete a deployment.
Backs ``DELETE /prod/v2/deployments/{deployment_id}``. This cannot
be undone. Consider ``update_deployment(is_enabled=false)`` to pause
instead.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true; the description adds valuable context that deletion is permanent and irreversible, enhancing transparency 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?
Three short, purposeful sentences with no redundancy. Front-loads the core action, then provides backing and guidance.
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 simplicity (1 param, no output schema), the description covers purpose, irreversibility, and an alternative. Missing permission context, but overall 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 description coverage is 0% for the single parameter deployment_id, and the description does not explain what it represents (e.g., format, source), leaving the agent without additional guidance.
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 'Permanently delete' and the resource 'a deployment'. It also distinguishes from siblings like update_deployment by suggesting an alternative.
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 warns this cannot be undone and provides a clear alternative: 'Consider update_deployment(is_enabled=false) to pause instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deploymentARead-onlyIdempotentInspect
Get one deployment by ID.
Backs ``GET /prod/v2/deployments/{deployment_id}``.
Set include_payload=true to inspect the deployed workflow graph
(workflow_api_json) and default overrides — use the node IDs and
input names to build the ``overrides`` for ``submit_request``.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_id | Yes | ||
| include_readme | No | ||
| include_payload | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat safety. It adds behavioral context by explaining how include_payload reveals internal structure for subsequent submitted requests, which is beyond the 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?
Three compact sentences: purpose, endpoint mapping, and usage tip. Front-loaded with the core action. 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?
No output schema, but the description omits return structure details and ignores include_readme. It focuses on a specific integration use case, which is helpful but not fully comprehensive for a retrieval 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 explains include_payload's purpose but ignores include_readme and deployment_id is self-evident. Partial coverage—adds meaning for one of three parameters.
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 starts with 'Get one deployment by ID,' clearly stating the verb and resource. This distinguishes from sibling tools like list_deployments (plural retrieval), create_deployment, and delete_deployment, making the tool's 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 specific guidance on when to set include_payload=true: to inspect the workflow graph and build overrides for submit_request. While it doesn't explicitly exclude alternative tools, the usage context is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_request_resultARead-onlyIdempotentInspect
Fetch a completed request's outputs.
Backs ``GET /prod/v1/deployments/{deployment_id}/requests/{request_id}/result``.
Output URLs are hosted for 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| deployment_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds that outputs are hosted for 7 days, which is behavioral context beyond the annotations. 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?
The description is two sentences long, front-loaded with the core purpose, and includes the endpoint as context. Every sentence adds value without 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 two-parameter tool with rich annotations and no output schema, the description covers the main purpose and a key limitation (7-day hosting). It could be more explicit about the completion precondition, but overall it is sufficiently complete.
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%. The description does not explain the parameters (deployment_id, request_id) beyond their names, which are already in the schema. No additional semantics are provided.
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 'Fetch a completed request's outputs' with a specific verb and resource. It includes the underlying endpoint and distinguishes from siblings like get_request_status (which returns status) and cancel_request (which cancels).
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?
It implies use only for completed requests through the phrase 'completed request's outputs'. Mentions the 7-day retention policy, which limits when results are available. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_request_statusARead-onlyIdempotentInspect
Poll a request's current status.
Backs ``GET /prod/v1/deployments/{deployment_id}/requests/{request_id}/status``.
Lifecycle: ``in_queue`` → ``in_progress`` → ``completed`` / ``cancelled``.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| deployment_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by showing the lifecycle states and backing endpoint, though it does not disclose error handling or rate limits.
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 concise sentences, both providing useful information, though it could be slightly more focused.
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 0% parameter descriptions, the description omits return values, error cases, and how to interpret states, leaving critical gaps for a polling 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 coverage is 0%, and the description does not explain what deployment_id or request_id refer to beyond their names, failing to add meaning over the 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 explicitly states the tool polls a request's current status and provides the lifecycle states, distinguishing it from siblings 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?
The description implies use for checking status but does not specify when to use this tool versus alternatives like get_request_result, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_deploymentsARead-onlyIdempotentInspect
List Serverless API deployments in the caller's account.
Backs ``GET /prod/v2/deployments``.
Args:
ids: Optional list of deployment IDs to filter to.
include_payload: Include workflow_api_json, overrides, and
object_info_url for each deployment. Larger response.
include_readme: Include the deployment's README markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| include_readme | No | ||
| include_payload | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds context about parameter effects (e.g., larger response for include_payload) and the underlying API endpoint. This enhances transparency beyond annotations without contradicting them.
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 extremely concise, front-loaded with the main purpose, and followed by a brief args section. Every sentence adds value, with no redundant or verbose language.
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 no output schema, but the description explains what is listed (deployments) and the optional inclusions. It lacks details about pagination or return structure, but given the simple list nature and strong annotations, it is nearly complete.
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 coverage, the description compensates by explaining each parameter's purpose: ids for filtering, include_payload for extra fields, and include_readme for README content. It does not dive into format or constraints, but the explanations are sufficient for basic usage.
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 tool lists Serverless API deployments in the caller's account, distinguishing it from sibling tools like get_deployment (single) and create/delete/update (mutations). The verb 'list' and resource 'deployments' are specific and 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 context about the tool's purpose but does not explicitly state when to use it versus alternatives. However, the name and sibling tools make it clear that this is the listing operation, and the mention of larger responses for certain parameters offers implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_requestAInspect
Submit an async inference request to a deployment.
Backs ``POST /prod/v1/deployments/{deployment_id}/inference``.
Args:
deployment_id: Target deployment.
overrides: Partial graph keyed by node_id, e.g.
``{"6": {"inputs": {"text": "a cat"}}}``.
Use ``get_deployment(include_payload=true)`` to discover
node IDs and input names.
workflow_api_json: Advanced — run a different workflow without
updating the deployment. Omit ``overrides`` in this mode.
extra_data: E.g. ``{"api_key_comfy_org": "comfyui-..."}`` for
ComfyUI Core API nodes.
webhook_url: Push-based updates instead of polling.
webhook_intermediate_status: Fire webhooks on every status
change, not just terminal.
wait_for_completion: If true, poll until done and return the
result inline.
timeout_seconds: Max wait when wait_for_completion=true.
File inputs: pass a public HTTPS URL or Base64 data URI directly
in the overrides value, e.g.
``{"189": {"inputs": {"image": "https://example.com/photo.jpg"}}}``
or ``{"189": {"inputs": {"image": "data:image/jpeg;base64,/9j..."}}}``.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | ||
| extra_data | No | ||
| webhook_url | No | ||
| deployment_id | Yes | ||
| timeout_seconds | No | ||
| workflow_api_json | No | ||
| wait_for_completion | No | ||
| webhook_intermediate_status | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a write operation (readOnlyHint=false) and potentially modifies external state (openWorldHint=true). The description discloses async behavior and polling mechanics but does not elaborate on side effects like cost implications or rate limits. Adding more context about external effects would improve 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 well-structured with a clear purpose statement followed by parameter explanations. While slightly lengthy, the bullet-like format aids readability. Every section serves a purpose without major 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?
Given the complexity of 8 parameters and async behavior, the description is remarkably complete. It covers all parameters, provides examples, explains edge cases, and describes the behavior when wait_for_completion is true. The tool's full context is well addressed.
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 coverage, the description compensates well by explaining each parameter in plain language, including examples for overrides, workflow_api_json, and file inputs. The explanations add significant meaning beyond the schema structure.
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 it submits an async inference request, with specific verb 'submit' and resource 'deployment'. While it doesn't explicitly differentiate from siblings like cancel_request or get_request_result, the purpose is 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 detailed context for parameter usage, including when to use overrides vs workflow_api_json, how to handle file inputs, and webhook options. However, it does not specify when not to use this tool or mention alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_deploymentBInspect
Partially update a deployment.
Backs ``PATCH /prod/v2/deployments/{deployment_id}``. Only pass the
fields you want to change. Set is_enabled=false to pause;
true to re-enable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| hardware | No | ||
| is_enabled | No | ||
| queue_size | No | ||
| deployment_id | Yes | ||
| max_instances | No | ||
| min_instances | No | ||
| workflow_version | No | ||
| keep_warm_duration_in_seconds | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds that is_enabled=false pauses the deployment, but lacks details on other behavioral traits like whether the deployment must exist or what happens to omitted fields.
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 brief (two sentences) and front-loaded with the main action, but it is slightly underinformative given the parameter count.
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?
With no output schema and minimal annotations, the description fails to cover return values, error conditions, or prerequisites (e.g., the deployment must exist). This leaves significant gaps for an agent 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 0%, yet the description only explains the is_enabled parameter. It does not clarify the meaning or constraints of the other eight parameters (name, hardware, instance counts, etc.), leaving the agent with insufficient guidance.
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 it performs a partial update (PATCH) on a deployment, which distinguishes it from creation or deletion tools. However, it could explicitly differentiate from create_deployment.
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?
It instructs to only pass fields to change and provides a specific example for pausing, but does not state when not to use this tool or mention alternatives like create_deployment for full creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!