Skip to main content
Glama
sapientsai

dokploy-mcp-server

by sapientsai

dokploy_application

Manage applications through actions: create, deploy, update, monitor, and configure environment variables, git sources, and build settings.

Instructions

Manage applications. create: name+environmentId. get: applicationId (returns env vars, git source, build config). update: applicationId+fields (supports sourceType, repository, owner, branch, customGitUrl, customGitBranch, githubId, dockerImage, etc.). move: applicationId+targetEnvironmentId. deploy: applicationId, redeploy? (note: first deploy on new services may fail — retry immediately). start/stop/delete/markRunning/refreshToken/cleanQueues/killBuild/cancelDeployment: applicationId. reload: applicationId+appName. saveEnvironment: applicationId+env (KEY=VALUE pairs, one per line). saveBuildType: applicationId+buildType. traefikConfig: applicationId, traefikConfig? (omit to read). readMonitoring: appName. readLogs: applicationId, tail? (default 100), since? ('all' or duration like '1h'), search? (substring filter).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
applicationIdNo
nameNo
environmentIdNo
descriptionNo
serverIdNo
targetEnvironmentIdNo
redeployNo
titleNo
deployDescriptionNoDeploy description (maps to API description field)
dockerImageNo
commandNo
memoryLimitNo
cpuLimitNo
replicasNo
autoDeployNo
appNameNo
sourceTypeNoSource type. github → set repository+owner+branch (+githubId for private). git → set customGitUrl+customGitBranch. docker → set dockerImage. The API also supports gitlab/bitbucket/gitea/drop sources, but those need provider-specific fields not yet exposed by this tool.
repositoryNoGitHub repository name
ownerNoGitHub org/user
branchNoBranch name
customGitUrlNoCustom git repository URL (for sourceType: git)
customGitBranchNoBranch for custom git source
githubIdNoGitHub App provider ID for private repo access
envNoEnvironment variables as KEY=VALUE pairs, one per line. Example: 'DB_HOST=localhost\nDB_PORT=5432'
buildArgsNo
buildSecretsNo
createEnvFileNo
buildTypeNodockerfile | heroku_buildpacks | paketo_buildpacks | nixpacks | static | railpack
dockerfileNo
dockerContextPathNo
dockerBuildStageNo
publishDirectoryNo
traefikConfigNoNew config content (omit to read current)
tailNoNumber of recent log lines to return (default 100)
sinceNoTime range: 'all' or a duration like '30m', '1h', '7d'
searchNoFilter log lines by substring (alphanumeric + ' ._-' only)
Behavior4/5

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

With no annotations, description discloses important behaviors: first deploy may fail, traefikConfig omission reads current config, readLogs parameters. Covers mutability and side effects for most actions.

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?

Single paragraph but well-structured with action: parameters format. Dense but efficient, though bullet points would improve readability. No unnecessary sentences.

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

Completeness3/5

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

Covers all actions and main behaviors, but lacks details on return values, error handling, and some parameter constraints. Given 37 parameters and no output schema, more depth would be beneficial.

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 coverage is low (38%), but description adds meaning for many parameters (e.g., action-specific fields, env format, tail/since/search). However, several parameters remain unexplained (title, serverId, etc.).

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

Purpose5/5

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

Clearly describes the tool as 'Manage applications' with a comprehensive list of actions (create, get, update, etc.) each with required parameters. This makes it distinct from sibling tools that manage other resources.

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

Usage Guidelines4/5

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

Provides per-action guidelines (e.g., create needs name+environmentId, deploy includes note about first deploy failure). No explicit exclusions or alternatives to sibling tools, 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.

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/sapientsai/dokploy-mcp-server'

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