Skip to main content
Glama

Set Plan Schedule

set_plan_schedule

Give a plan a schedule so it fires on its own, change it, or clear it. Pick a cadence: hourly (at minute past each hour), daily (at hour:minute), weekly (also weekday, MON to SUN) or monthly (also day, 1 to 28), in timezone (an IANA name such as America/Los_Angeles; omitted means UTC). Pass cadence 'none' to clear the schedule, after which the plan fires only when somebody fires it. ONCE SET, EVERY FIRING RUNS WITH NOBODY CONFIRMING IT, spending what the plan's steps spend each time, so read the plan with get_plan first. Scheduling needs every permission the plan's steps call, and each firing runs with your permissions as they stand when it fires: if you lose one the steps need, or your access is revoked, the schedule stops and the workspace's admins are told. Only an active plan can be scheduled, and a plan with a create step that refreshes nobody (update_cap 0) is refused. The response says when it fires and which steps ask the provider about their whole scope on every firing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNoDay of the month, 1 to 28. Monthly only.
hourNo0 to 23. Needed for daily, weekly and monthly.
minuteNo0 to 59. Defaults to 0.
cadenceYesHow often it fires, or 'none' to clear the schedule.
plan_idYesThe plan to schedule.
weekdayNoMON, TUE, WED, THU, FRI, SAT or SUN. Weekly only.
timezoneNoAn IANA time zone name, e.g. America/New_York. Omitted means UTC.
connection_idYesThe CRM connection. Call list_crm_connections first.

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?

Dramatically exceeds annotation coverage, which only flags non-read-only and open-world. Discloses that firings run unattended, spend resources each time, require all step permissions, run under the caller's current permissions, stop on permission loss, and notify admins – critical safety context an agent cannot infer from annotations.

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

Conciseness5/5

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

Front-loads the core action, then groups cadence details, clearing behavior, and critical safety warnings in a logical flow. Every sentence carries essential information; no waste despite the length.

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?

Given no output schema exists, the description proactively explains the response ('when it fires and which steps ask the provider about their whole scope'). Covers all necessary prerequisites, failure modes, and side effects for an 8-parameter scheduling mutation.

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?

The schema has 100% description coverage, so baseline is 3. The description adds value by clarifying the IANA timezone default (UTC), the 'none' clear semantics, and the cadence-specific parameters. It doesn't add syntax beyond the schema, but reinforces key defaults and constraints.

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 ('Give a plan a schedule'), and explicitly covers the three operations: set, change, and clear. Clearly distinguishes itself from siblings like fire_plan (manual firing) and get_plan (reading).

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?

Tells the agent exactly when to use this tool with concrete conditions: only active plans can be scheduled, create-step plans refreshing nobody are refused, and it prompts reading the plan first. Also contrasts scheduled firing with manual firing, clarifying the alternative.

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.