Hook Detector

review_short

Rate my Reel or Short: read one public short the way Hook Detector reads a clip (its first frames, its words heard by ElevenLabs Scribe v2) and rate it against the real finds on its subject (the Short form search over the last 30 days, ranked by their multiple over the creator's usual). Returns review_id, url, platform, video_id, subject, subject_from, clip (first_line, first_word_s, words_per_minute, longest_pause_s, words, heard_by, not_heard_why, onscreen_text, plays, multiple), reads (five, in order: stop, gap, momentum, feeling, reach; each with verdict strong, moderate or weak, says, computed_from counted against the finds, and finds: 1 to 3 ids from finds), finds (each a real video with its url, plays, multiple, first_line and pace), finds_from, label, credits_charged and credits. Never a guessed number. Costs 3 credits, taken first and given back on any failure: 422 invalid_link (before any charge), 404 video_not_found (private or removed), 422 not_a_short, 422 review_not_possible (too few finds on the subject), 503 model_unavailable. 402 insufficient_credits under 3; limited per account per hour (429). Takes up to about 90 seconds. Needs research. Same as POST /v1/review/short.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "review_short"
  }
}

Input Schema

Name	Required	Description
`url`	No	a public Instagram Reel, TikTok video or YouTube Short link, starting with https://
`api_key`	No
`subject`	No	what the clip is about, 2 to 120 characters; leave out to read it from the clip
`idempotency_key`	No	retry safely: the same key and arguments within 24 hours answer the saved review and charge nothing

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

There are no annotations, and the description carries the full behavioral burden: it states the 3-credit cost, that credits are taken first and refunded on failure, the specific error conditions, rate limiting, and the roughly 90-second runtime. That is unusually complete disclosure for a paid, slow, stateful operation.

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 description is extremely dense and repeatedly enumerates return fields even though an output schema exists. That return-value inventory is largely redundant and makes the definition longer than necessary for an agent deciding whether and how to call it.

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 the tool's complexity, the description is complete: it covers cost, refund behavior, error cases, rate limits, runtime, public-link requirements and the relationship to the underlying POST endpoint. Since a rich output schema exists, the description does not need to carry return-shape details, and it still goes beyond the minimum.

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 75%, so the schema already documents most parameters. The description adds context that the URL must be a public Instagram Reel, TikTok video or YouTube Short and that the review is tied to a subject, but it does not add meaningful semantics for api_key or idempotency_key beyond what the schema provides.

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 uses a specific verb and resource: it rates one public Reel or Short by reading its first frames and words and comparing it against real finds on the subject. This is distinct from sibling listing, search and hook-discovery tools, and the output/error details reinforce exactly what operation is being performed.

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?

Usage is implied by the phrase 'Rate my Reel or Short' and by the public-link requirement, but the description does not explicitly say when to choose this over alternatives such as find_hooks, trending_shorts or find_long_hooks. It gives operating constraints and failure cases rather than selection guidance.

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

All Hook Detector 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?