Skip to main content
Glama

find_long_hooks

Find long-form hooks: how the YouTube videos that beat their own channel open, on a topic. Long-form YouTube only, never Shorts, TikTok or Instagram (for those: find_hooks).

What it does: searches YouTube for long-form videos on the topic, keeps only the
outliers (a video whose views are at least min_outlier times the median views of its
own channel's recent uploads; 2 by default) posted in 2023 or later (nothing older is
ever delivered), reads the first intro_seconds (60 by default) of each one's
transcript, and says why that opening holds a viewer.

What comes back: the run's `finds`, ranked, strongest outlier first. Each has title,
channel, watch_url, player_url (an iframe src), thumbnail_url, views,
channel_median_views, outlier (28.2 means 28 times the channel's usual), outlier_score
(0 to 100 on one fixed scale: nothing else a run found moves it, so finds from
different runs rank together), outlier_tier, channel_size, likes_per_1k, posted_at,
duration_s, and the opening: intro (the first minute as it was said: lines of n, t in
seconds, text) and intro_text, always whole; and inside it the hook (verbatim: the lines
the analysis marks as the hook, ending on a sentence end, at most 25 seconds and 60
words, with hook_words, hook_start_s and hook_end_s, a sponsor read or greeting at the
front left out; hook_seconds is hook_end_s). auto_captions says the opening has almost
no punctuation. about_subject is yes or partly: a video the model judges not to be
about the subject is dropped. The analysis: hook_type (the same list as find_hooks),
mechanism (why it holds, quoting the opening word for word), promise, open_loop,
title_link (how the first lines pay off the title), beats (the opening in parts: from,
to, beat, does),
opens_with (cold_open, greeting, teaser, question, sponsor), format (the kind of
video), angle, template (the hook as a fill-in structure), steal_it and audience. When
the topic asks for a kind of opening ("question hooks", "storytime"), style_match says
whether each find is that kind and the matches come first. analysed is false
when the model could not analyse an opening: the opening is still real, its analysis
fields are null. The run's report.patterns lists the opening types at least two finds
share; report.shape says how the openings are built, counted from the finds
(hook_seconds, how long the hook runs, and hook_words as medians, beats with how many
openings use each and the second it usually starts_at, and the sequence of beats most
of them share); and
report.openers holds up to `openers` (3 by default, 0 for none) openings WRITTEN for
your topic from those structures (hook, then, hook_type, based_on). report.openers_label
is always "Written by Hook Detector from the structure of these real openings": show
it with them, never present one as a real video's opening. report.landscape is the
subject at a glance, counted from the videos the run held against their own channel
(videos, channels, outliers and their share, breakouts, small_channel_outliers,
recent_outliers). The run's hooks and bonus are always empty.

A link instead of a subject: when topic is a channel's YouTube address
(https://www.youtube.com/@name, or just @name) the run returns that channel's OWN
outliers, its recent long-form uploads that beat its usual (one provider call, no
search); when it is a long-form video's address the run returns that one video,
whatever its multiple (requested is 1). options.link says "channel" or "video". No
openings are written for a link (use remix_find on a find to write for your niche).
A Short's address is refused with 422.

Arguments: topic 3 to 500 characters; count 1 to 30 (default 8); language and country
optional; posted_within_days 30, 90, 365 or 730 to narrow the 2023 floor further;
channel_size "small", "medium" or "large" to keep only channels of that size (by what
their uploads usually get), so a small creator sees breakouts from channels their own
size; reuse=true (default) starts from the videos your last long or packaging run on
this topic bought within a week, and a video you already had read is delivered from
that read (analysis_from_earlier_read) at no model or provider cost. seen_before says
an earlier run of yours already found the video. idempotency_key: always pass one and
reuse it on a retry. wait_seconds 0 to 50: 0 returns the run_id at once; above 0 waits
and returns the run. Starts are limited per account per hour (429 rate_limited).

Cost: reserves up to 90 credits for 20 videos or fewer and 5 more for each video above
that (140 at 30; less on a smaller balance, down to 25) and charges
only the provider calls it made: the searches, one call per channel measured, one per
transcript read. A failed run costs nothing, and so does a run that
finds nothing, inside the same allowance a hook run has (the outcome says so).

Timing and next step: how long a run takes has not been measured yet, so never assume
a time. Call get_run with wait_seconds=50 until status is done or failed;
progress.items holds the finds written so far as cards
and progress.scan the videos it is looking at while it runs. Then keep_find, export_run. Same as POST /v1/longform. Needs the research
permission (403 insufficient_scope otherwise).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNohow many long-form hooks to deliver, 1 to 30
reuseNostart from the videos your last long or packaging run on this topic already bought (within a week), so the second tab on a topic costs little
topicYesthe subject to research, 3 to 500 characters, in any language. Or a YouTube address instead of a subject: a channel's (https://www.youtube.com/@name, or just @name) returns that channel's own outliers, its recent long-form uploads that beat its usual; a long-form video's (https://www.youtube.com/watch?v=...) returns that one video, whatever its multiple. A Short's address is refused (422)
api_keyNo
countryNooptional, an assigned ISO 3166-1 alpha-2 code (US, GB, MA): searches YouTube as seen from this country. It steers the search; it does not filter the channels
openersNooptional, 0 to 6 (default 3): how many openings to write for the subject from the structure of the real ones; 0 for none
languageNooptional, up to 60 characters: the language the videos should be spoken in, in words or as a tag ("Spanish", "pt-BR"). Left out, it is read from the topic's own language
min_outlierNooptional, 1.5 to 100 (default 2): how many times its own channel's usual views a video must have to count as an outlier. Only outliers are ever delivered
channel_sizeNooptional: only videos from channels of this size, by what the channel's uploads usually get (its median views, the figure the outlier is measured against): small (under 20,000), medium (up to 200,000) or large. Null or left out: any size
wait_secondsNo0 to 50: seconds to wait for the run to finish; 0 returns at once
intro_secondsNooptional, 20 to 120 (default 60): how many seconds of each video's opening to read and return
idempotency_keyNo1 to 255 visible ASCII characters; the same key within 24 hours returns the first run instead of paying for a second
posted_within_daysNooptional, how recent the videos must be, as days: 30, 90, 365, 730. Null or left out means everything since 2023-01-01; nothing older is ever delivered

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / count / description
      Previous value: -"how many long-form hooks to deliver, 1 to 20"New value: +"how many long-form hooks to deliver, 1 to 30"
    • changedInput schema / properties / count / maximum
      Previous value: -20New value: +30
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does much of that: cost reservation (90 credits for 20 or fewer, 5 per extra), rate limits (429), failure cost (nothing), link-address refusal (422), and reuse semantics. However, it doesn't state whether the operation is safe/read-only versus mutating in a compact way for an agent, and some behavioral edges (retry behavior, concurrency) are omitted. Still very strong for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

This is an extremely long, dense description that mixes purpose, detailed return schema (finds, report fields, outliers), parameters, cost, and timing into one block. It is not front-loaded for quick scanning; a reader must parse many lines of return-shape detail before getting to arguments and next steps. Much of the return-shape detail duplicates the output schema, which is a waste of description budget.

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?

Given the complexity (13 params, nested output) and the presence of an output schema, the description is very complete, perhaps overly so. It covers link handling, cost, rate limits, and the get_run flow. Completeness is strong, but the inclusion of extensive return-field explanations is redundant when an output schema exists, suggesting the description is compensating beyond need.

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 description coverage is 92%, so the schema already documents nearly all parameters. The description adds meaning to key ones (topic link behavior, min_outlier threshold, reuse, idempotency_key, wait_seconds), which reinforces but largely mirrors schema content. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource ('searches YouTube for long-form videos', 'find long-form hooks'), defines the outlier concept, and explicitly distinguishes the scope from siblings: 'Long-form YouTube only, never Shorts, TikTok or Instagram (for those: find_hooks).' This routes the agent to the right tool 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?

Explicit when-to-use and when-not-to-use, naming the alternative (find_hooks for Shorts/TikTok/Instagram, remix_find for link-based writing). It also instructs the follow-up pattern (get_run with wait_seconds=50 until done), the idempotency_key usage, and permission requirements. This is far beyond minimum guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources