Skip to main content
Glama

schedule_task

Save a multi-step WORKFLOW (upsert by name) and attach a recurring cron schedule for its delivery.

Use this when the user wants a sequence of platform calls delivered ON A
SCHEDULE / repeatedly (e.g. "every weekday morning pull 8-K releases, screen
for cheap large-caps, and email me the overlaps as a table"). For a ONE-OFF
request, call the corresponding tools directly instead. A request worded as a
"datafeed" / "feed" / recurring file is draft_custom_dataset, not this — even
with summary columns, since stored summaries are ordinary dataset columns.

`steps` (shape in the parameter description): a transform applies its
instruction to the accumulated results of ALL prior steps (e.g. "intersect the
two event sets by symbol and build a table"), and each step's `label` keys its
result. The LAST step's output is what gets delivered, so end table/summary
workflows with a transform.

Allowlisted fetch endpoints (anything else is rejected with a 422 at save
time; `params` takes the same keys as the matching tool):

- POST, JSON-body params: "get-realtime-events" (`list_realtime_events`),
  "list-upcoming-earnings-announcements" (`list_earnings_announcements`),
  "predict-earnings-announcement-move" ({"symbols": [...]}),
  "data-catalogue-exploration" ({"query": "..."}).
- GET, scalar query params only (no lists/dicts): "get-company-snapshot"
  (requires {"symbol": "..."}), "get-strategy-performance-summary",
  "get-strategy-track-record", "get-strategy-swaps", "get-stock-picks",
  "list-tickers", "list-realtime-event-options", "get-sectors",
  "get-sub-industries".
- EXPENSIVE — max 2 per workflow, and the cron must use a literal minute and
  at most 4 literal hours (no sub-hourly / "*" fields): "screen-stocks"
  (`screen_stocks`), "generate-research-report" ({"query": "..."}),
  "create-full-report" (writes a new note every run, a few minutes, replacing
  the symbol's report; {"ticker": "..."} for the standard note;
  add "user_override": true plus the shaping lists `generate_report_for_stock`
  takes — financial_items, ratios, as_reported_financial_items, revenue_segment,
  technical_analysis_items, estimate_items, institutional_ownership CIKs — for a
  custom one; the backend rejects the lists without the switch),
  "optimize-symbols", "optimize-portfolio", "list-optimized-stock-picks".

Each user may hold at most 10 active schedules.

Returns `status` 201 (created) or 200 (updated) with `workflow_id` and
`task_name` ("wf:{email}:{name}"), the key that `list_scheduled_tasks` shows
and `delete_scheduled_task` takes.

Input Schema

NameRequiredDescriptionDefault
nameYesLowercase slug and upsert key (no spaces, colons, or uppercase); re-saving the same name updates the workflow and re-attaches its schedule.
stepsYesOrdered 1-8 steps; the first must be a fetch. Fetch: {"kind": "fetch", "endpoint": "<allowlisted kebab-case path, no leading slash>", "params": {...}, "label": "..."}. Transform: {"kind": "transform", "instruction": "<=2000 chars, applied to all prior results>", "label": "..."}. `label` is an optional unique lowercase slug (default step_{i}). The last step's output is delivered.
deliveryNoWhere each run's output goes.email
descriptionNoOptional human-readable note saved with the workflow.
regular_cronYesRaw 5-field cron expression for when the workflow fires, e.g. "30 6 * * 1-5" (weekdays 06:30); validated server-side.

Output Schema

NameRequiredDescriptionDefault
cronNoThe cron expression attached.
nameNoThe workflow name (upsert key).
statusNo201 when the workflow was created, 200 when an existing one was updated.
scheduledNo
task_nameYes"wf:{email}:{name}" — the key list_scheduled_tasks shows and delete_scheduled_task takes.
workflow_idNoId of the saved workflow definition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the safety profile (mutation, non-destructive), while the description adds substantial undisclosed behavior: 422 rejection of non-allowlisted endpoints, expensive-endpoint caps of max 2 per workflow with cron minute/hour restrictions, the 10-active-schedules-per-user quota, upsert semantics under the same name, and the 201-vs-200 status distinction with workflow_id/task_name. This is exactly the extra context annotations cannot 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 purpose, then usage, then data-shape detail and a bulleted endpoint allowlist — every section serves a decision the agent must make. It is long, and the deeply nested create-full-report parenthetical is heavier than strictly necessary, but the bulk is load-bearing allowlist/limit information found nowhere else.

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 high-complexity scheduling tool with free-form nested steps, the description supplies the allowlist, quotas, cron limits, and step semantics. An output schema exists, yet the description still names workflow_id/task_name as the keys that list_scheduled_tasks and delete_scheduled_task consume, closing the follow-up loop.

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?

Schema coverage is 100%, but the description adds meaning the schema structurally cannot: steps items are free-form objects, so the allowlisted endpoint vocabulary, per-endpoint param keys, and transform-accumulation semantics ('applies to accumulated results of ALL prior steps', last step's output delivered) are only documented here. It also ties name to upsert behavior and constrains regular_cron beyond the schema's 'validated server-side'.

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?

The first sentence gives a precise verb (save/upsert by name) plus a compound resource (multi-step workflow + recurring cron schedule). It immediately distinguishes itself from the sibling draft_custom_dataset by naming that tool as the wrong path for 'datafeed'/'feed' requests.

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 when-to-use (repeated delivery of a sequence of platform calls), explicit when-not (ONE-OFF requests should call the tools directly), and an explicit alternative for a confusable request shape (draft_custom_dataset, even with summary columns). Sibling routing is fully resolved.

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.

Resources