Director's Lookbook

Compile a brief

brief

Read-onlyIdempotent

Turn card ids into paste-ready prompt blocks, worded verbatim from the cards: IMAGE PROMPT, VIDEO PROMPT, PALETTE (hexes), TYPE, SUNO STYLE and SUNO EXCLUDE, SITE PROMPT, or for job game: KEY ART, CAPSULE, SPRITE/TILESET, UI MOCKUP, MUSIC; for job drama: SHOT blocks for the hook, twist and payoff plus BEATS (timing, shot, what happens, a placeholder line with its length rule), END CARD (title, promise, call to action, set in the type card), CAPTION RULES (safe band y 210 to 1345 on 1080x1920, nothing in the bottom 30%) and DON'T. Pass the ids from deal_hand (or find_styles), at most one card per suit, except camera: several camera cards make a shot list (one SHOT block each). A camera card of kind light lights every shot; a film card of kind fx adds a post effect. tool respells the blocks: midjourney (--ar, --style raw, --sref with the film card's example image), runway or kling (camera line first, 5 or 10 s clips), suno (music blocks only). seconds splits a running time over the shots, beats says what happens in each, vocals picks lyrics or instrumental. A lens card in a shot list shapes every shot. Example: {"hand_ids": ["film-gold-200", "camera-closeup", "color-golden-hour"], "job": "photo", "subject": "an older woman teaching a young man to dance", "tool": "midjourney"}. Drama example: {"hand_ids": ["type-futura", "film-vision3-500t", "color-blue-hour", "camera-closeup", "camera-pull", "camera-push"], "job": "drama", "subject": "a meal-kit app", "feeling": "a quiet breakup at a dinner table", "title": "Dinner for Two", "seconds": 30}. Also returns the don't-list, tone words, deliverables, lint warnings and a site_url.

Input Schema

Name	Required	Description	Default
`job`	No	What the brief is for (default reel); use the job you dealt for. photo = a still image, video = reel, song = Suno blocks only, site = SITE PROMPT, game = key art set, drama = short drama ad (beats, end card, caption rules).	reel
`tool`	No	Target tool: any (plain prose), midjourney, runway or kling (camera line first, shots capped at 10 s), suno (music blocks only), openfilm (leads with a FILM PLAN and a LOOK.CSS for a coding agent building the film as web pages in OpenFilm).	any
`beats`	No	Optional: what happens in each shot, in order, e.g. ["they sit in silence", "she slides a photo across the table"]. Beat n goes into SHOT n (or the one VIDEO PROMPT).
`title`	No	Optional title lettering for the image or key art (set in the type card). For drama, the show or brand name on the end card.
`aspect`	No	Optional aspect ratio, e.g. "16:9", "9:16", "4:5", "1:1", "2.39:1". Default 9:16 for reel and lyric, 16:9 for game.
`vocals`	No	Optional for music: "lyrics" lifts vocal bans out of SUNO EXCLUDE so a sung track can exist; "instrumental" adds them.
`feeling`	No	Drama only: the story's feeling or situation, e.g. "a quiet breakup at a dinner table". The hook opens on it and every shot carries it.
`seconds`	No	Optional running time in seconds, e.g. 15 for a reel or 60 for a short: split across the SHOT blocks (or the one VIDEO PROMPT) as "Duration: N s." Drama: 15 to 60, default 30, timed hook, twist, payoff.
`subject`	No	Who or what is in the shot, e.g. "a lighthouse keeper on a rocky coast". Without it the prompts say [your subject]. For drama, the product being advertised.
`hand_ids`	Yes	Card ids from deal_hand or find_styles, e.g. ["film-gold-200", "camera-closeup", "color-golden-hour"]. One per suit, except several camera cards = a shot list.

Output Schema

Name	Required	Description
`job`	No	the job as asked
`hand`	No
`lint`	No
`site`	No
`tool`	No	the tool the blocks are spelled for
`error`	No	Set instead of the fields above when the input was wrong.
`aspect`	No	the frame the blocks use
`blocks`	No	block name to paste-ready text
`ignored`	No	suits the job does not use
`seconds`	No	drama: the running time the beats are timed to
`handover`	No
`job_note`	No	a note for this job
`site_url`	No	opens the hand on directorslookbook.app
`beat_plan`	No	drama: each beat with its seconds and shot
`shot_order`	No	the SHOT block names in order
`substitute`	No	set when a stand-in card covers a genre the library lacks
`job_internal`	No	the deck term when it differs from the job asked (video = reel, photo = still)
`end_card_from`	No	drama: the second the end card starts

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / tool / description

Previous value: -"Target tool: any (plain prose), midjourney, runway or kling (camera line first, shots capped at 10 s), suno (music blocks only)."New value: +"Target tool: any (plain prose), midjourney, runway or kling (camera line first, shots capped at 10 s), suno (music blocks only), openfilm (leads with a FILM PLAN and a LOOK.CSS for a coding agent building the film as web pages in OpenFilm)."

changedInput schema / properties / tool / enum

Previous value: -[
-  "any",
-  "midjourney",
-  "runway",
-  "kling",
-  "suno"
-]New value: +[
+  "any",
+  "midjourney",
+  "runway",
+  "kling",
+  "suno",
+  "openfilm"
+]

First observedOct 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds substantial context: tool-specific respelling for midjourney/runway/kling/suno, camera-light and film-fx effects, lens behavior, seconds/beats/vocals effects, and extra returns like lint warnings and site_url. It does not discuss errors or validation, but it is well beyond what the annotations provide.

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?

The purpose is front-loaded, but the body becomes a dense semicolon-heavy run-on that mixes job types, tool variants, card rules, and two examples in one block. The content is useful, but the structure and length hurt scannability.

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?

Given 10 parameters, multiple enums, and an output schema, the description covers the important call-time concepts: job/tool variants, id constraints, examples for still and drama, and extra return fields. Missing return-value detail is acceptable because an output schema exists.

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 baseline is 3; the description adds cross-parameter meaning such as several camera cards producing a shot list, light/fx/lens cards affecting shots, seconds splitting duration, beats mapping to SHOT n, and vocals toggling SUNO EXCLUDE. It does not re-document every schema field, but it meaningfully explains interactions the schema does not.

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: 'Turn card ids into paste-ready prompt blocks,' then enumerates the block families and job-specific outputs. This clearly distinguishes it from siblings like deal_hand and find_styles, which supply the ids rather than compile prompts.

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?

Explicitly says to pass ids from deal_hand or find_styles and gives the 'one card per suit, except camera' rule, plus photo and drama examples. It does not explicitly say when to avoid this tool or route to lint_hand/show_card, so it stops short of full when/when-not guidance.

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

All Director's Lookbook 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?