relaykeep-tasks
Related Servers
Alternatives to relaykeep-tasks
No user-submitted related servers found.
Related Servers
- FlicenseNot gradedqualityNot gradedmaintenanceEnables MCP clients and local orchestrators to drive Codex Desktop and codex-app-server as a durable async worker: submit a task or Plan Mode workflow, immediately receive an operationId or workflowId, then poll status, answer approvals, and read final reports without holding long-lived calls open. It also provides retry-safe submission, duplicate-turn protection, restart recovery, concurrency/worker queue visibility, and health, diagnostics, and repair tools backed by local SQLite state.-
- AlicenseAqualityDmaintenanceEnables MCP clients to submit long-running jobs that are executed safely in isolated child processes with a durable SQLite queue, configurable timeouts, retries with backoff, and backpressure.5MIT
- FlicenseNot gradedqualityAmaintenanceEnables MCP clients to drive Codex Desktop and codex-app-server as a durable asynchronous worker for long-running tasks, with polling, approvals, Plan Mode workflows, retry safety, diagnostics, and final reporting. It also provides recovery, queueing, and repair tools for reliable local automation.-
- FlicenseNot gradedqualityAmaintenanceEnables MCP clients and local orchestrators to submit long-running Codex Desktop tasks asynchronously, poll status, handle approvals and Plan Mode workflows, and retrieve durable reports without blocking on multi-hour calls.-
- AlicenseNot gradedqualityBmaintenanceEnables durable, least-privilege handoff of bounded tasks from a local producer to a configured MCP worker, with atomic claim, complete, and fail operations under expiring leases.MIT
- FlicenseNot gradedqualityAmaintenanceEnables MCP clients to submit and manage durable, asynchronous Codex Desktop tasks, including polling, approvals, Plan Mode workflows, and final reports. It provides retry-safe operations, recovery, diagnostics, and local state for reliable long-running automation.-
TDQS
Scored across 3 tools
Each tool maps to a distinct lifecycle operation: submit creates a task, read retrieves state and result, and cancel handles queued task cancellation. There is no meaningful overlap between the three actions.
All tool names are single-word imperative verbs—submit, read, cancel—following a consistent and predictable pattern. While not verb_noun style, the convention is uniform across the entire server.
Three tools is well-scoped for a task relay server: each tool covers a necessary operation and none are redundant. This is comfortably within the ideal 3-15 range.
The surface covers the core task lifecycle: submission, status/result reading, and cancellation of queued tasks. The inability to cancel running tasks is explicitly documented rather than an overlooked gap.