Skip to main content
Glama

server_create_task

Schedule automated tasks for Minecraft servers using interval-based or cron-based timing. Configure commands, backups, restarts, starts, or stops to run at specified times.

Instructions

Create a scheduled task for a Minecraft server. Use interval_type with interval for simple schedules (e.g., every 6 hours), or set cron_string with empty interval_type for cron-based schedules (e.g., '0 3 * * *' for 3 AM daily).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
server_idYesServer ID or UUID
nameYesTask name
enabledNoWhether the task is active
actionYesAction type: command, backup, restart, start, stop
action_idNoID of the action target, if applicable
intervalNoInterval number (used with interval_type)
interval_typeNoInterval unit. Use empty string with cron_string for cron schedules.hours
start_timeNoStart time in HH:MM format
commandNoCommand to run (for command action type)
one_timeNoRun once then delete
cron_stringNoCron expression (e.g. '0 3 * * *'). Use with interval_type=''.
delayNoDelay in seconds before running

Implementation Reference

  • The tool `server_create_task` is registered and implemented in this block, using `server.tool` to define the input schema via zod and the handler function to POST the task data to the Crafty server API.
    server.tool(
      "server_create_task",
      "Create a scheduled task for a Minecraft server. Use interval_type with interval for simple schedules (e.g., every 6 hours), or set cron_string with empty interval_type for cron-based schedules (e.g., '0 3 * * *' for 3 AM daily).",
      {
        server_id: z.string().describe("Server ID or UUID"),
        name: z.string().describe("Task name"),
        enabled: z.boolean().default(true).describe("Whether the task is active"),
        action: z
          .string()
          .describe("Action type: command, backup, restart, start, stop"),
        action_id: z.string().optional().describe("ID of the action target, if applicable"),
        interval: z.number().default(1).describe("Interval number (used with interval_type)"),
        interval_type: z
          .enum(["hours", "minutes", "days", "reaction", ""])
          .default("hours")
          .describe("Interval unit. Use empty string with cron_string for cron schedules."),
        start_time: z.string().optional().describe("Start time in HH:MM format"),
        command: z
          .string()
          .optional()
          .describe("Command to run (for command action type)"),
        one_time: z.boolean().default(false).describe("Run once then delete"),
        cron_string: z
          .string()
          .optional()
          .describe("Cron expression (e.g. '0 3 * * *'). Use with interval_type=''."),
        delay: z.number().default(0).describe("Delay in seconds before running"),
      },
      async ({ server_id, ...taskData }) => {
        try {
          const data = await client.post(`/servers/${server_id}/tasks`, taskData);
          return { content: [{ type: "text", text: JSON.stringify(data, null, 2) }] };
        } catch (error) {
          const msg = error instanceof Error ? error.message : String(error);
          return { content: [{ type: "text", text: `Error: ${msg}` }], isError: true };
        }
      }
    );
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the scheduling behavior (interval vs cron) which is valuable, but doesn't mention permissions needed, whether tasks persist across server restarts, error conditions, or what happens on creation success/failure. For a creation tool with 12 parameters and no annotations, more behavioral context would be helpful.

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?

Two tightly focused sentences with zero waste. The first establishes purpose, the second provides critical usage guidance with concrete examples. Every word earns its place, and the most important information (the two scheduling approaches) is front-loaded.

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

Completeness3/5

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

For a creation tool with 12 parameters, no annotations, and no output schema, the description does well on scheduling mechanics but leaves gaps. It doesn't cover what the tool returns, error conditions, permissions required, or how the task integrates with the server system. The parameter guidance is strong, but broader context is missing.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the relationship between interval_type, interval, and cron_string parameters - specifically that interval_type should be empty string when using cron_string. This clarifies parameter interdependencies that aren't obvious from the schema alone.

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 clearly states the specific action ('Create a scheduled task') and resource ('for a Minecraft server'), distinguishing it from sibling tools like server_run_task (executes immediately) and server_delete_task (removes tasks). It provides concrete purpose beyond just the tool name.

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?

The description explicitly provides when-to-use guidance by explaining the two scheduling approaches: 'Use interval_type with interval for simple schedules' and 'set cron_string with empty interval_type for cron-based schedules'. It gives concrete examples (e.g., 'every 6 hours', '0 3 * * * for 3 AM daily') that help the agent choose between parameter combinations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HadiCherkaoui/crafty-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server