Prometheor

Schedule a task

schedule_task

DestructiveIdempotent

Saves a task that starts again at set times, e.g. every morning at 8, Mon–Fri at 07:30, or once tomorrow at 9. Use it only when the owner asks for a recurring or later task. At each time Prometheor starts a normal task with this brief in the app you name (executor_id from list_agents; leave it out only when the owner has one app); its result comes back to you like a delegate's, and a run starts up to 5 minutes late. Give time (HH:MM, 24 hours) with days (leave out for every day) and timezone (the owner's time zone, e.g. Europe/Berlin; ask once if you do not know it), or once_at for one time. While a run's task has not ended, the next run is skipped, and a run while the Mac sleeps is left out (you hear of it in updates); missed runs are not caught up. action "list" shows the account's schedules; "pause", "resume" and "remove" need schedule_id. The owner also sees and pauses them in the Prometheor Mac app. At most 20 per account. Tell the owner in plain words when it runs next.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "schedule_task"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Weekdays, e.g. ["mon","tue","wed","thu","fri"]; every day when absent.
`name`	No	Optional short name the owner sees, e.g. "Morning briefing"; else the brief's first line.
`time`	No	Time of day, HH:MM in 24 hours, e.g. "08:00".
`brief`	No	The task for every run, written as for delegate.
`action`	No	create (default), list, pause, resume or remove.	create
`folder`	No	Optional. Where the app works (~, ~/… or absolute); the home folder when absent.
`once_at`	No	Instead of time and days: one run at this date and time with offset, e.g. "2026-10-30T09:00:00+01:00".
`timezone`	No	IANA time zone of the owner, e.g. "Europe/Berlin". Needed with time.
`execution`	No	Optional model, reasoning_effort or commands for the app, as in delegate.
`background`	No	Optional details for every run.
`executor_id`	No	The app that runs it (list_agents).
`schedule_id`	No	pause, resume, remove: the schedule from list or create.
`reply_session`	No	Optional. Your own web session id, told when a run has a result, a question or an end.
`idempotency_key`	No	create: a new random value per schedule; the same value again saves nothing twice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / execution / description

Previous value: -"Optional model, reasoning_effort, permission_mode or commands for the app, as in delegate."New value: +"Optional model, reasoning_effort or commands for the app, as in delegate."

First observedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: overlapping runs are skipped, runs during Mac sleep are dropped, missed runs are not caught up, runs may start up to 5 minutes late, and there is a hard cap of 20 schedules per account. It also discloses that the owner sees and can pause schedules in the Mac app and that run results/questions come back to the caller — none of which the structured fields convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the primary usage rule are front-loaded, and nearly every sentence carries operational meaning. It is still one dense paragraph mixing creation, lifecycle actions, limits and concurrency rules, which makes it harder to scan than a lightly structured version would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, no-required-field, multi-action tool with no output schema, the description covers the full operating model: creation paths, listing/management actions, concurrency, sleep, quota, latency and result delivery. An agent has enough to invoke it correctly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds cross-parameter logic absent from the schema: time must be paired with timezone and optional days, or once_at used instead; executor_id comes from list_agents and may be omitted only when the owner has a single app; pause/resume/remove require schedule_id. These conditional paths are exactly what the schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('saves a task that starts again at set times') and concretely shows the recurring/one-shot forms. It also distinguishes itself from the delegate flow by explaining that each run spawns a normal task 'like a delegate's', so an agent can separate it from delegate and list_tasks without reading schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is an explicit scope rule: 'Use it only when the owner asks for a recurring or later task', plus actionable prerequisites such as asking once for the timezone and telling the owner in plain words when it runs next. The alternative (delegate for immediate work) is only implied through the 'like a delegate's' comparison rather than named outright, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Prometheor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?