Skip to main content
Glama

Tillpad

by com.cnrcode
OverviewDiscussionsAdmin

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, pause with disabled_reason=no_active_plan when the account lapses (resumes on plan activation). 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

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.
includeExcerptNoFor action=runs only: when true, include responseExcerpt (up to 4KB). Default false so list stays small. Ignored by other actions.
intervalMinutesNoMinutes between runs. Required for action=create. Minimum 5. Ignored by other actions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / includeExcerpt
      Added value: +{
+  "description": "For action=runs only: when true, include responseExcerpt (up to 4KB). Default false so list stays small. Ignored by other actions.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.5/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: it discloses metering (create does not meter, later attempts meter outbound_http, success actions meter kvp_ops/rag_index/outbound_http), the delivery contract (10s timeout, 3 attempts, exponential backoff capped at 300s, 2xx success, auto-disable after 5 consecutive exhausted failures), lapse behavior with disabled_reason=no_active_plan, and that delete retains the row. These are exactly the side effects and constraints an agent needs before mutating state.

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?

The purpose is front-loaded and nearly every clause carries operational information, but the delivery-contract details interrupt the action enumeration in the middle of the paragraph, so create/list/get/delete/runs are not presented in one clean block. Slightly reordering would improve scanability without losing content.

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 17-parameter tool with no annotations and no output schema, the description covers actions, permissions, metering, failure/lapse behavior, and delete semantics. Return values are only summarized ('returns schedules', 'returns one schedule and the contract'), so an agent still does not know the field shape of a schedule or run record, which keeps this from a 5.

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 100%, so the baseline is 3; the description adds meaning beyond the schema by tying action values to ACLs and metering, defining the delivery contract that governs intervalMinutes and retry semantics, and clarifying that delete only disables future runs. It does not explain the onFailure/onSuccess object shapes beyond pointing at the schema, but the added contract context is substantive.

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 description opens with a specific verb+resource ('Account HTTPS interval jobs') and then enumerates every action (create/list/get/delete/runs) with what each writes or returns, plus the ACL each checks. An agent can distinguish this from siblings like get_usage or manage_inbox without opening the schema.

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?

The action-by-action breakdown effectively tells the agent which mode to pick, and it explicitly routes the related-but-different need ('Use get_usage to see outbound_http remaining'). What is missing is a clear when-not-to-use statement or named alternative for scheduling itself, but the context is otherwise unambiguous.

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

All Tillpad toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources