Expose logs/stdout for manually run schedules

[agentHits]

Summary

The MCP server exposes schedule.runManually, schedule.one, and schedule.list, but there does not appear to be a MCP tool to read stdout/stderr/logs for a manually executed schedule.

For operational verification, schedule.runManually returning only true is not enough: the caller needs the command output or at least a way to read the generated schedule deployment log.

Use case

I use Dokploy MCP from an automation/coding agent to verify a self-hosted Dokploy dev stack without exposing private services or secrets.

A typical safe check is:

1. Create a disabled compose schedule for a private service, for example postgres.
2. Run a read-only verification command manually, for example checking whether a migration-created table exists.
3. Read the command output as audit evidence.
4. Delete the temporary schedule.

This allows verifying private runtime state without opening database ports, copying secrets out of Dokploy, or using SSH into the host.

Current behavior

• schedule.runManually returns only a boolean (true) on success.
• schedule.one / schedule.list can show that a schedule deployment finished with status done and includes a logPath internally.
• The MCP tool list includes log readers for applications, compose containers, Redis/Postgres/MySQL/etc., but not for schedule runs or generic deployment logs.
• There is no obvious MCP equivalent of deployment.readLogs for the schedule deployment log path.

Because of that, a successful schedule can be proven as done, but its stdout/stderr cannot be captured through MCP.

Expected behavior

One of these would solve it:

• Add schedule.readLogs(scheduleId, tail?, since?, search?) that returns logs from the latest/manual schedule run.
• Add deployment.readLogs(deploymentId, tail?, since?, search?) so schedule/application/compose deployments can be inspected uniformly.
• Make schedule.runManually optionally return the created deployment id and/or captured stdout/stderr.

Why this matters

For agent-driven infrastructure workflows, the difference between status: done and the actual command output matters. Examples:

• SELECT to_regclass('public.some_table') should prove the exact table name returned.
• Backup validation should prove a specific marker or row count.
• Migration smoke checks should produce evidence without exposing DB credentials.

Without schedule logs, agents either have to fall back to SSH, expose private service ports, or use awkward workarounds such as writing markers into service logs and reading them via compose.readLogs.

Workaround used

I worked around this by making the temporary schedule run a PostgreSQL RAISE LOG block so the result appears in the main Postgres container logs, then reading it via compose.readLogs:

DO $$
DECLARE r text;
BEGIN
  SELECT to_regclass('public.provider_key_states')::text INTO r;
  RAISE LOG 'provider_sync_table_check:%', coalesce(r, 'NULL');
END $$;

That works, but it is indirect and database-specific. A direct MCP schedule/deployment log reader would be cleaner and safer.

Environment

• Dokploy MCP server, docs source: /dokploy/mcp in Context7.
• Schedule type: compose schedule.
• Service: private compose service.
• Need: read output for a manually triggered, disabled schedule.

No secrets or private deployment data are included in this issue.