spawnpoint

Set schedule

set_schedule

Have spawnpoint call a route on a node, python, or docker app on a timer, for work at intervals: a digest, polling an inbox, a nightly export. Use it instead of a timer inside the app (setInterval, node-cron, APScheduler), which stops while the app sleeps: put the job in a POST route, deploy, then call set_schedule. At each time, spawnpoint wakes the app if it sleeps and sends one POST to path; the app does the work and answers 2xx when it is done. cron is five fields in timezone (UTC by default): "0 2 * * " is every day at 02:00, "/15 * * * *" every 15 minutes, "0 9 * * 1-5" weekdays at 09:00. Each POST carries X-Spawnpoint-Signature: t=,v1=<hex HMAC-SHA256 of t + "." + the raw body, keyed with the SPAWNPOINT_RUN_SECRET env var>; the route must recompute it over the raw body (not re-serialized JSON), compare in constant time (crypto.timingSafeEqual, hmac.compare_digest), refuse a t more than 300 seconds from now, and answer 401 otherwise. The body is JSON with run_id, schedule, scheduled_for, and attempt: key the work by scheduled_for, and answer 200 at once for a run_id already done, since a failed run is retried. The first schedule restarts the app once to give it SPAWNPOINT_RUN_SECRET. Setting the same name again changes that schedule; remove_schedule removes one. Plans limit how many schedules a project has, how often they run, and timeout_seconds; a refusal says the limit. Then call run_schedule to try it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "path": "<path>",
      "cron": "<cron>"
    },
    "name": "set_schedule"
  }
}

Input Schema

Name	Required	Description
`cron`	Yes	when, as five cron fields (minute hour day-of-month month day-of-week), such as 0 2 * * * for every day at 02:00, or @hourly, @daily, @weekly
`name`	No	a name for the schedule; defaults to the path. Setting a name again changes that schedule
`path`	Yes	the app's route spawnpoint POSTs to, starting with /, such as /tasks/nightly-export
`paused`	No	true keeps the schedule but stops its runs; setting it again without paused resumes it
`timezone`	No	the IANA timezone the cron is read in, such as Europe/London; UTC when omitted
`project_id`	Yes	the id of the project
`timeout_seconds`	No	how long a run may take before it counts as failed; 60 when omitted, at most 60 on Free and 300 on paid plans

Output Schema

Name	Required	Description	Default
`note`	Yes
`schedule`	Yes
`project_id`	Yes
`secret_env`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds substantial behavior beyond annotations: the first schedule restarts the app to inject SPAWNPOINT_RUN_SECRET, each run is a single POST carrying an HMAC signature header with verification requirements, retries are keyed by scheduled_for so duplicate run_ids must answer 200, and plan limits can refuse creation with a stated reason. Annotations cover only the safety profile (readOnlyHint=false, non-destructive, non-idempotent), so this context is genuinely earned; minor deduction for not clarifying what a partial/failed creation returns.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, but the body is a dense multi-clause run-on covering signature recomputation, constant-time comparison, clock skew, and idempotency keys — much of it operational documentation that could be trimmed for a tool definition. Every point is relevant, but the semicolon-chained structure makes it harder to scan than needed.

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 tool with a side effect (app restart), retry semantics, and plan-gated limits, the description covers everything an agent needs to call it correctly, and an output schema plus annotations already handle return shape and safety hints.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: cron is read in the timezone field (UTC default) with concrete examples, timeout_seconds is bounded by plan, and paused/same-name semantics interact with the update behavior. It does not add formats beyond what the schema examples already give, so it stays below 5.

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?

States a concrete verb and effect: spawnpoint POSTs to a route on a node/python/docker app on a timer, at cron intervals. It also distinguishes itself from in-app timers and names the sibling it works with (run_schedule) and the one that undoes it (remove_schedule).

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

Usage Guidelines5/5

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

Explicit guidance: use it instead of setInterval/node-cron/APScheduler, because those stop while the app sleeps; the workflow (put the job in a POST route, deploy, then call set_schedule) is spelled out. It also says setting the same name again updates that schedule, remove_schedule removes one, and run_schedule tries it out.

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

All spawnpoint tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.