Skip to main content
Glama

Add a task to a schedule

schedule_task_create

Adds a task to a Pterodactyl server schedule to run commands, send power signals, or trigger backups at defined offsets.

Instructions

Add a task. action is command, power, or backup; payload is the command, power signal, or ignored globs.

Input Schema

NameRequiredDescriptionDefault
panelNoName of a saved panel. Omit to use the active or default panel.
actionYes
serverYes
baseUrlNoInline panel URL override, e.g. https://panel.example.com. Not persisted.
payloadNo
scheduleYes
clientKeyNoInline client API key (ptlc_…) override. Not persisted.
sequence_idNoPosition in the schedule.
time_offsetYesSeconds after the previous task.
applicationKeyNoInline application API key (ptla_…) override. Not persisted.
continue_on_failureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden and does not meet it: it says nothing about permissions needed, ordering/append semantics, what happens on failure (continue_on_failure is unmentioned), or whether the call is idempotent. It only clarifies action/payload value mapping.

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?

Two tight sentences with no filler, and the action/payload mapping is front-loaded immediately after the verb. It is efficient, though its brevity is closer to under-specification than true economy given an 11-param tool.

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

Completeness2/5

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

For an 11-parameter mutation tool with no annotations and no output schema, the description is substantially incomplete — required params like server, schedule, and time_offset and the ordering semantics of sequence_id are never addressed. It explains only the action/payload pairing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does add real value for two undocumented params — action's three modes and payload as "command, power signal, or ignored globs" (payload has no schema description). But with 11 parameters at 55% coverage, it says nothing about server, schedule, time_offset, sequence_id, continue_on_failure, or the inline override params, leaving the majority of the surface unexplained.

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

Purpose3/5

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

"Add a task" gives a verb and object, but it only restates the title and never says the task is appended to an existing schedule — the key distinction from sibling schedule_create. An agent must infer the schedule-create vs schedule-task-create split from names alone.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus schedule_create, schedule_task_update, or schedule_execute, and no prerequisites (e.g., that the target schedule must already exist, or how time_offset/sequence_id order tasks). Usage is only implied by the name.

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