Sume Scheduled has no MCP tool or CLI command: your options

Sume Scheduled has no MCP tool and no CLI command today, so you cannot create, edit or run a schedule from the hosted MCP server or the sume CLI. You author a schedule in the Agents dashboard at https://www.sume.com/agents/scheduled, or by asking the Agent in chat to set one up for you. Once it exists, the Developer API can list it, read it, start runs and monitor runs, but it cannot create, edit or delete it.

This is the current state in the Scheduled docs, under the heading of what schedules do not support yet. If you are wiring a coding agent to Sume, plan around it instead of searching for a missing tool.

What you can do from each surface

The split matters when an agent is the one automating. Authoring is a human or chat task, while operating an existing schedule is a plain HTTP task. The table summarizes what the docs state.

Limits that affect an automation

Two more gaps appear in the same list. There is no events endpoint, so events_url on a run receipt is always null; use status_url and result_url, or a run webhook, which delivers the same receipt once when the run completes or fails. Schedules owned by a team workspace are not reachable over the public API yet, by either the opaque or the vanity path, so a team-owned automation needs the dashboard.

Be careful, too, about what a read returns. The instructions text is also deliberately omitted from the public schedule shape. A script that reads GET /v1/actions/{action_id} will see the title, status, trigger, cron, model, output schema and spend cap, but not the instructions, which you read and edit in the dashboard.

Why it is split this way

The docs frame a schedule as saved instructions an Agent carries out on a cadence, possibly across several generations, with a spend cap bounding each run. Authoring those instructions is closer to writing a prompt than to calling an endpoint, which is why creation sits with the dashboard and chat, where you can read the output and adjust. Operating the schedule is the repeatable part, which is why the API exposes list, read, run and monitor.

For an agent that needs to create something on demand rather than reuse a saved recipe, the two other surfaces are better matches: a Format stores how to do the work and takes inputs per call, and an Agent Completion stores nothing and takes the whole task per call.

A pattern that works

Keep the saved instructions in the dashboard, enable the API trigger, and let your agent or backend do the part the API does well: start runs with an Idempotency-Key, poll GET /v1/action-runs/{run_id}/status until next_action stops being poll_status, then fetch result.

``bash curl -sS "https://api.sume.com/v1/action-runs/$RUN_ID/status" \ -H "Authorization: Bearer $SUME_API_KEY" ``

If the task changes on every call and nothing is worth saving, skip schedules and use Agent Completions instead; the linked comparison of Agent Completions and Format runs explains the choice, and the Python polling guide shows the status loop in code.