Xyla AI

Turn autopilot on or off

set_autopilot

Destructive

Turns Xyla autopilot on or off for this shop. With autopilot on, Xyla makes and schedules posts by itself. mode include (the default) keeps posts already made and adds them to the schedule. mode fresh DELETES every post not yet scheduled, including posts the merchant made by hand, then builds a new schedule: call it first without confirm_delete_count to get the number of posts it deletes, tell the merchant, and only after they agree call again with confirm_delete_count set to that number. Turning autopilot off unschedules upcoming posts and deletes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "on": "<on>"
    },
    "name": "set_autopilot"
  }
}

Input Schema

Name	Required	Description	Default
`on`	Yes	true turns autopilot on, false turns it off.
`mode`	No	Only when turning on. include keeps existing posts; fresh deletes unscheduled posts first.	include
`confirm_delete_count`	No	Fresh mode only: the number of posts to delete, from the previous set_autopilot reply, after the merchant agreed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already mark this as destructive and non-idempotent, and the description adds critical specifics: fresh mode deletes every unscheduled post including hand-made ones, requires a two-step confirm_delete_count workflow, and turning autopilot off unschedules upcoming posts without deleting anything. This is exactly the behavioral context an agent needs beyond 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?

The description is front-loaded with the main action, then covers modes, the destructive confirmation workflow, and the off behavior. Every sentence carries operational weight, and the structure follows the decision order an agent would need.

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?

For a destructive mutation tool with no output schema and low-complexity parameters, the description supplies the missing safety and workflow context. It explains on/off behavior, mode semantics, deletion scope, and the confirmation protocol, making the definition sufficiently complete.

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

Parameters5/5

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

Although the schema has 100% parameter description coverage, the description adds meaningful semantics beyond it: it clarifies the real consequence of fresh mode, the reason confirm_delete_count exists, and the required two-call sequence for safely using it. This enriches parameter meaning rather than merely repeating the schema.

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 states the exact verb and resource: turns Xyla autopilot on or off for this shop. It explains the direct consequence of autopilot being on, so the agent can distinguish this tool from neighboring settings and post-management tools 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?

It clearly explains the two modes, when to use fresh versus include, and the mandatory confirmation workflow before destructive deletion. It does not explicitly name an alternative sibling tool, but the context for selecting each mode is strong.

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

All Xyla AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?