{"id":"99ee1673-3605-4881-bad0-422cc0702ec8","slug":"cueport","kind":"mcp","name":"cueport","summary":"CueAPI agent-work scheduling: cues, executions, claiming, heartbeats, and outcomes.","owner":"CloudCorpRecords","repoUrl":"https://github.com/CloudCorpRecords/cueport","license":"MIT","licenseTier":"permissive","trust":"community","stars":0,"match":null,"fewStars":true,"format":"mcp","createdAt":"2026-11-02T07:21:45.000Z","addedAt":"2026-11-02T12:47:55.175Z","logoUrl":"https://avatars.githubusercontent.com/u/95189389?u=8e277e1a24ff84ae7b49c89e6897fa44178a5c34&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["utilities"],"tags":[],"runtime":"node","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-11-02T12:49:20.901Z","sample":false,"url":"https://conduits.dev/tools/cueport","language":"TypeScript","transports":["stdio"],"install":{"npm":"@reneturcios/cueport"},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# cueport\n\ncueport gives an MCP host or a terminal access to CueAPI, the\ncoordination layer for agent work: schedule cues (recurring cron or\none-time), fire them on demand, watch their executions, claim worker\nexecutions, keep a claim alive with heartbeats, and close the loop\nby reporting an outcome backed by evidence. One binary serves a\ncommand-line interface and a stdio MCP server.\n\nAn API key is required. Set `CUEAPI_API_KEY` to a key from your\nCueAPI account; every call sends it as `Authorization: Bearer\n<key>`, and a missing key fails before any request is attempted.\nSelf-hosting or testing against another host? Set `CUEAPI_BASE_URL`\nalongside the key; when it is unset, calls go to\n`https://api.cueapi.ai`.\n\n## Install\n\n```bash\nnpx @reneturcios/cueport list-cues\n```\n\nOr run the container image:\n\n```bash\ndocker run -i ghcr.io/cloudcorprecords/cueport\n```\n\nThe container defaults to the MCP server (see below). Pass CLI\narguments to use it as a CLI instead.\n\n## CLI\n\n```bash\ncueport create-cue --name digest --schedule \"0 9 * * *\" --callback-url https://example.test/hook\ncueport list-cues --status active --limit 5\ncueport get-cue cue_abc123\ncueport fire-cue cue_abc123 --payload-override '{\"topic\":\"release notes\"}'\ncueport update-cue cue_abc123 --name \"morning digest\"\ncueport pause-cue cue_abc123\ncueport resume-cue cue_abc123\ncueport delete-cue cue_abc123\ncueport list-executions --cue-id cue_abc123 --status failed\ncueport get-execution exec_123\ncueport list-claimable --task digest --agent worker-a\ncueport claim-execution exec_123 --worker-id worker-7\ncueport claim-next --task-name digest --worker-id worker-7\ncueport heartbeat exec_123 --worker-id worker-7\ncueport report-outcome exec_123 --outcome succeeded --external-id ext_42 --result-url https://example.test/result\n\ncueport --version\n```\n\nCommands print the upstream JSON payload. Exit codes: `0` on\nsuccess, `1` when a call fails (including a missing API key or an\nupstream API error), `2` for usage errors.\n\nTwo behaviours are worth knowing. Pausing and resuming are not\nseparate endpoints: both are a `PATCH /v1/cues/{id}` carrying only a\nstatus field (`paused` or `active`). And `claim-next` is a fan-out,\nnot a single call: the claim endpoint has no task filter, so the\ntool first fetches the server-side filtered claimable list, picks\nthe oldest entry, and then claims that execution by id.\n\n## MCP server\n\nOne bin serves both faces. The `mcp` subcommand starts a stdio MCP\nserver:\n\n```bash\nnpx -y @reneturcios/cueport mcp\n```\n\nMCP client configuration:\n\n```json\n{\n  \"mcpServers\": {\n    \"cueport\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@reneturcios/cueport\", \"mcp\"],\n      \"env\": {\n        \"CUEAPI_API_KEY\": \"cue_sk_...\"\n      }\n    }\n  }\n}\n```\n\nAdd `CUEAPI_BASE_URL` to the `env` block to point the server at a\ndifferent CueAPI-compatible host.\n\n### Tools\n\n| Tool | Input | What it does |\n| --- | --- | --- |\n| `cueapi_create_cue` | `name`, `schedule` (required); optional description, callback, method, timezone, payload, task and platform fields | Create a recurring or one-time cue. |\n| `cueapi_list_cues` | `status`, `limit` (optional) | List cues, filtered by status. |\n| `cueapi_get_cue` | `cue_id` | Fetch one cue. |\n| `cueapi_fire_cue` | `cue_id`; optional `payload_override`, `merge_strategy` (`merge` default, or `replace`) | Fire a cue immediately. |\n| `cueapi_update_cue` | `cue_id` plus any mutable cue fields | Sparse update; only provided fields are sent. |\n| `cueapi_pause_cue` | `cue_id` | Pause a cue (PATCH with status `paused`). |\n| `cueapi_resume_cue` | `cue_id` | Resume a cue (PATCH with status `active`). |\n| `cueapi_delete_cue` | `cue_id` | Delete a cue permanently. |\n| `cueapi_list_executions` | `cue_id`, `status`, `limit` (optional) | List executions, filtered by cue and status. |\n| `cueapi_get_execution` | `execution_id` | Fetch one execution, with state and outcome. |\n| `cueapi_list_claimable_executions` | `task`, `agent`, `limit` (optional) | List unclaimed worker executions, filtered server-side. |\n| `cueapi_claim_execution` | `execution_id`; optional `worker_id` | Atomically claim one execution. |\n| `cueapi_claim_next_execution` | `task_name`, `worker_id` (optional) | Claim the oldest claimable execution. |\n| `cueapi_execution_heartbeat` | `execution_id`, `worker_id` (both required) | Extend a claim lease; `worker_id` travels in the `X-Worker-Id` header. |\n| `cueapi_report_outcome` | `execution_id`, `outcome` (required); optional evidence fields | Report a write-once outcome with evidence. |\n\n## Development\n\n```bash\nnpm install\nnpm run build   # tsc -> dist/\nnpm test        # node test runner over test/*.test.ts, no network (fake fetch fixtures)\nnpm run dev     # run the CLI from source via tsx\n```\n\n## License\n\nMIT — see `LICENSE`.\n"}