Skip to main content
Glama
Sign In

Refs

by video.refs
OverviewDiscussionsAdmin

Get a video's blueprint

get_blueprint
Read-only

The full reverse-engineered blueprint of one video: hook frame by frame, beat sheet with timestamps, shot list, style guide, voice and sound, script template, production plan, edit recipe, QA checklist, plus a runnable recipe prompt. Markdown by default; format "json" returns the plates, toolkit, recipe and measured timeline as one object. To see the film's frames, call get_frames. Accepts a REF id (REF-0005), a refs.video link, the source YouTube/X link, or the id from search_videos. Needs a Refs account with Pro; without one, the app asks the user to sign in. search_videos is free.

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": {
      "id": "<id>"
    },
    "name": "get_blueprint"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesREF-0005, a refs.video/v/… link, a YouTube/X link, an id from search_videos, or one of your brand films (brand:<import>:<film>, from get_brand)
formatNoDefault markdown. "json": plates as an array, the toolkit, the measured timeline (shots, camera, type, audio grid) and the frame sheets on hand
include_recipeNoDefault true

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: -[
-  "id",
-  "context",
-  "llm_model"
-]New value: +[
+  "id"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With readOnlyHint and destructiveHint already declaring a safe read, the description still adds real context: the Pro-account requirement and the sign-in fallback the app triggers, which no annotation conveys. It does not mention response size or whether output is ever truncated, which matters for a "full blueprint" payload.

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?

Front-loads the resource and payload contents, then layers output format, sibling redirect, and auth in a logical progression. The long content enumeration earns its place because it lets an agent judge coverage before calling.

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?

Covers the essential agent questions for this tool — what it returns, in which formats, who can call it, and the cheaper alternative. Minor gaps: no note on payload size or whether the markdown/json variants differ in cost or latency.

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 coverage is 100%, so id formats and the markdown/json enum are already documented in the schema; the description largely restates them. It adds a little meaning by describing the json return as "one object" containing plates, toolkit, recipe and measured timeline, but the brand-film id form remains schema-only. Baseline 3 applies when the schema carries the semantics.

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 — the reverse-engineered blueprint of one video — and enumerates the deliverables (hook frames, beat sheet, shot list, style guide, script template, edit recipe, QA checklist). It explicitly distinguishes itself from get_frames and search_videos, so an agent can pick it without opening schemas.

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?

Gives a clear redirect to get_frames for frames and flags search_videos as the free alternative, plus the Pro-account prerequisite. It lacks explicit "when not to use" guidance relative to adjacent tools like get_formula, storyboard, or plan_video, which likely overlap in purpose.

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