Skip to main content
Glama
Sign In

Refs

by video.refs
OverviewDiscussionsAdmin

Check a storyboard and lay it out as a Claude Design canvas

storyboard
Read-onlyIdempotent

Before anything is built, storyboard the film the way an editor does. Send the storyboard you drafted from plan_video: 1 direction for a fixed brief, 2–4 when it's open. Each direction: logline, references (REF id + the one job each does), palette, type, sound, 2–3 style frames at full look, and 3–30 numbered panels in order, each with in/out seconds, shot size, camera move, action, VO, on-screen text, sound, the transition into the next panel, and its frame as layers (text, REF stills or the user's own captures by https URL, and shapes; positions in % of the frame). Mark a layer real only when it's a real capture of the user's product or a real result. This checks the timing and the REF ids and returns each REF's real still. While it returns ok: false it lists what to fix (fix it and call again); with ok: true it tells you how to lay the storyboard out as a Claude Design canvas (or as a text board where you can't make one). Free with Pro. Let the user pick a direction before you write any build prompt.

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": {
      "title": "<title>",
      "brief": "<brief>",
      "aspect": "<aspect>",
      "length_s": "<length_s>",
      "directions": "<directions>"
    },
    "name": "storyboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
bpmNo
fpsNo
brandNoBrandprint import used for the look, if any
briefYes
titleYes
aspectYes
length_sYes
directionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / context
      Removed value: -{
-  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
-  "type": "string"
-}
    • removedInput schema / properties / llm_model
      Removed value: -{
-  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "title",
-  "brief",
-  "aspect",
-  "length_s",
-  "directions",
-  "context",
-  "llm_model"
-]New value: +[
+  "title",
+  "brief",
+  "aspect",
+  "length_s",
+  "directions"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / directions / items / properties / references / items / properties / contributes / maxLength
      Previous value: -140New value: +400
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/closed-world, but the description discloses the actual response contract: ok:false returns a list of things to fix, ok:true returns canvas layout instructions, and it returns each REF's real still. It also flags the Pro entitlement, which the agent cannot infer from structured fields.

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 purpose and the pre-build sequencing are front-loaded in the first sentence, and nearly every clause adds a requirement or behavior. It is, however, one dense run-on paragraph whose long middle enumeration would be easier to parse as a short list.

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?

Against a deeply nested schema with no output schema, the description supplies input content requirements, the pass/fail response semantics, the retry behavior, and the downstream artifact. An agent has enough to construct a valid call and interpret the result without guessing.

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 description coverage is only 13%, so the description carries most of the burden, and it does enumerate direction content (logline, references with 'the one job each does', palette, type, sound, 2–3 style frames, 3–30 numbered panels with in/out seconds, shot size, camera move, action, VO, on-screen text, transition, layered frame). It adds the 'mark a layer real only when it's a real capture' rule, but leaves top-level title/brief/aspect/length_s/bpm/fps unexplained.

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: it validates a storyboard's timing and REF ids, then emits layout instructions for a Claude Design canvas (or a text board). It explicitly positions itself downstream of plan_video, so an agent can separate drafting from checking without opening any schema.

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?

Gives the input source ('the storyboard you drafted from plan_video'), the direction count rule (1 for a fixed brief, 2–4 when open), the retry loop ('fix it and call again'), and a sequencing constraint ('let the user pick a direction before you write any build prompt'). That is explicit when-to-use and when-to-repeat guidance.

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

All Refs toolsInspect
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