CueFrame

Get Brief

get_brief

Read-onlyIdempotent

Read a brief by id — the persisted intent plus its current quote (compose + estimated render).

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": {
      "briefId": "<briefId>"
    },
    "name": "get_brief"
  }
}

Input Schema

Name	Required	Description	Default
`briefId`	Yes	briefId (path).

Output Schema

Name	Required	Description
`id`	No
`cta`	No
`goal`	No	What the video must accomplish.
`hook`	No
`kind`	No	authored = create_brief; clip = minted by suggest_briefs from an AI clip suggestion.
`name`	No
`tone`	No
`audio`	No
`beats`	No
`gates`	No
`quote`	No
`format`	No
`locale`	No	Output language (BCP-47 tag, e.g. 'es-419'): ALL on-screen copy + captions.
`caption`	No
`audience`	No
`captions`	No
`platform`	No
`createdAt`	No
`projectId`	No
`updatedAt`	No
`exclusions`	No
`references`	No
`durationSec`	No	Target output duration. HONOR-OR-REFUSE: compose validates it against the beat-source window (±1.5s) and refuses a brief it cannot honor.
`motionStyle`	No
`mustIncludes`	No
`seededGraphics`	No	Client-authored graphic clips the Director must carry VERBATIM: seeded into the design loop's base composition as LOCKED clips (never re-authored, never discarded).
`sourceSuggestionId`	No	kind:'clip' provenance — the suggestion this Brief was minted from.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026
- removedOutput schema / properties / format / description
```
Removed value: -"Output-format spec per §Format."
```
First observedOct 10, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that the response bundles the persisted intent with a current quote (compose + estimated render), which is useful behavioral context about how fresh/derived the returned data is. It does not say whether the quote is recomputed on read or cached, which is the main open question for a read tool with derived content.

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?

A single sentence with zero filler; the verb and resource lead, and the parenthetical clarifying the payload comes last. Nothing to trim.

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?

With an output schema present, the description needn't enumerate return fields, and it still summarizes the payload shape. One parameter, rich annotations, and a clear scope make this largely self-sufficient; only the not-found/error behavior is unaddressed.

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 100% for the single briefId parameter (documented as a path parameter), so the schema carries the burden and baseline 3 applies. The description's 'by id' adds no format, sourcing, or failure semantics (e.g. what happens on an unknown id) beyond what the schema states.

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?

States a specific verb (read) and resource (a brief by id), and clarifies what the payload contains: persisted intent plus its current quote (compose + estimated render). That is far more telling than a bare 'Get Brief'. It does not explicitly contrast with list_briefs or get_composition, so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Read a brief by id' implies the single-record lookup case, which implicitly separates it from list_briefs. But there is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative for retrieving composition-level detail (e.g. get_composition).

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

All CueFrame 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.