Skip to main content
Glama

Save Autopilot settings

soclo_autopilot_save
DestructiveIdempotent

Save explicit Autopilot settings (schedule, recipe, limits, approval choices). Read soclo_autopilot_read first, pass its exact expectedUpdatedAt (null for absent), a stable UUID clientRequestId and only the approved patch. First call without confirm:true returns a preview; confirm:true with the same patch saves. First setup saves an inactive manual/paused row. A recipe change needs directionScope and is saved separately from other settings. Selected-video budget changes may require pausing, saving and requoting first. Saving is free and never requires an available quote, subscription or credits; each paid operation still requires current pricing and available wallet credits. Starts no run; future scheduled work follows saved settings. Existing plan and Ads Watch billing are preserved. Needs manage:autopilot. The app table has no durable request-ID ledger: after uncertainty, read current state and reconcile the exact original intent instead of retrying automatically.

Input Schema

NameRequiredDescriptionDefault
patchYes
confirmNo
directionScopeNo
clientRequestIdNo
expectedUpdatedAtYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • addedInput schema / definitions
      Added value: +{
      +  "s1": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "override": {
      +        "enum": [
      +          "manual",
      +          "assist",
      +          "autopilot"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  }
      +}
    • addedInput schema / properties / patch / properties / domains / properties / ads / $ref
      Added value: +"#/definitions/s1"
    • removedInput schema / properties / patch / properties / domains / properties / ads / additionalProperties
      Removed value: -false
    • removedInput schema / properties / patch / properties / domains / properties / ads / properties
      Removed value: -{
      -  "override": {
      -    "enum": [
      -      "manual",
      -      "assist",
      -      "autopilot"
      -    ],
      -    "type": "string"
      -  }
      -}
    • removedInput schema / properties / patch / properties / domains / properties / ads / type
      Removed value: -"object"
    • addedInput schema / properties / patch / properties / domains / properties / growth / $ref
      Added value: +"#/definitions/s1"
    • removedInput schema / properties / patch / properties / domains / properties / growth / additionalProperties
      Removed value: -false
    • removedInput schema / properties / patch / properties / domains / properties / growth / properties
      Removed value: -{
      -  "override": {
      -    "enum": [
      -      "manual",
      -      "assist",
      -      "autopilot"
      -    ],
      -    "type": "string"
      -  }
      -}
    • removedInput schema / properties / patch / properties / domains / properties / growth / type
      Removed value: -"object"
    • addedInput schema / properties / patch / properties / domains / properties / posting / $ref
      Added value: +"#/definitions/s1"
    • removedInput schema / properties / patch / properties / domains / properties / posting / additionalProperties
      Removed value: -false
    • removedInput schema / properties / patch / properties / domains / properties / posting / properties
      Removed value: -{
      -  "override": {
      -    "enum": [
      -      "manual",
      -      "assist",
      -      "autopilot"
      -    ],
      -    "type": "string"
      -  }
      -}
    • removedInput schema / properties / patch / properties / domains / properties / posting / type
      Removed value: -"object"
  2. Changed5 schema fields changed
    • addedInput schema / properties / patch / properties / guardrails / properties / allowMotionEffects
      Added value: +{
      +  "type": "boolean"
      +}
    • removedInput schema / properties / patch / properties / guardrails / properties / dailyCreditCap
      Removed value: -{
      -  "maximum": 2147483647,
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • removedInput schema / properties / patch / properties / guardrails / properties / monthlyCreditCap
      Removed value: -{
      -  "maximum": 2147483647,
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • addedInput schema / properties / patch / properties / guardrails / properties / recipe / properties / cadenceStartDay
      Added value: +{
      +  "maximum": 6,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / patch / properties / guardrails / properties / recipe / properties / captionsPerWeek
      Added value: +{
      +  "maximum": 2147483647,
      +  "minimum": 0,
      +  "type": "integer"
      +}
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses many key behaviors: preview-versus-save semantics, first setup creating an inactive manual/paused row, separate handling of recipe changes, preservation of existing plan and Ads Watch billing, no run being started, required manage:autopilot permission, and the absence of a durable request-ID ledger. These are exactly the kind of operational details an agent needs before invoking a destructive mutation.

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 dense but appropriately sized for a complex mutation with nested settings. It is front-loaded with the action and workflow, then adds conditional, billing, permission, and recovery details, each of which earns its place.

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?

Given the nested schema, lack of output schema, and destructive/idempotent annotations, the description is complete enough to call safely. It covers prerequisites, preview/confirm flow, side effects, billing implications, permissions, and recovery after uncertainty.

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 0%, so the description must carry parameter meaning, and it does for the top-level parameters: expectedUpdatedAt must come from soclo_autopilot_read, null means absent, clientRequestId must be a stable UUID, confirm controls preview versus save, and directionScope is required for recipe changes. It does not explain every nested patch field, but it supplies the critical invocation semantics beyond the schemas.

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 a specific verb and resource: 'Save explicit Autopilot settings (schedule, recipe, limits, approval choices).' It also distinguishes the operation from reading by naming soclo_autopilot_read and from running by stating 'Starts no run.' This is enough for an agent to identify the tool’s role 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 Guidelines5/5

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

It gives an explicit workflow: read soclo_autopilot_read first, pass the exact expectedUpdatedAt, call without confirm for a preview, then call with confirm:true to save. It also names conditional cases such as recipe changes requiring directionScope and selected-video budget changes potentially requiring pause/save/requote first.

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.

Resources