Skip to main content
Glama

coolify_application_deployments

Manage application deployments by listing, retrieving details, or triggering new deployments through the Coolify MCP Server.

Instructions

Application deployment management - list, get, and trigger deployments

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: list (list all deployments), get (get deployment by UUID), trigger (trigger deployment)
uuidNoApplication UUID (required for trigger action)
deployment_uuidNoDeployment UUID (required for get action)
force_rebuildNoForce rebuild (optional for trigger action, default: false)
pageNoPage number (optional for list action)
per_pageNoItems per page (optional for list action)

Implementation Reference

  • The handler function that implements the logic for 'coolify_application_deployments' tool, dispatching to API endpoints for list, get, and trigger deployments.
    async applicationDeployments(action: string, args: any) {
      switch (action) {
        case 'list':
          const queryString = this.apiClient.buildQueryString(args);
          const response = await this.apiClient.get(`/deployments?${queryString}`);
          return { content: [{ type: 'text', text: JSON.stringify(response.data, null, 2) }] };
        case 'get':
          if (!args.deployment_uuid) throw new Error('Deployment UUID is required for get action');
          const getResponse = await this.apiClient.get(`/deployments/${args.deployment_uuid}`);
          return { content: [{ type: 'text', text: JSON.stringify(getResponse.data, null, 2) }] };
        case 'trigger':
          if (!args.uuid) throw new Error('Application UUID is required for trigger action');
          const triggerResponse = await this.apiClient.post('/deploy', {
            uuid: args.uuid,
            force_rebuild: args.force_rebuild || false,
          });
          return { content: [{ type: 'text', text: JSON.stringify(triggerResponse.data, null, 2) }] };
        default:
          throw new Error(`Unknown application deployments action: ${action}`);
      }
    }
  • The input schema and metadata definition for the 'coolify_application_deployments' tool.
    {
      name: 'coolify_application_deployments',
      description: 'Application deployment management - list, get, and trigger deployments',
      inputSchema: {
        type: 'object',
        properties: {
          action: { 
            type: 'string', 
            enum: ['list', 'get', 'trigger'],
            description: 'Action to perform: list (list all deployments), get (get deployment by UUID), trigger (trigger deployment)'
          },
          uuid: { 
            type: 'string', 
            description: 'Application UUID (required for trigger action)' 
          },
          deployment_uuid: { 
            type: 'string', 
            description: 'Deployment UUID (required for get action)' 
          },
          force_rebuild: { 
            type: 'boolean', 
            description: 'Force rebuild (optional for trigger action, default: false)' 
          },
          page: { 
            type: 'number', 
            description: 'Page number (optional for list action)' 
          },
          per_page: { 
            type: 'number', 
            description: 'Items per page (optional for list action)' 
          },
        },
        required: ['action'],
      },
    },
  • src/index.ts:110-111 (registration)
    Registration/dispatch point in the main tool handler switch statement that routes calls to the applicationDeployments handler.
    case 'coolify_application_deployments':
      return await this.handlers.applicationDeployments(args.action, args);
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'list, get, and trigger deployments' implies read and write operations, the description doesn't disclose critical behavioral traits such as authentication requirements, rate limits, whether 'trigger' is destructive or reversible, or what happens on success/failure. For a multi-action tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place by specifying the three actions. However, it could be slightly more structured by explicitly separating the actions or adding minimal context, but it's appropriately concise for its content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, 3 distinct actions including a write operation 'trigger'), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or return formats, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all six parameters thoroughly with descriptions and enum values. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like how 'uuid' and 'deployment_uuid' differ). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Application deployment management - list, get, and trigger deployments' clearly states the tool's purpose as managing deployments with three specific actions, but it doesn't distinguish this tool from its many siblings (like coolify_application_lifecycle or coolify_service_lifecycle) that might also handle deployment-related tasks. The description is accurate but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With 17 sibling tools including several that might overlap with deployment management (e.g., coolify_application_lifecycle, coolify_service_lifecycle), the agent receives no help in selecting this specific tool over others. The description merely states what the tool does, not when to use it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HowieDuhzit/CoolifyMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server