Skip to main content
Glama

Run schedule

run_schedule

Run one of a project's schedules now, to test its route, and wait for the answer: status ok (the route answered 2xx) or failed, with http_status, what the app answered (response), and error_explained in plain words. It wakes the app first if it sleeps. A test run is never retried and does not count toward the failure email. While a run of that schedule is going, it reports that run instead of starting another. A 401 means the route's signature check does not match: it must compute HMAC-SHA256 over t + "." + the raw body with SPAWNPOINT_RUN_SECRET. A 404 means the app has no such route.

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>",
      "name": "<name>"
    },
    "name": "run_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesthe schedule's name (its path when it was set without one)
project_idYesthe id of the project

Output Schema

NameRequiredDescriptionDefault
noteNo
wokeYes
run_idYes
statusYes
responseNo
duration_msNo
http_statusNo
error_explainedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Far beyond the annotations: it discloses that the app is woken first, that test runs are never retried and don't count toward the failure email, that concurrent invocations return the in-flight run, and what the returned status/http_status/response/error_explained fields mean. The 401 HMAC-SHA256 signing recipe and 404 route-missing semantics are exactly the kind of failure-mode context the annotations can't carry.

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?

Front-loaded with the action and result, then failure modes in a logical order (401 signature, 404 route). It is dense — a long multi-clause paragraph — but nearly every clause carries operational information; only the HMAC recipe borders on over-detail.

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 two-parameter trigger tool with an output schema, the description covers the invocation contract, blocking behavior, concurrency, side effects on alerting, and the two most likely failure codes. Nothing material an agent needs before calling it is missing.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description only loosely reinforces them ("one of a project's schedules", "its route"), adding no format or edge-case detail such as name resolution rules beyond what the schema states.

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?

Opens with a specific verb+resource+mode: "Run one of a project's schedules now, to test its route, and wait for the answer." That clearly separates it from set_schedule (create/edit) and remove_schedule, and it states the blocking/waiting contract up front.

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?

It gives a clear motivating context (test the route, wait for the result) and a concurrency rule (a run already in progress is reported instead of starting another). It doesn't explicitly name a sibling to use instead for other cases, but the test-oriented framing leaves little ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.