Skip to main content
Glama

Get Generation Plan Brief

generation_plan_brief
Read-onlyIdempotent

Read a generation brief from rawPrompt. Source-video edits return execution for generation_video_create with required assets and transformation controls. New scenes return an authoring grammar and planJsonSchema for generation_plan_validate. This read does not generate media or spend credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
genreNoGenre pack id (e.g. pixar-culture-skit). The brief lists available ids in availableGenres; the pack's beats and visual contract override the generic grammar.
rawPromptNoOriginal request. Clone or character-replacement requests select a video transformation brief instead of a new-story plan.
aspectRatioNo9:16
visualStyleNoVisual style preset id; its locked style contract is included in the brief.
videoModelIdNoTarget video model id (see generation_options_list, kind: video). Defaults to the strongest single-take model.
targetDurationSecondsNoDesired final video duration in seconds.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / rawPrompt
      Added value: +{
      +  "description": "Original request. Clone or character-replacement requests select a video transformation brief instead of a new-story plan.",
      +  "maxLength": 5000,
      +  "type": "string"
      +}
    • addedOutput schema / properties / brief / properties / execution
      Added value: +{
      +  "description": "Source-video operation, model and required assets; null for new-story plans.",
      +  "type": [
      +    "object",
      +    "null"
      +  ]
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / genre
      Added value: +{
      +  "description": "Genre pack id (e.g. pixar-culture-skit). The brief lists available ids in availableGenres; the pack's beats and visual contract override the generic grammar.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / brief / properties / availableGenres
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / brief / properties / genrePack
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already mark the tool read-only, idempotent, and non-destructive, so the description's main added value is the credit note and the branch-specific output behavior. This is useful context beyond the structured hints, though it doesn't cover topics like rate limits or auth.

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?

Three sentences with no fluff. The primary action is front-loaded, followed by the two branch behaviors and the safety/cost note. Every sentence 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?

With an output schema and strong annotations present, the description covers the essential triggers, branch outputs, and downstream tool targets. An agent has enough to call the tool correctly without ambiguity.

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?

Schema description coverage is high (83%), so the baseline is 3. The description adds the conceptual distinction between source-video edits and new scenes, but the input schema already explains the rawPrompt behavior and other parameters. The description doesn't need to compensate.

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 opens with a clear verb-resource pair: 'Read a generation brief from rawPrompt.' It then distinguishes two output branches — source-video edits vs new scenes — and names the downstream tools each brief feeds. This clearly separates it from siblings like generation_video_create and generation_plan_validate.

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?

The branching logic tells an agent what kind of brief to expect and which follow-up tool to invoke, and the statement 'does not generate media or spend credits' distinguishes it from generation tools. It stops short of an explicit 'use this when...' rule, but the context is clear enough.

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