Refs

Check a render against its reference

check_render

Read-only

After rendering a video from a reference, check it against that film's measured timeline and get concrete fixes: cut timing to the frame, pace, brightness curve, motion per shot, loudness for the platform, and format. First measure your render: run node scripts/measure.mjs <file> from the Refs starter kit (curl -sL https://refs.video/starter.zip -o refs-starter.zip && unzip refs-starter.zip; it unpacks to refs-starter/) and pass the JSON it prints as render. Returns a score out of 100, a table of checks and a numbered fix list (frames at your render's frame rate), then the same as JSON. Costs 2 credits, so fix, re-measure and check again. 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>",
      "render": "<render>"
    },
    "name": "check_render"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The reference you built from: REF-0005, a refs.video/v/… link, a YouTube/X link, or an id from search_videos
`render`	Yes	The JSON printed by `node scripts/measure.mjs <your video>`, as an object (or that JSON as text)
`target`	No	Where it will be posted; sets the loudness target: x, youtube, instagram and meta −14 LUFS, tiktok −14 to −10, web −16, true peak ≤ −1 dBTP. Default: the reference's platform

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 8, 2026

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",
-  "render",
-  "context",
-  "llm_model"
-]New value: +[
+  "id",
+  "render"
+]

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / target / description

Previous value: -"Where it will be posted; sets the loudness target: x and youtube −14 LUFS, tiktok −14 to −10, web −16, true peak ≤ −1 dBTP. Default: the reference's platform"New value: +"Where it will be posted; sets the loudness target: x, youtube, instagram and meta −14 LUFS, tiktok −14 to −10, web −16, true peak ≤ −1 dBTP. Default: the reference's platform"

changedInput schema / properties / target / enum

Previous value: -[
-  "x",
-  "youtube",
-  "tiktok",
-  "web"
-]New value: +[
+  "x",
+  "youtube",
+  "tiktok",
+  "instagram",
+  "meta",
+  "web"
+]

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds crucial behavior: it costs 2 credits, requires a Refs Pro account, prompts sign-in otherwise, and returns both a human-readable table/fix list and equivalent JSON. The credit and auth details are exactly the context an agent needs before invoking it.

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 description is front-loaded with purpose and prerequisites, and every sentence carries operational information. The inline curl/unzip command is dense but directly relevant to obtaining the required measurement script, so it earns its place despite making the paragraph long.

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?

For a tool with no output schema, the description fully explains the return format (score, check table, numbered fixes, then JSON), the input preparation workflow, cost, and account requirements. An agent has everything needed to call it correctly and understand what comes back.

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 schema already documents the id forms, render JSON shape, and target enum values. The description still adds value by specifying the exact measurement script that must produce the render JSON and by explaining that fix-list frame numbers use the render's frame rate.

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 precise verb and object: check a rendered video against a reference's measured timeline. It names the exact outputs (score out of 100, check table, numbered fix list) and distinguishes itself from the free sibling search_videos, so an agent can identify its role immediately.

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?

It states the exact precondition (after rendering a video from a reference), gives the required first step (run node scripts/measure.mjs and pass the JSON as render), explains the credit cost and Pro-account requirement, and explicitly notes that search_videos is free. That is explicit when-to-use, when-not, and prerequisite guidance.

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

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