PilotControl

Crear y publicar carrusel

create_and_publish_carousel

DestructiveIdempotent

Recibe las imágenes o videos y envía el carrusel a publicar en todos los destinos elegidos en una sola acción; si scheduled_for tiene fecha futura, lo programa. Úsala únicamente cuando el usuario pidió publicar o programar imágenes nuevas, con marca, redes y texto acordados. Los archivos deben ser imágenes JPG/PNG o videos MP4/MOV de esta conversación, en orden; si hay videos, los destinos deben ser solo Instagram. no rutas del entorno de código. Usa cuentas compatibles de list_accounts y captions propios por red si se solicitaron. Requiere permiso tanto para guardar imágenes como para publicar. Conserva operation_id al consultar o recuperar el mismo pedido; no cambies el identificador ante un resultado incierto. PUBLISHING significa que el envío está en curso: consulta get_post para confirmar cada destino y sus enlaces; no lo anuncies como publicado hasta confirmarlo. Respeta las confirmaciones y controles del cliente. Para un carrusel ya guardado usa publish_carousel; para guardar sin publicar usa create_carousel_draft.

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_and_publish_carousel"
  }
}

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.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, and the description adds genuinely incremental behavior: dual permission requirements (save images + publish), the meaning of the PUBLISHING state and the instruction to confirm each destination via get_post before announcing success, and operation_id retention on uncertain outcomes. It stops short of describing partial-failure behavior or what a destructive publish actually overwrites, which is the one remaining gap for a write tool.

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?

Front-loaded with the core action and packed with operative constraints rather than filler, so nearly every clause earns its place. Readability suffers from long semicolon-chained sentences that mix preconditions, format rules and post-publish verification into single blocks, which makes it denser than it needs to be.

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

Completeness4/5

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

Return values need not be explained because an output schema exists, yet the description still covers the async PUBLISHING state and how to confirm it, plus permissions and operation_id handling. For a 7-parameter, multi-destination publishing tool the coverage is close to complete; only failure/rollback semantics and array size limits are absent.

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?

With only 29% schema description coverage, the description carries real weight: file format/ordering and origin ('this conversation', not code paths), the Instagram-only constraint when videos are present, caption-per-network only when the user requested distinct texts (and that title/description are the fallback), accounts from list_accounts, and operation_id stability. It leaves title's relationship to caption only implicitly covered and says nothing about the files/targets cardinality limits, so it does not fully compensate for the coverage 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?

Opens with a specific verb+resource+scope: receive images/videos and send the carousel to publish across all chosen destinations in one action, with scheduling when scheduled_for is future. It is immediately distinguishable from create_carousel_draft (save without publishing) and publish_carousel (already-saved carousel), which the closing sentence makes explicit.

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?

States an explicit when-to-use condition (only when the user asked to publish or schedule new images with brand, networks and text already agreed) and names two alternatives with the condition that selects each. It also gives negative constraints (no local code paths; video means Instagram-only targets), which is stronger than typical routing guidance.

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?