Skip to main content
Glama
0xtlt

coolify-mcp

by 0xtlt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

coolify_create_application

[WRITE] Create a new Coolify application from various sources

Instructions

[WRITE] Create a new Coolify application from various sources

Input Schema

NameRequiredDescriptionDefault
nameNoApplication name
domainsNoDomain name(s) for the application
build_packNoBuild pack (dockerfile, nixpacks, static, dockercompose, dockerimage)
dockerfileNoInline Dockerfile content (for dockerfile source_type)
git_branchNoGit branch (default: main)
descriptionNoApplication description
server_uuidYesUUID of the server to deploy on
source_typeYesSource type for the application
project_uuidYesUUID of the project
custom_fieldsNoAdditional fields not listed above (advanced)
ports_exposesNoExposed ports, comma-separated (e.g. '3000,8080')
git_repositoryNoGit repository URL (required for public/private-github-app/private-deploy-key)
instant_deployNoDeploy immediately after creation
github_app_uuidNoGitHub App UUID (required for private-github-app)
environment_nameYesEnvironment name (e.g. 'production')
private_key_uuidNoPrivate key UUID (required for private-deploy-key)
docker_registry_image_tagNoDocker image tag (default: 'latest')
docker_registry_image_nameNoDocker image name (required for dockerimage, e.g. 'nginx')
custom_container_name_prefixNoReadable prefix for generated container names (Coolify v4.4+; slugified, max 30 chars, unique per server)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.3.0
    • addedInput schema / properties / custom_container_name_prefix
      Added value: +{
+  "description": "Readable prefix for generated container names (Coolify v4.4+; slugified, max 30 chars, unique per server)",
+  "maxLength": 255,
+  "type": "string"
+}
  2. First observedv4.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that this is a write operation via "[WRITE]" and "Create," but does not explain side effects, permission requirements, how instant_deploy behaves, or what happens across the different source types.

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 one short sentence with a useful "[WRITE]" prefix and is front-loaded with the core action. It contains no wasted language, though "from various sources" is vague enough to reduce precision slightly.

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?

For a complex write tool with 19 parameters, no annotations, and no output schema, the description is too minimal. It omits source-type distinctions, required field relationships, and operational consequences, leaving the schema to carry nearly all of the explanatory load.

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 schema already documents all 19 parameters including required fields, enums, and source-specific requirements. The description adds no parameter-level meaning beyond the vague phrase "from various sources," so the baseline of 3 is appropriate.

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

Purpose4/5

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

The description states a clear verb and resource: "Create a new Coolify application." The "[WRITE]" tag reinforces the operation type. However, it does not explicitly distinguish this tool from sibling alternatives such as coolify_update_application or coolify_delete_application, leaving that distinction implicit.

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?

There is no guidance on when to use this tool versus alternatives, nor are prerequisites such as needing a server UUID, project UUID, and environment name called out in prose. The create intent is inferable from the name, but no explicit usage context or exclusions are provided.

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

Deploy Server

Other Tools