ai-content-drop

Add generation card

add_generation_card

Add a draft generation card to a board: a prompt and a model (an id from list_models) that can be rendered later with run_generation_card. Adding it costs nothing; nothing renders until it is run with a quote. Set duration and resolution on the card for a per-second model: the quote for run_generation_card must be taken with them. For a step that builds on an earlier card (a still that becomes a video), pass from_card_id: the new card is connected to that card on the board and, unless it has its own image_url, starts from that card's finished image. SIGN-IN REQUIRED: connect this server with OAuth (the host prompts for it), or add an API key header "Authorization: Bearer acd_live_…" created at https://aicontentdrop.com/settings/integrations.

Input Schema

Name	Required	Description
`kind`	No	Defaults to video.
`model`	No	A model id from list_models.
`width`	No	Optional card width in pixels.
`height`	No	Optional card height in pixels.
`prompt`	No	The generation prompt, up to 4000 characters.
`duration`	No	Optional clip length in seconds, for video models that price by duration.
`position`	No	Optional { x, y } in board pixels. When omitted the server places the card in the first free grid cell.
`revision`	No	The board revision this change is based on (from the last board you saw). Optional: when omitted the tool reads the current one first.
`canvas_id`	Yes	The board id, from list_canvases or create_canvas.
`image_url`	No	Optional public https reference image for image-to-video or image-to-image.
`resolution`	No	Optional, e.g. 720p, 1080p.
`aspect_ratio`	No	Optional, e.g. 9:16, 16:9, 1:1.
`from_card_id`	No	Optional: an image generation card or an image media card on the same board. The new card is connected to it, and its finished image is the new card's start frame when the new card runs (run the source card first).

Output Schema

Name	Required	Description
`card`	Yes
`edge`	No	The connection from from_card_id, when one was given.
`canvas`	Yes
`next_step`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

removedOutput schema / properties / canvas / properties / updated_at

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / properties / canvas / required

Previous value: -[
-  "id",
-  "name",
-  "revision",
-  "card_count",
-  "updated_at",
-  "link",
-  "cards",
-  "edges"
-]New value: +[
+  "id",
+  "name",
+  "revision",
+  "card_count",
+  "link",
+  "cards",
+  "edges"
+]

Changed4 schema fields changedSep 23, 2026

addedInput schema / properties / from_card_id

Added value: +{
+  "description": "Optional: an image generation card or an image media card on the same board. The new card is connected to it, and its finished image is the new card's start frame when the new card runs (run the source card first).",
+  "type": "string"
+}

addedOutput schema / properties / canvas / properties / edges / items / description

Added value: +"A connection drawn from one card to the next: { id, source, target, label? }. data.role start_image means the source card's finished image is the target card's start frame."

addedOutput schema / properties / canvas / properties / edges / items / properties

Added value: +{
+  "id": {
+    "type": "string"
+  },
+  "label": {
+    "description": "Text drawn on the line, when it has one."
+  },
+  "source": {
+    "description": "The card the connection starts from.",
+    "type": "string"
+  },
+  "target": {
+    "description": "The card it leads to.",
+    "type": "string"
+  }
+}

addedOutput schema / properties / edge

Added value: +{
+  "description": "The connection from from_card_id, when one was given.",
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "label": {
+      "description": "Text drawn on the line, when it has one."
+    },
+    "source": {
+      "description": "The card the connection starts from.",
+      "type": "string"
+    },
+    "target": {
+      "description": "The card it leads to.",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

AddedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (not read-only, not destructive, not idempotent). The description adds real behavioral context beyond that: OAuth/API-key auth requirement with a concrete header format, the fact that duration and resolution must match what the quote is taken with, and how from_card_id links cards and seeds the start frame.

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?

The core behavior is front-loaded in the first two sentences and every sentence carries information. The trailing auth block is somewhat bulky and could be tightened, but it is not filler.

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?

With 13 parameters but an output schema present and full schema coverage, the description supplies the missing pieces an agent needs: auth method, cost/render timing, duration-resolution coupling, and the parent-card linkage. Nothing essential for a correct call is 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?

Schema coverage is 100%, so the schema carries the per-parameter baseline. The description still adds meaning the schema lacks: how model ids are obtained, why duration/resolution are coupled to the quote, and the connection/start-frame semantics of from_card_id.

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 ('Add a draft generation card to a board') and immediately clarifies it is a prompt+model pair that is not rendered until run_generation_card. This separates it cleanly from run_generation_card (rendering) and add_media_card (importing media).

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?

Explicitly says adding costs nothing and nothing renders until run with a quote, names run_generation_card as the follow-up and list_models as the source of model ids, and gives the concrete branch condition for from_card_id (building on an earlier card). It covers when to use, what happens next, and the alternative path.

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

All ai-content-drop 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.