A compact MCP server that gives AI agents access to the full Dokploy PaaS API through just 3 default tools, covering hundreds of underlying procedures with minimal context window overhead.
Core Tools
search – Discover Dokploy API procedures, parameters, HTTP methods, schemas, and response hints by searching text, getting recommendations, filtering by tag, or looking up a specific procedure (e.g., catalog.get("application.update"), catalog.recommend("tail project logs")).
execute – Run multi-step JavaScript workflows against the full Dokploy API using globals dokploy and helpers; supports guided deploy-application workflows with preview/apply modes, rollout polling, and cancellation via MCP tasks.
list_profiles – List all configured Dokploy connection profiles (names and URLs) without exposing API keys, useful when managing multiple Dokploy organizations.
What You Can Do
Deploy applications – Trigger and monitor deployments, with optional guided workflow mode for safe preview-before-apply rollouts.
Manage projects and services – List, inspect, and operate on Dokploy projects and their services.
Work with Docker Compose – Deploy and manage compose stacks.
Stream and inspect logs – Tail project and deployment logs across environments.
Manage domains and databases – Configure domains and create/operate on databases hosted in Dokploy.
Multi-org / multi-profile support – Switch between named profiles (different Dokploy instances) by passing a profile argument.
Explore the full API – Use search to browse 544+ procedures across 50 tags, then execute them in code mode.
Flexible Modes: Default (3 tools), raw mode (one tool per endpoint), or hybrid mode combining both — for tailored context window usage. Works cleanly with AI assistants like Codex, Cursor, Claude Code, and Claude Desktop.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@vibetools/dokploy-mcp deploy my latest build to production"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Dokploy that works cleanly with Codex, Cursor, Claude Code, and Claude Desktop.
Three tools up front. Hundreds of Dokploy procedures underneath. Less schema tax, more actual deploys.
Most MCP servers treat your context window like free landfill. This one starts with
search, execute, and list_profiles, then earns the rest.
What that buys you:
compact default surface instead of hundreds of raw endpoint tools
generated, broad Dokploy coverage underneath
real workflows for deploys, compose, logs, domains, databases, and profiles
local stdio plus hosted HTTP metadata in the same package
Need proof instead of a sales monologue? Start with docs/live-e2e-proof.md.
Generated API procedures in the pinned catalog: 544
Generated tags: 50
Default public MCP tools: 3 (search, execute, list_profiles)
Default tools/list footprint from the current budget check: about 1,681 tokens (6,723 bytes)
Reduction versus the classic endpoint-per-tool baseline (92,354 tokens): 98.2%
Classic endpoint-per-tool baseline | Current Code Mode default | |
Tool definitions sent | about | about |
Public MCP tools | hundreds of endpoint schemas |
|
Context window tax | wide schema dump | compact fixed surface |
Related MCP server: Dokploy MCP Server
Get your API key from Dokploy Settings > Profile > API/CLI.
For env-based setup, start from .env.example.
If your client uses a JSON-style MCP config, this is the whole block:
{
"mcpServers": {
"dokploy": {
"command": "npx",
"args": ["@vibetools/dokploy-mcp"],
"env": {
"DOKPLOY_URL": "https://panel.example.com",
"DOKPLOY_API_KEY": "dokp_..."
}
}
}
}If your client uses CLI-based MCP management:
# Codex
codex mcp add dokploy \
--env DOKPLOY_URL=https://panel.example.com \
--env DOKPLOY_API_KEY=dokp_... \
-- npx @vibetools/dokploy-mcp
# Claude Code
claude mcp add --transport stdio \
-e DOKPLOY_URL=https://panel.example.com \
-e DOKPLOY_API_KEY=dokp_... \
dokploy -- npx @vibetools/dokploy-mcpAlready authenticated with the Dokploy CLI or local
dokploy-mcp config?
You may not need the env block at all.
Using multiple Dokploy organizations?
Keep one compact MCP server and configure profiles with DOKPLOY_PROFILES_JSON:
{
"mcpServers": {
"dokploy": {
"command": "npx",
"args": ["@vibetools/dokploy-mcp"],
"env": {
"DOKPLOY_PROFILES_JSON": "{\"redivo\":{\"url\":\"https://redivo.example.com\",\"apiKey\":\"dokp_redivo\"},\"personal\":{\"url\":\"https://personal.example.com\",\"apiKey\":\"dokp_personal\"},\"mezon\":{\"url\":\"https://mezon.example.com\",\"apiKey\":\"dokp_mezon\"}}"
}
}
}
}Use list_profiles to see the available default and named profile targets without exposing API
keys. Pass profile to execute when you want a named profile instead of the default target:
{
"profile": "redivo",
"code": "return await dokploy.project.all()"
}search also accepts an optional profile argument for profile-name validation while preserving
the same compact catalog behavior.
Hosted HTTP sessions keep their request-scoped remote credentials bound to the session. Named local profiles are not exposed there.
Want the wizard path instead of manual config?
npx @vibetools/dokploy-mcp setupsearch: discover Dokploy procedures and contracts
execute: run multi-step workflows in one sandboxed call
list_profiles: list configured Dokploy profile names and URLs without secrets
optional raw mode: one tool per procedure
optional hybrid mode: Code Mode plus selected raw tools
optional hosted HTTP path with server.json metadata and header-based remote auth
If you are new, use the default mode and stop trying to outsmart a problem that already has a working shape.
npx @vibetools/dokploy-mcp
npx @vibetools/dokploy-mcp serve-stdio
npx @vibetools/dokploy-mcp serve-http
npx @vibetools/dokploy-mcp setup
npx @vibetools/dokploy-mcp versiongit clone https://github.com/vcode-sh/dokploy-mcp.git && cd dokploy-mcp
npm install
npm run build
npm run lint
npm test
npm run docs:check:factsThe rest lives in docs, where it belongs.
Forked from Dokploy/mcp. Started at 67 tools, mass-refactored to 377, then rebuilt the whole thing into an architecture that makes the tool count irrelevant.
Mauricio Siu built Dokploy itself -- the PaaS this server talks to. Without the platform, this is a very elaborate way to POST into the void.
Henrique Andrade wrote the original MCP server. 15 commits, every PR merged. The kind of contributor who closes issues instead of opening them.
Contributors who shaped the original: Joshua Macauley -- lucasleal-developer -- Nour Eddine Hamaidi -- Corey -- Azil0ne
Unmerged PRs are still blueprints. That's how open source works -- stolen inspiration with better commit messages.
MIT - Vibe Code
Original work by Henrique Andrade under Apache 2.0 -- see LICENSE-ORIGINAL.
Run JavaScript code or a guided Dokploy workflow. In code mode, write bare JS against global dokploy and helpers without wrapping it in a function. In workflow mode, deploy-application can resolve a target, choose preview vs apply, collect bounded rollout options, and build a bounded plan when sampling and elicitation are enabled. When MCP tasks are enabled, execute also supports polling and cancellation for long-running runs. Known Dokploy IDs yield reusable dokploy://... resource links, and search helps discover procedures.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | JavaScript code. `dokploy` and `helpers` are globals -- do NOT wrap in a function. Simple: `await dokploy.project.all()`. Multi-step: `const app = await dokploy.application.one({ applicationId: "abc" }); return app.name`. dokploy.<module>.<method>(params) calls the Dokploy API. helpers: sleep(ms), assert(cond, msg), pick(obj, keys), limit(arr, n). | |
| workflow | No | Optional guided workflow mode. Currently supports `deploy-application` with interactive target resolution, preview/apply selection, bounded rollout options, and an MCP-native plan when phase 3 sampling and elicitation are enabled. | |
| profile | No | Dokploy profile name. Required when DOKPLOY_PROFILES_JSON configures multiple profiles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits such as code execution, workflow modes, polling/cancellation for long-running runs, and resource links. The annotation 'openWorldHint: true' is aligned, and the description adds useful context beyond annotations, though it could be more explicit about side effects.
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 clear separation of code mode and workflow mode. While it is relatively long, the length is justified by the complexity of the tool. A minor improvement could be front-loading the core purpose more succinctly.
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 complexity (nested objects, no output schema), the description covers modes, parameters, globals, and workflow features. It mentions resource links and search, but lacks explicit details on return values or error handling, which is a minor gap.
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 100% with detailed parameter descriptions. The tool description goes beyond the schema by explaining the purpose of globals (dokploy, helpers), usage patterns, and workflow options like target resolution and rollout. This adds significant value.
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 runs JavaScript code or a guided Dokploy workflow, distinguishing two modes (code and workflow). It provides specific details about each mode, but does not explicitly differentiate from sibling tools like list_profiles or search.
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 when to use each mode (code vs workflow) but lacks explicit guidance on when not to use the tool or when to prefer siblings. It mentions specific workflow capabilities but does not set clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available Dokploy profiles, including default and named targets, without exposing API keys. Returns profile names, normalized Dokploy API URLs, and config sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent behavior. The description adds value by stating it does not expose API keys and describes the returned data, providing safety context 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?
Single sentence, front-loaded with 'List the available Dokploy profiles'. Every part is necessary and 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 no parameters, strong annotations, and no output schema, the description sufficiently explains purpose and return content. No missing information.
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 parameters exist (0 params), so schema coverage is 100%. Baseline for zero parameters is 4, and the description adds no param information but does not need to.
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 available Dokploy profiles, including default and named targets, and specifies return fields (names, URLs, config sources). It distinguishes from siblings like 'execute' and 'search'.
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 profiles but offers no explicit guidance on when to use this tool versus alternatives like 'execute' or 'search'. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Dokploy API catalog. IMPORTANT: Do NOT wrap code in a function -- catalog is already a global. Write bare code: catalog.searchText("deploy") or catalog.recommend("safe database password rotation") or catalog.getByTag("application") or catalog.get("application.one"). Common patterns: catalog.recommend("tail project logs across environments") -> helper-first workflow suggestions; catalog.get("application.one") -> application detail fields plus optional shaping params; catalog.get("application.update") -> build/runtime/resource tuning fields such as byte-based memory limits; catalog.get("application.many") -> batched application reads; catalog.get("project.overview") -> compact project state view; catalog.get("deployment.all") -> deployment history entries. Returns procedure names, parameters, HTTP methods, schemas, and response hints for key endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code. `catalog` is a global -- do NOT wrap in a function. Examples: `catalog.searchText("application deploy")` | `catalog.recommend("safe database password rotation")` | `catalog.getByTag("compose")` | `catalog.get("application.one")` | `catalog.get("application.update")`. Methods: searchText(query), recommend(query), get(procedure), getByTag(tag), endpoints, byTag. | |
| profile | No | Optional Dokploy profile name to validate before returning catalog results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context by detailing the return types (procedure names, parameters, schemas, etc.) and emphasizing that 'catalog' is a global. 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 front-loaded with the critical usage note about not wrapping in a function. It then provides structured examples. While slightly lengthy, every sentence adds value, and the structure is logical.
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?
Despite having no output schema, the description explains what the tool returns in sufficient detail (procedure names, parameters, HTTP methods, etc.). It covers the core functionality and usage patterns comprehensively.
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 100%. The description adds significant value by explaining that 'code' is JavaScript code with examples, and that 'profile' is optional for validation. This goes beyond the schema's basic 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 specifies the verb 'Search' and the resource 'Dokploy API catalog'. It effectively distinguishes itself from sibling tools 'execute' and 'list_profiles' by focusing on catalog exploration rather than execution or profile listing.
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 extensive usage guidelines with concrete code examples and common patterns. It explains how to use different methods and what each returns. However, it lacks explicit contrast with sibling tools or clear 'when not to use' statements, preventing a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v3.1.2executelist_profilessearchEach tool targets a different aspect: execute handles code and workflows, list_profiles lists profiles, and search queries the API catalog. Occasional overlap exists (execute and search both reference workflows) but purposes are mostly distinct.
Naming is inconsistent: execute (bare verb), list_profiles (verb_noun with snake_case), search (bare verb). There is no clear pattern across the tool set.
With only 3 tools, the server feels under-scoped for a platform like Dokploy that typically requires managing applications, deployments, and configurations. A broader tool set is expected.
The tool set lacks essential operations such as creating, updating, or deleting applications or deployments. While execute and search provide some flexibility, core lifecycle management is absent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vcode-sh/dokploy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
