framefetch
Server Details
Any social-video URL → transcript, metadata, frames, OCR, summary, search, Q&A. MCP server + x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MarvinRey7879/framefetch-client
- GitHub Stars
- 0
- Server Listing
- framefetch
Available Tools
4 toolsframefetch_accountARead-onlyInspect
Check this account's credit balance/usage. Read-only — never charges; works at zero balance (unlike framefetch_extract). Purpose: check balance before expensive framefetch_extract calls — at session start, periodically, or after a 402. When NOT to use: before every single framefetch_extract call in a tight loop. Returns: balance_micros, spend_7d_micros, calls_7d — micro-USD (1,000,000 = $1). Low balance: top up via x402 (USDC) at POST /v1/topup, or card at POST /v1/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral context: never charges, works at zero balance, and clarifies that it does not behave like framefetch_extract. It also mentions top-up endpoints for low balance, adding operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose first, then usage guidance, then return details. Every sentence serves a purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no input schema or output schema, the description provides return fields (balance_micros, spend_7d_micros, calls_7d) with units and usage context. This fully covers what an agent needs to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric baseline is 4. The description adds no parameter-level detail because none is needed, but it does explain the return fields and units, which is useful despite not being parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check this account's credit balance/usage.' It clearly distinguishes itself from sibling framefetch_extract by noting it is read-only and works at zero balance, unlike the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: at session start, periodically, or after a 402. Also gives a clear when-not-to-use case (before every call in a tight loop), which is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
framefetch_extractARead-onlyInspect
Extract data from ONE public social-video URL (YouTube incl. Shorts, TikTok, Instagram Reels, Pinterest, Reddit): metadata/insights/transcript/frames/digest/comments/etc — see fields. When NOT to use: non-video pages, private/login-walled content, or bulk crawling (one URL per call). Returns one JSON object with only the requested fields + a cost block (micro-USD); shapes: https://framefetch.net/docs. Cost scales with what you request (frames/transcript cost more than metadata). No key? POST /v1/keys {email} -> instant key (~100 free calls); or x402 (USDC), no account. Example: {"url":"https://www.youtube.com/watch?v=...","fields":["metadata","transcript"]}.
| Name | Required | Description | Default |
|---|---|---|---|
| ask | No | Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable. Long videos: answer draws on a relevance-selected/sampled subset, not just the head — see response `ask.coverage`. No transcript (e.g. Pinterest): falls back to frames, `based_on`:["frames"]. | |
| url | Yes | Public video URL from a supported platform. | |
| cache | No | false forces a fresh, billed extract. | |
| voice | No | Voice for "audio_digest": OpenAI voices (alloy/echo/fable/onyx/nova/shimmer) + Groq "Fritz-PlayAI"; default "alloy". | |
| fields | No | Which data to return; default ["metadata"]. Pulls: digest→transcript; audio_digest→digest→transcript; structured→transcript; comment_sentiment→comments. digest/audio_digest/structured/comment_sentiment: degrade to a warning, never charged, on failure. digest: gist+topics via LLM. audio_digest: mp3 of digest (signed URL, 24h); voice via `voice`; +`translate` for other-language audio. structured: chapters/entities/products_shown/claims/key_moments via vision LLM. comments: up to comments_cap; YouTube only (else warning; see GET /v1/platforms). comment_sentiment: aggregated audience sentiment (positive_pct/neutral_pct/negative_pct/summary/top_themes); needs >=5 comments; same YouTube-only limit. text_overlay: OCR per frame; requires "frames"; skipped above 200 frames. delta: velocity vs the previous fetch; first call seeds the baseline. Docs: https://framefetch.net/docs. | |
| frames | No | Frame-sampling spec; required when "frames" or "text_overlay" is requested. | |
| translate | No | ISO-639-1 target language (e.g. "es"); adds `transcript_translated` (timings kept). Requires "transcript" (or "digest"). Billed per audio-minute. | |
| comments_cap | No | Max top-level comments (1-200, default 30); only used with "comments". | |
| subtitle_format | No | Renders transcript as subtitles in `subtitles` (srt/vtt). Requires "transcript" (or "digest"); uses translated cues if "translate" set. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the return shape (one JSON object + cost block), cost scaling, per-field degradation without charge, caching semantics, auth flows, YouTube-only comments limitations, and the delta baseline side effect. This gives the agent a strong behavioral model of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense and well organized, with clear sections for scope, when-not-to-use, return contract, cost, auth, and an example. Every clause earns its place, and the core one-URL extraction purpose is front-loaded before peripheral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers supported platforms, return contract, field dependencies, failure/degradation behavior, auth, cost, and limitations. A docs link is also provided for detailed shapes, leaving no major gap for an agent deciding whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds value by providing an example, noting that frames/transcript cost more than metadata, and clarifying that only requested fields plus cost are returned, which nudges it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource precisely: 'Extract data from ONE public social-video URL' and enumerates supported platforms and field categories. It does not explicitly name or differentiate sibling tools like framefetch_search, relying on the 'one URL per call' constraint and the fields list instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when NOT to use the tool: non-video pages, private/login-walled content, and bulk crawling. However, it does not point to a named alternative tool for discovery or bulk use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
framefetch_platform_capabilitiesARead-onlyInspect
JSON matrix of data types (metadata, insights, transcript, frames, comments) per platform — YouTube (+Shorts), TikTok, Instagram Reels, Pinterest, Reddit. Call before framefetch_extract to confirm support. No input.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that the tool takes no input and provides a capability matrix. It discloses the scope of the returned data (data types and platforms) without unnecessary detail, consistent with the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is three short sentences, front-loaded with the core function. No filler words—every part adds value (data types, platforms, usage hint, no-input confirmation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple information retrieval with no input and a clearly described output, the description fully covers its purpose and usage context. The absence of an output schema is compensated by the explicit enumeration of what the matrix contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description confirms 'No input.' This is redundant with the empty schema but reinforces the fact; since there are no parameters to explain, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a JSON matrix of data types per platform, enumerating both data types (metadata, insights, transcript, frames, comments) and platforms (YouTube, TikTok, Instagram Reels, Pinterest, Reddit). It explicitly directs usage before framefetch_extract, distinguishing it from sibling tools like framefetch_extract, framefetch_search, and framefetch_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance to call this tool before framefetch_extract to confirm support, providing direct usage context. This also implies the tool serves as a prerequisite check, making the alternative (framefetch_extract) and the timing clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
framefetch_searchARead-onlyInspect
Search YouTube by keyword (yt-dlp, no login). Returns up to limit hits: url/title/uploader/durationSec/uploadDate(often null)/thumbnail/views. YouTube only — use framefetch_extract on a hit's url for transcript/frames/etc. Billed ~$0.002/call (metadata-tier), regardless of limit.
| Name | Required | Description | Default |
|---|---|---|---|
| cache | No | false = fresh, billed search. | |
| limit | No | Default 10. | |
| query | Yes | 2-200 chars. | |
| platform | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal readOnlyHint and openWorldHint. The description goes further by disclosing 'yt-dlp, no login', billing cost '~$0.002/call', result field list, and the caveat that uploadDate is often null. It does not contradict annotations and adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the primary purpose, then implementation details, billing, and a pointer to the next step. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, what it returns, cost, login requirements, and the alternative tool. It lacks an explicit note about error cases or empty results, but it is complete enough for a simple search tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning by clarifying that `limit` controls the number of returned hits, listing the fields returned, and restricting platform to YouTube. It does not repeat schema text and gives context for `limit` and platform beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Search YouTube by keyword'. It clearly identifies what the tool does and differentiates from the sibling 'framefetch_extract' by stating 'use framefetch_extract on a hit's url for transcript/frames/etc.' It also pins scope with 'YouTube only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'Search YouTube by keyword' and an explicit alternative: 'use framefetch_extract on a hit's url...'. It also gives an exclusion: 'YouTube only'. This is strong guidance for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
framefetch_extract1 field changed- changed
Input schema / properties / comments_cap / descriptionPrevious value: -"Max top-level comments (1-200, default 100); only used with \"comments\"."New value: +"Max top-level comments (1-200, default 30); only used with \"comments\"."
1 tool update
- Changed
framefetch_extract1 field changed- removed
Input schema / properties / verbosityRemoved value: -{ - "enum": [ - "concise", - "detailed" - ], - "type": "string" -}
1 tool update
- Added
framefetch_search
1 tool update
- Changed
framefetch_extract1 field changed- added
Input schema / properties / cacheAdded value: +{ + "description": "false forces a fresh, billed extract.", + "type": "boolean" +}
1 tool update
- Changed
framefetch_extract1 field changed- changed
Input schema / properties / ask / descriptionPrevious value: -"Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable. Long videos: answer draws on a relevance-selected/sampled subset, not just the head — see response `ask.coverage`."New value: +"Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable. Long videos: answer draws on a relevance-selected/sampled subset, not just the head — see response `ask.coverage`. No transcript (e.g. Pinterest): falls back to frames, `based_on`:[\"frames\"]."
1 tool update
- Changed
framefetch_extract2 fields changed- changed
Input schema / properties / ask / descriptionPrevious value: -"Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable."New value: +"Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable. Long videos: answer draws on a relevance-selected/sampled subset, not just the head — see response `ask.coverage`." - changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return; default [\"metadata\"]. Pulls: digest→transcript; audio_digest→digest→transcript; structured→transcript; comment_sentiment→comments. digest/audio_digest/structured/comment_sentiment: degrade to a warning, never charged, on failure. digest: gist+topics via LLM. audio_digest: mp3 of digest (signed URL, 24h); voice via `voice`; +`translate` for other-language audio. structured: chapters/entities/products_shown/claims/key_moments via vision LLM. comments: up to comments_cap; YouTube+Reddit only (else warning; see GET /v1/platforms). comment_sentiment: aggregated audience sentiment (positive_pct/neutral_pct/negative_pct/summary/top_themes); needs >=5 comments; same YouTube+Reddit limit. text_overlay: OCR per frame; requires \"frames\"; skipped above 200 frames. delta: velocity vs the previous fetch; first call seeds the baseline. Docs: https://framefetch.net/docs."New value: +"Which data to return; default [\"metadata\"]. Pulls: digest→transcript; audio_digest→digest→transcript; structured→transcript; comment_sentiment→comments. digest/audio_digest/structured/comment_sentiment: degrade to a warning, never charged, on failure. digest: gist+topics via LLM. audio_digest: mp3 of digest (signed URL, 24h); voice via `voice`; +`translate` for other-language audio. structured: chapters/entities/products_shown/claims/key_moments via vision LLM. comments: up to comments_cap; YouTube only (else warning; see GET /v1/platforms). comment_sentiment: aggregated audience sentiment (positive_pct/neutral_pct/negative_pct/summary/top_themes); needs >=5 comments; same YouTube-only limit. text_overlay: OCR per frame; requires \"frames\"; skipped above 200 frames. delta: velocity vs the previous fetch; first call seeds the baseline. Docs: https://framefetch.net/docs."
1 tool update
- Changed
framefetch_extract6 fields changed- changed
Input schema / properties / ask / descriptionPrevious value: -"A question about the video (3-500 chars); returns a <=500-token answer grounded in the transcript with timestamped supporting quotes ({ answer, quotes: [{ t_sec, text }], confidence, based_on }) instead of a full transcript dump, auto-including \"transcript\" as its input, never served from the cache (a fresh answer every call, even when the underlying extraction is otherwise cached), and degrading gracefully (omitted, never charged) if no transcript is available or the model fails."New value: +"Question about the video (3-500 chars); <=500-token answer w/ timestamped quotes, grounded in the transcript (auto-pulled). Never cached; degrades (never charged) if unavailable." - changed
Input schema / properties / comments_cap / descriptionPrevious value: -"Max number of top-level comments the \"comments\" field returns (1–200, default 100). Inert unless \"comments\" is requested."New value: +"Max top-level comments (1-200, default 100); only used with \"comments\"." - changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"structured\" is the video, understood: a vision LLM reads the transcript AND sampled keyframes and returns typed JSON — chapters ({ start_sec, end_sec, title, summary }), entities ({ name, type }), products shown ({ name, evidence: visual|spoken|both }), claims ({ text, timestamp_sec? }), and key moments ({ timestamp_sec, description }). It automatically pulls in \"transcript\" (one of its inputs) and also downloads the video for its own keyframe pass, so it works even on caption-less sources. Deterministic and cacheable; a flat per-video price. It degrades gracefully (omitted with a warning, never charged) if the model/parse fails. \"comments\" returns up to comments_cap top-level comments per video ({ items: [{ text, author?, like_count?, reply_count? }], total_fetched, cap_applied, sort:\"top\" }); it is INDEPENDENT of the transcript (no download) and available on YouTube and Reddit only — TikTok/Instagram/Pinterest return it as a warning, never a charge (check GET /v1/platforms). Author is a display handle only (no user ids/urls). \"comment_sentiment\" is aggregated audience sentiment: percentages, themes, summary — ONE LLM pass over the comments returns { positive_pct, neutral_pct, negative_pct (they sum to 100), summary (2-3 English sentences), top_themes (up to 5), representative { positive?, negative? } }. It automatically pulls in \"comments\" (its input; same YouTube/Reddit-only availability) and needs at least 5 comments — fewer, or a model failure, omits it with a warning and is never charged. No competitor offers this rollup. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags."New value: +"Which data to return; default [\"metadata\"]. Pulls: digest→transcript; audio_digest→digest→transcript; structured→transcript; comment_sentiment→comments. digest/audio_digest/structured/comment_sentiment: degrade to a warning, never charged, on failure. digest: gist+topics via LLM. audio_digest: mp3 of digest (signed URL, 24h); voice via `voice`; +`translate` for other-language audio. structured: chapters/entities/products_shown/claims/key_moments via vision LLM. comments: up to comments_cap; YouTube+Reddit only (else warning; see GET /v1/platforms). comment_sentiment: aggregated audience sentiment (positive_pct/neutral_pct/negative_pct/summary/top_themes); needs >=5 comments; same YouTube+Reddit limit. text_overlay: OCR per frame; requires \"frames\"; skipped above 200 frames. delta: velocity vs the previous fetch; first call seeds the baseline. Docs: https://framefetch.net/docs." - changed
Input schema / properties / subtitle_format / descriptionPrevious value: -"If set, also render the transcript as a subtitle file and add it as a top-level \"subtitles\" string (\"srt\" = SubRip, \"vtt\" = WebVTT). Requires \"transcript\" in fields (or \"digest\", which pulls it in); uses the translated cues when \"translate\" is set. Does not change any other field or the cost."New value: +"Renders transcript as subtitles in `subtitles` (srt/vtt). Requires \"transcript\" (or \"digest\"); uses translated cues if \"translate\" set." - changed
Input schema / properties / translate / descriptionPrevious value: -"ISO-639-1 target language (e.g. \"es\", \"de\", \"ja\"); adds transcript_translated (the transcript translated into that language, with timings preserved). Requires \"transcript\" in fields (or \"digest\", which pulls transcript in). Billed per audio-minute like transcription, even for caption-sourced transcripts."New value: +"ISO-639-1 target language (e.g. \"es\"); adds `transcript_translated` (timings kept). Requires \"transcript\" (or \"digest\"). Billed per audio-minute." - changed
Input schema / properties / voice / descriptionPrevious value: -"Spoken voice for the \"audio_digest\" field. The six OpenAI voices (alloy/echo/fable/onyx/nova/shimmer) plus Groq/PlayAI's \"Fritz-PlayAI\". Defaults to \"alloy\". Inert unless \"audio_digest\" is requested."New value: +"Voice for \"audio_digest\": OpenAI voices (alloy/echo/fable/onyx/nova/shimmer) + Groq \"Fritz-PlayAI\"; default \"alloy\"."
1 tool update
- Changed
framefetch_extract1 field changed- added
Input schema / properties / askAdded value: +{ + "description": "A question about the video (3-500 chars); returns a <=500-token answer grounded in the transcript with timestamped supporting quotes ({ answer, quotes: [{ t_sec, text }], confidence, based_on }) instead of a full transcript dump, auto-including \"transcript\" as its input, never served from the cache (a fresh answer every call, even when the underlying extraction is otherwise cached), and degrading gracefully (omitted, never charged) if no transcript is available or the model fails.", + "maxLength": 500, + "minLength": 3, + "type": "string" +}
1 tool update
- Changed
framefetch_extract3 fields changed- added
Input schema / properties / comments_capAdded value: +{ + "description": "Max number of top-level comments the \"comments\" field returns (1–200, default 100). Inert unless \"comments\" is requested.", + "maximum": 200, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"structured\" is the video, understood: a vision LLM reads the transcript AND sampled keyframes and returns typed JSON — chapters ({ start_sec, end_sec, title, summary }), entities ({ name, type }), products shown ({ name, evidence: visual|spoken|both }), claims ({ text, timestamp_sec? }), and key moments ({ timestamp_sec, description }). It automatically pulls in \"transcript\" (one of its inputs) and also downloads the video for its own keyframe pass, so it works even on caption-less sources. Deterministic and cacheable; a flat per-video price. It degrades gracefully (omitted with a warning, never charged) if the model/parse fails. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags."New value: +"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"structured\" is the video, understood: a vision LLM reads the transcript AND sampled keyframes and returns typed JSON — chapters ({ start_sec, end_sec, title, summary }), entities ({ name, type }), products shown ({ name, evidence: visual|spoken|both }), claims ({ text, timestamp_sec? }), and key moments ({ timestamp_sec, description }). It automatically pulls in \"transcript\" (one of its inputs) and also downloads the video for its own keyframe pass, so it works even on caption-less sources. Deterministic and cacheable; a flat per-video price. It degrades gracefully (omitted with a warning, never charged) if the model/parse fails. \"comments\" returns up to comments_cap top-level comments per video ({ items: [{ text, author?, like_count?, reply_count? }], total_fetched, cap_applied, sort:\"top\" }); it is INDEPENDENT of the transcript (no download) and available on YouTube and Reddit only — TikTok/Instagram/Pinterest return it as a warning, never a charge (check GET /v1/platforms). Author is a display handle only (no user ids/urls). \"comment_sentiment\" is aggregated audience sentiment: percentages, themes, summary — ONE LLM pass over the comments returns { positive_pct, neutral_pct, negative_pct (they sum to 100), summary (2-3 English sentences), top_themes (up to 5), representative { positive?, negative? } }. It automatically pulls in \"comments\" (its input; same YouTube/Reddit-only availability) and needs at least 5 comments — fewer, or a model failure, omits it with a warning and is never charged. No competitor offers this rollup. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags." - changed
Input schema / properties / fields / items / enumPrevious value: -[ - "metadata", - "insights", - "transcript", - "frames", - "text_overlay", - "digest", - "audio_digest", - "structured", - "delta" -]New value: +[ + "metadata", + "insights", + "transcript", + "frames", + "text_overlay", + "digest", + "audio_digest", + "structured", + "comments", + "comment_sentiment", + "delta" +]
1 tool update
- Changed
framefetch_extract2 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags."New value: +"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"structured\" is the video, understood: a vision LLM reads the transcript AND sampled keyframes and returns typed JSON — chapters ({ start_sec, end_sec, title, summary }), entities ({ name, type }), products shown ({ name, evidence: visual|spoken|both }), claims ({ text, timestamp_sec? }), and key moments ({ timestamp_sec, description }). It automatically pulls in \"transcript\" (one of its inputs) and also downloads the video for its own keyframe pass, so it works even on caption-less sources. Deterministic and cacheable; a flat per-video price. It degrades gracefully (omitted with a warning, never charged) if the model/parse fails. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags." - changed
Input schema / properties / fields / items / enumPrevious value: -[ - "metadata", - "insights", - "transcript", - "frames", - "text_overlay", - "digest", - "audio_digest", - "delta" -]New value: +[ + "metadata", + "insights", + "transcript", + "frames", + "text_overlay", + "digest", + "audio_digest", + "structured", + "delta" +]
1 tool update
- Changed
framefetch_extract3 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags."New value: +"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"audio_digest\" is a spoken audio briefing of the video: it speaks the digest gist as an mp3 and returns { url, seconds, voice, provider, lang? } (mp3, signed URL, 24h TTL); it automatically pulls in \"digest\" (and thus \"transcript\"), and when \"translate\" is also set the digest is generated directly in that target language so the audio speaks it — combine \"audio_digest\" with \"translate\" for foreign-language audio, and pick the voice with the \"voice\" param. It degrades gracefully (omitted with a warning, never charged) if no digest is available or TTS fails. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags." - changed
Input schema / properties / fields / items / enumPrevious value: -[ - "metadata", - "insights", - "transcript", - "frames", - "text_overlay", - "digest", - "delta" -]New value: +[ + "metadata", + "insights", + "transcript", + "frames", + "text_overlay", + "digest", + "audio_digest", + "delta" +] - added
Input schema / properties / voiceAdded value: +{ + "description": "Spoken voice for the \"audio_digest\" field. The six OpenAI voices (alloy/echo/fable/onyx/nova/shimmer) plus Groq/PlayAI's \"Fritz-PlayAI\". Defaults to \"alloy\". Inert unless \"audio_digest\" is requested.", + "enum": [ + "alloy", + "echo", + "fable", + "onyx", + "nova", + "shimmer", + "Fritz-PlayAI" + ], + "type": "string" +}
1 tool update
- Changed
framefetch_extract2 fields changed- added
Input schema / properties / subtitle_formatAdded value: +{ + "description": "If set, also render the transcript as a subtitle file and add it as a top-level \"subtitles\" string (\"srt\" = SubRip, \"vtt\" = WebVTT). Requires \"transcript\" in fields (or \"digest\", which pulls it in); uses the translated cues when \"translate\" is set. Does not change any other field or the cost.", + "enum": [ + "srt", + "vtt" + ], + "type": "string" +} - added
Input schema / properties / translateAdded value: +{ + "description": "ISO-639-1 target language (e.g. \"es\", \"de\", \"ja\"); adds transcript_translated (the transcript translated into that language, with timings preserved). Requires \"transcript\" in fields (or \"digest\", which pulls transcript in). Billed per audio-minute like transcription, even for caption-sourced transcripts.", + "type": "string" +}
1 tool update
- Added
framefetch_account
1 tool update
- Changed
framefetch_extract2 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it."New value: +"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"digest\" is an LLM summary ({ gist, topics, state? }) of the transcript and automatically pulls in \"transcript\" (its input) — it degrades gracefully (omitted with a warning) if no transcript is available. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it. \"delta\" tracks a video over time: it compares this fetch against the previous one of the SAME url and returns { hasPrior, sinceTs, viewsPerHr, likesPerHr, commentsPerHr, titleChanged, thumbnailChanged } — the first fetch of a url just seeds the baseline (hasPrior:false); call again later to get the per-hour velocity and creator-edit flags." - changed
Input schema / properties / fields / items / enumPrevious value: -[ - "metadata", - "insights", - "transcript", - "frames", - "text_overlay" -]New value: +[ + "metadata", + "insights", + "transcript", + "frames", + "text_overlay", + "digest", + "delta" +]
1 tool update
- Changed
framefetch_extract3 fields changed- changed
Input schema / properties / fields / descriptionPrevious value: -"Which data to return. Default [\"metadata\"]. Request the minimum you need."New value: +"Which data to return. Default [\"metadata\"]. Request the minimum you need. \"text_overlay\" (on-screen text via OCR) requires \"frames\" to also be requested, and is auto-skipped (with a warning, not an error) above 200 estimated frames — OCR runs a subprocess per frame, so keep the frames spec narrow (fps/range) when you want it." - changed
Input schema / properties / fields / items / enumPrevious value: -[ - "metadata", - "insights", - "transcript", - "frames" -]New value: +[ + "metadata", + "insights", + "transcript", + "frames", + "text_overlay" +] - changed
Input schema / properties / frames / descriptionPrevious value: -"Frame-sampling spec; required when \"frames\" is requested."New value: +"Frame-sampling spec; required when \"frames\" or \"text_overlay\" is requested."
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Multimodal video analysis MCP — transcription, vision, and OCR for any video URL.
Any video URL to LLM-ready transcript. ASR built in, no captions needed. TikTok, X, TED and more.
- MysocialOAuthio.mysocial
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
1 MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP server for video analysis — extracts transcripts, key frames with OCR, and annotated timelines from video URLs. Supports Loom and direct video files (.mp4, .webm). Zero auth required.4857058MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server for comprehensive video analysis — AI-powered transcription, visual frame analysis, and metadata extraction from 1000+ platforms.1MIT
- FlicenseBqualityDmaintenanceAn MCP server that extracts transcripts, metadata, and summaries from YouTube videos across various URL formats including Shorts and standard links. It provides comprehensive video data and insights for analysis within MCP-compatible environments.3-
- AlicenseNot gradedqualityBmaintenanceMCP server that turns video URLs into transcripts and important keyframes locally, with no cloud or API keys.3202MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Each tool maps to a clearly distinct function: balance checking, single-URL extraction, platform capability lookup, and YouTube search. The descriptions explicitly separate them, especially framing framefetch_account as read-only and framefetch_extract as the only paid operation. There is no real risk of selecting the wrong tool for a task.
All tools share the framefetch_ prefix and use consistent lowercase snake_case, giving the set a coherent namespace. However, the suffixes mix nouns like account and platform_capabilities with verbs like extract and search, so the naming is not as uniform as a strict verb_noun convention.
Four tools is well-scoped for a social-video extraction API: account, capabilities, search, and extraction each earn their place without overlap. The set is neither too thin nor bloated for its apparent purpose.
The tool surface covers the core workflow: check platform support, search for a video, extract desired data, and monitor account balance. There are no obvious dead ends or missing operations for the stated video-extraction domain.