Summary
Dokploy MCP should expose enough schedule/deployment tooling for agents to safely run and inspect one-off compose schedule commands.
Related core issue: Dokploy/dokploy#4718.
Current behavior
The MCP exposes:
schedule-create
schedule-runManually
deployment-allByType
compose-readLogs, but it requires a Docker containerId
For a failed compose schedule manual run, MCP currently returns only:
{
"success": false,
"error": "Failed to execute schedule-runManually",
"details": "Error: Request failed with status code 500"
}
A schedule deployment row can be queried via deployment-allByType({ type: "schedule", id: scheduleId }), and it contains deploymentId, status, and logPath, but MCP does not expose a direct deployment-readLogs tool in the current tool surface available to the client. compose-readLogs is not enough because it needs a runtime container id, not a schedule deployment id.
Needed MCP capabilities
Once Dokploy core returns structured metadata from schedule.runManually, MCP should expose it directly, for example:
schedule.runManually({ scheduleId }) => {
scheduleId: string
deploymentId: string
status: "running" | "done" | "error"
logPath?: string
}
MCP should also expose a safe log read tool for schedule deployments, either by generating the existing OpenAPI endpoint or adding a documented route:
deployment.readLogs({ deploymentId, tail? })
or a schedule-focused wrapper:
schedule.readLogs({ scheduleId, deploymentId?, tail? })
Why this matters
This is important for safe AI-agent automation:
- run a one-off diagnostic/smoke command inside a compose service;
- avoid persistent env mutation for temporary flags;
- avoid full env replacement when env is redacted;
- avoid SSH access to Dokploy internals;
- inspect failure logs without exposing secrets.
Example use case: run a dev-only acceptance smoke with process-local env flags inside a compose service, then verify logs and leave persistent env unchanged.
Acceptance criteria
schedule-runManually returns or preserves actionable deployment metadata from Dokploy core.
- MCP exposes a way to read schedule deployment logs by deployment id.
- Failed schedule commands still expose log access metadata without returning raw secrets.
- Tests cover a failed manual run response and log retrieval routing.
- No fallback requires reading/replacing full env blocks.
Related existing env safety work
Safe env patch/upsert is tracked separately:
This schedule/log issue is complementary: it lets clients run temporary process-local commands without requiring persistent env mutation at all.
Summary
Dokploy MCP should expose enough schedule/deployment tooling for agents to safely run and inspect one-off compose schedule commands.
Related core issue: Dokploy/dokploy#4718.
Current behavior
The MCP exposes:
schedule-createschedule-runManuallydeployment-allByTypecompose-readLogs, but it requires a DockercontainerIdFor a failed compose schedule manual run, MCP currently returns only:
{ "success": false, "error": "Failed to execute schedule-runManually", "details": "Error: Request failed with status code 500" }A schedule deployment row can be queried via
deployment-allByType({ type: "schedule", id: scheduleId }), and it containsdeploymentId,status, andlogPath, but MCP does not expose a directdeployment-readLogstool in the current tool surface available to the client.compose-readLogsis not enough because it needs a runtime container id, not a schedule deployment id.Needed MCP capabilities
Once Dokploy core returns structured metadata from
schedule.runManually, MCP should expose it directly, for example:MCP should also expose a safe log read tool for schedule deployments, either by generating the existing OpenAPI endpoint or adding a documented route:
or a schedule-focused wrapper:
Why this matters
This is important for safe AI-agent automation:
Example use case: run a dev-only acceptance smoke with process-local env flags inside a compose service, then verify logs and leave persistent env unchanged.
Acceptance criteria
schedule-runManuallyreturns or preserves actionable deployment metadata from Dokploy core.Related existing env safety work
Safe env patch/upsert is tracked separately:
This schedule/log issue is complementary: it lets clients run temporary process-local commands without requiring persistent env mutation at all.