Skip to main content
Glama

get_run

A research run: its status, progress, charge and every hook it produced.

wait_seconds 0 to 50: wait up to that long for the run to finish, returning the
moment it is done or failed. Use wait_seconds=50 and call again while status is
"queued" or "running"; a fresh run needs about 3 or 4 such calls. progress has
stage, message and updated_at, plus counts once the research reports them, preview
(hooks written so far) while a running run holds one, and feed (the live research
wall: up to 24 clips the run is working on, newest first, each key, platform, creator,
views, state found|reading|talking|passed, thumb_url, a JPEG any <img> can load
with no key, and line, the banner or opening words once the judges passed the clip)
while it shows one, and on a Long form or Packaging run scan (the videos it is looking
at: up to 60 tiles {v: YouTube video id, s: found|on_topic|off_topic|measured|beat|
reading|ready|passed, x: multiple of the channel's usual or null}, oldest first, and
lanes with found, on_topic, measured, beat, reading, ready; draw a tile from
https://i.ytimg.com/vi/{v}/mqdefault.jpg; counts.measured and counts.beat are the
numbers report.landscape ends on). Pass since with the last
progress.updated_at to return on change or completion. It must be an ISO timestamp
with a timezone (422 invalid_request otherwise). `hooks` is the deck (a person
talking); `bonus` is always [] (removed 2026-10-08). Every hook has format and
section (always "main"), and
creator_country (TikTok only), place and place_country (null when unknown), banner
(the title placed on the video, null when none) and match ("exact" or "close", a
close match being a neighbouring subject delivered after the exact ones; null on runs
with no language or country and on older hooks). Since 2026-10-04 the run carries
understood (what the request was read to ask: subject, language, country, core,
audience, neighbours, styles, style_other, wants; null until read) and, on a run that
asked for a kind of opening ("controversial hooks", "storytime"), every hook carries
style_match (true when it opens that way; null otherwise). Since 2026-10-01 every hook carries
the virality v2 fields: virality (0 to 1 on one fixed scale since 2026-10-02),
virality_why, outlier, outlier_basis, creator_median_views, posted_at, age_days,
views_per_day, duration_s, paid, sound_reuse, own_sound, hashtags (null on older
hooks), and since 2026-10-02 the analysis: hook_type, hook_type_other, mechanism,
visual_hook, audience, template, steal_it; the run echoes posted_within_days and
seed_hook_ids, and once done carries
patterns: up to 3 hook structures winning in this deck, each name, template, why,
hook_ids and count, grouped by hook_type and computed before the run is done, in the
deck's language (null on older runs and when nothing is shared). Hooks include
transcript_kind:
speech, music, none, other, or null when unknown. conversation_id names the chat conversation the run
belongs to (null outside one). A done run with fewer hooks than asked for, or none,
has outcome: why in one plain paragraph, what to try next, and whether it was free
(stats.rejections holds the counts); a full run's outcome is null, or one sentence
when some hooks are under the view floor because the country filter set clips aside.
Free: reading a run costs no credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNo
run_idYes
api_keyNo
wait_secondsNo0 to 50: seconds to wait for the run to finish; 0 returns at once

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/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 burden and does so well: it discloses that reading a run is free (no credits), that since must be an ISO timestamp with a timezone or a 422 invalid_request occurs, and the wait_seconds bounds/polling behavior. It does not cover authentication requirements for api_key or any rate limits, keeping it short of a 5.

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?

The first sentence and the wait_seconds/since guidance are front-loaded and useful, but the bulk of the text is an exhaustive data dictionary of return fields (hooks, virality fields, feed, scan tiles, patterns). Since an output schema exists, this return-value enumeration is largely redundant and inflates the description into a dense wall of text.

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 tool's complexity and the presence of an output schema, the description supplies more than enough context to invoke the tool correctly: purpose, cost, polling strategy, since semantics and error behavior. The one gap is the undocumented api_key parameter, and much of the return-value detail is surplus rather than missing.

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 only 25% (wait_seconds alone is documented in the schema), so the description must compensate. It richly explains since (pass the last progress.updated_at for change/completion, timezone requirement, 422 on failure) and the wait_seconds usage pattern, but says nothing about run_id or api_key semantics. It adds real value for two of four parameters while leaving the credential and identifier params unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states the resource and scope precisely: a single research run with its status, progress, charge and every hook. Combined with the required run_id, an agent can tell this retrieves one run rather than listing runs. It does not explicitly contrast itself with siblings like list_runs or get_hook, so differentiation is implied rather than stated.

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?

Strong operational guidance: it prescribes a polling pattern (wait_seconds=50, call again while status is queued/running, ~3-4 calls for a fresh run) and explains when to pass since. What is missing is any explicit routing to sibling tools (e.g., list_runs vs get_run, or get_hook) for related needs.

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