Skip to main content
Glama

manage_schedule

Account HTTPS interval jobs. action=create writes a schedule and returns it plus the delivery contract (ACL schedule_create). Requires an active plan. This call does not meter. Each later attempt meters outbound_http. Success actions store_kvp meter kvp_ops, store_rag meters rag_index, and notify_webhook meters another outbound_http. Contract: 10 second timeout, up to 3 attempts, exponential backoff capped at 300 seconds, success is HTTP 2xx, auto-disable after 5 consecutive exhausted failures. Minimum interval is 5 minutes. action=list returns schedules (ACL schedule_list). action=get returns one schedule and the contract (ACL schedule_get). action=delete sets enabled off and disabled_reason deleted, which stops future runs and keeps the row (ACL schedule_delete). action=runs lists attempts (ACL schedule_runs_list). No email from this call. Use get_usage to see outbound_http remaining.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS URL to call. Required for action=create. Omit otherwise.
nameNoDisplay name for action=create, up to 120 characters. Default empty. Ignored by other actions.
limitNoPage size for action=runs. Default 50, maximum 100. Ignored by create, list, get, and delete.
actionYescreate checks ACL schedule_create and writes a schedule. list checks schedule_list. get checks schedule_get. delete checks schedule_delete and disables future runs. runs checks schedule_runs_list. Required. No default.
methodNoHTTP method for action=create. Default GET. POST may send bodyTemplate. Ignored by other actions.
offsetNoRow offset for action=runs. Default 0. Ignored by create, list, get, and delete.
statusNoFilter for action=runs. failed means retries are exhausted. Omit for every status. Ignored by other actions.
authModeNoHow action=create authenticates the outbound call. Default none. bearer and header require authSecret. Ignored by other actions.
timezoneNoTimezone label stored on the schedule. Default UTC. Used when action=create. Ignored by other actions.
onFailureNoActions after retries are exhausted, for action=create. Same object shapes as onSuccess. Omit for none.
onSuccessNoActions after a 2xx response, for action=create. Each item is {type:store_kvp, namespace, key}, {type:store_rag, namespace}, or {type:notify_webhook, url}. Omit for none. store_kvp meters kvp_ops, store_rag meters rag_index, notify_webhook meters outbound_http when the run happens.
authSecretNoSecret for authMode=bearer or header on action=create. Stored encrypted. Required for those modes. Omit for authMode=none.
scheduleIdNoSchedule id. Required for get and delete. Optional filter for runs. Omit for create and list.
bodyTemplateNoPOST body for action=create when method=POST. Omit for an empty body. Ignored for GET and for other actions.
authHeaderNameNoHeader name when authMode=header. Default authorization. Ignored unless action=create and authMode=header.
intervalMinutesNoMinutes between runs. Required for action=create. Minimum 5. Ignored by other actions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: ACL required per action, metering behavior (create does not meter; later attempts meter outbound_http; store_kvp/store_rag/notify_webhook meter specific counters), no email sent, and the full delivery contract (10s timeout, 3 attempts, exponential backoff capped at 300s, HTTP 2xx = success, auto-disable after 5 consecutive exhausted failures). It also discloses that delete is a soft disable that keeps the row.

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?

Dense and front-loaded: the create action and its metering/contract are stated first, followed by the remaining actions in a compact list. The telegraphic style ('This call does not meter', 'No email from this call') is efficient, and every clause conveys distinct behavior, though the length is notable for a single description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter multi-action tool with no output schema and no annotations, the description covers the essential behavior: quota/metering, ACLs per action, delivery contract, and soft-delete semantics. Return values are only lightly implied ('returns it plus the delivery contract'), but create's return contract is described enough to call correctly.

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 description coverage is 100%, so the schema already documents all 16 parameters including per-action applicability and defaults, making 3 the baseline. The description adds only marginal parameter context (metering for onSuccess types, min interval, authSecret storage), largely restating what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The body clearly enumerates the resource (interval HTTPS jobs/schedules) and what each action does — create writes and returns a schedule plus delivery contract, list/get/delete/runs each have defined behavior. The opening fragment 'Account HTTPS interval jobs' is telegraphic, but the per-action verbs and resources make it identifiable. It does not explicitly differentiate itself from siblings like manage_inbox_webhook, only pointing to get_usage for quota.

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

Usage Guidelines3/5

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

It gives per-action conditions (create requires an active plan, min interval 5 minutes, authMode requirements) and routes quota checking to get_usage, which is genuine usage context. However, it never states when to choose this tool over alternatives such as manage_inbox_webhook or index_document for similar outbound/delivery needs, so usage is implied rather than guided.

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.