Fetch Hive

Schedule a workflow

set_schedule

Destructive

Run a deployed workflow on a schedule (pass workflow_id), or change a schedule (pass schedule_id). Deploy the workflow first with deploy_workflow. A new repeating schedule starts off, runs once straight away as a test, and switches on by itself when the test succeeds. Scheduled runs cost money, so call it first without approved to get the times and the cost per run, tell the person, and call again with approved: true only after they say yes. No cron: use recurrence.

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": "set_schedule"
  }
}

Input Schema

Name	Required	Description
`name`	No
`approved`	No	true only after the person has agreed to the schedule and its cost.
`timezone`	No	IANA name, e.g. Europe/London. Default: the account's timezone.
`recurrence`	No	unit day: interval, time_of_day. week: interval, time_of_day, weekdays. month: interval, time_of_day, day_of_month (1-31 or "last"). hour or minute (at least 5): interval, time_of_day (the start). once: run_at.
`schedule_id`	No	The schedule to change (from list_schedules).
`workflow_id`	No	The deployed workflow to schedule (for a new schedule).
`input_values`	No	Start input values for every scheduled run, keyed by input name.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the supplied annotations (destructiveHint, openWorldHint, non-idempotent). It discloses that a new repeating schedule is created disabled, performs an immediate test run, and self-enables on success, plus that runs incur cost and require human approval. Those lifecycle and billing behaviors are not inferable from annotations or schema.

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-loads the two operating modes, then prerequisites, then the cost/approval protocol. Dense but nearly every clause is load-bearing; a couple of sentences chain several ideas together and could be split for faster parsing.

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?

With no output schema, the description still tells the agent what the unapproved call returns (the run times and cost per run) and what happens after approval. For a destructive, open-world mutation with nested recurrence parameters, the description covers the lifecycle, the cost gate, and the scheduling model.

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 high (86%), so the baseline is 3, and the description adds meaning on top: workflow_id versus schedule_id are framed as mutually exclusive modes, approved is tied to the cost-confirmation step, and recurrence is asserted as the cron replacement. It does not explain input_values or the recurrence sub-fields, which the schema already handles.

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 specific verb and resource and explicitly splits the two modes by parameter: workflow_id for a new schedule, schedule_id for a change. That routing means an agent can pick the correct mode without opening the schema or consulting siblings.

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?

Gives a prerequisite (deploy_workflow first), a mandatory two-step approval protocol (call without approved, report times and cost, then call again with approved: true), and an explicit exclusion ("No cron: use recurrence"). When-to-use and when-not-to-use are both spelled out.

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

All Fetch Hive 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.

Resources

Need Help?