PilotControl

Guardar carrusel en PilotControl

create_carousel_draft

Idempotent

Recibe de 2 a 10 imágenes JPG/PNG o videos MP4/MOV creados o adjuntados en ChatGPT, en el orden del array. Si incluye videos, solo admite cuentas de Instagram (hasta 300 MB por video). Cada imagen tiene que ser un archivo de esta conversación (generada con la herramienta de imágenes o adjuntada por el usuario); un archivo creado en el entorno de código (/mnt/data) o un nombre de archivo no sirven: muéstralo como imagen en el chat o pide al usuario que la adjunte. Guarda un borrador en la marca indicada con título, descripción, destinos (de list_accounts) y, si el usuario lo pidió, fecha programada. Si el usuario no da el texto o te pide que lo escribas, míralas y escríbelo tú en su idioma: título corto y claro, descripción con gancho, beneficio, llamada a la acción y pocos hashtags; no preguntes primero. Si una red necesita otro tono o largo, usa caption en ese target. Solo para guardar un borrador por petición del usuario. Si pidió publicar o programar imágenes nuevas, usa create_and_publish_carousel; no termines su orden como borrador. Conserva operation_id al reintentar el mismo pedido.

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": {
      "operation_id": "<operation_id>",
      "title": "<title>",
      "files": "<files>",
      "targets": "<targets>"
    },
    "name": "create_carousel_draft"
  }
}

Input Schema

Name	Required	Description
`files`	Yes
`title`	Yes
`targets`	Yes
`brand_id`	No	ID de la marca (de list_brands). Usa solo la marca que el usuario nombró; si no la nombró y hay varias, pregúntale cuál.
`description`	No
`operation_id`	Yes
`scheduled_for`	No	Fecha y hora ISO 8601 con zona horaria para programar, solo si el usuario la pidió. Se aplica con create_and_publish_carousel, o con publish_carousel para un carrusel ya guardado.

Output Schema

Name	Required	Description	Default
`title`	Yes
`reused`	Yes
`status`	Yes
`post_id`	Yes
`brand_id`	Yes
`description`	Yes
`image_count`	Yes
`scheduled_for`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare the mutation/idempotency profile, but the description adds real behavior: video only supports Instagram accounts with a 300 MB per-video cap, files must originate from this conversation rather than /mnt/data, and brand ambiguity must be resolved with the user. These are operational constraints an agent could not infer from the structured fields.

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?

Every sentence carries operational value, but the whole thing is a single dense block that delays the core 'save a draft' action until the third sentence. It would read better with the save action and its exclusion rule front-loaded ahead of the file-sourcing and copywriting guidance.

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 seven-parameter, nested-file, multi-target mutation tool with an output schema, the description covers sourcing rules, platform limits, brand resolution, copywriting behavior, and the sibling boundary. An agent has everything needed to call this correctly without guessing.

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 low (29%), yet the description compensates for most parameters: the 2-10 file range and accepted formats, targets sourced from list_accounts, per-target caption for differing tone, and scheduled_for only when requested. connection_id and account_id semantics are left to list_accounts, which is a minor residual gap.

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?

States a specific verb and resource ('Guarda un borrador en la marca indicada con título, descripción, destinos...') and constrains the input to 2-10 images or videos in array order. It explicitly separates itself from create_and_publish_carousel, so an agent can route correctly without opening either 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?

Gives explicit when-to-use ('Solo para guardar un borrador por petición del usuario') and when-not-to-use ('Si pidió publicar o programar imágenes nuevas, usa create_and_publish_carousel; no termines su orden como borrador'), naming the alternative tool. It also specifies the retry condition for reusing operation_id.

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

All PilotControl 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?