Skip to main content
Glama

Draft a new creative direction

redraft_video_direction
Destructive

Draft the next video's direction through an external AI service: with none and no idea yet, from one of the product's ideas we choose; else another take in its format. It overwrites edits: confirm first. Poll get_product.

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": {
      "product_id": "<product_id>"
    },
    "name": "redraft_video_direction"
  }
}

Input Schema

NameRequiredDescriptionDefault
product_idYesThe product's id.

Output Schema

NameRequiredDescriptionDefault
ratioNo
formatNo
draftingYes
editableYes
next_stepYes
affordableNo
product_idYes
resolutionNo
credit_costYes
draft_errorNo
creator_noteNo
draft_failedYes
target_marketNo
style_picturesNo
duration_secondsNo
look_descriptionNoWhat the user's style pictures show, in words they can edit on the website: the setting, light, palette, mood and presenter the video takes its look from. Never a product.
opened_new_videoYes
video_request_idYes
creative_directionNo
selected_image_idsYes
style_picture_urlsNoThe style pictures, never filmed; each link lasts an hour.
watermark_expectedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true; the description goes beyond them by naming the external AI service, warning that it 'overwrites edits: confirm first', and telling the agent to poll `get_product` because the operation is asynchronous. This is genuinely additive context, though it says nothing about failure handling or expected latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the purpose, and the overwrite/poll warnings do earn their place. However, the middle clause about ideas is syntactically tangled and forces a re-read to parse the three branching cases.

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 an output schema present and annotations covering the safety profile, the description supplies exactly the missing pieces: external-service dependency, destructiveness of overwriting prior edits, and the need to poll `get_product` for the result. Nothing essential to calling it correctly is omitted.

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

Parameters3/5

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

There is a single required parameter with 100% schema description coverage, so the schema already documents it. The description contributes no extra meaning about product_id or what an invalid id does, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Draft' plus the resource 'the next video's direction' gives a clear action and target, and the mention of 'another take in its format' hints at regeneration. It does not explicitly differentiate itself from the sibling update_video_direction, so an agent must infer that this creates a fresh draft while the sibling edits an existing one.

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?

Three input situations are enumerated (nothing yet, choose from the product's existing ideas, otherwise another take in the same format), plus an instruction to poll `get_product` afterward. The branching is stated but garbled ('with none and no idea yet, from one of the product's ideas we choose'), and no alternative tool is named for the edit case.

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.