framefetch
Server Details
Social-video URL → transcript, frames, OCR text & metadata across 6 platforms. MCP, x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: checking account balance, extracting video data, and querying platform capabilities. There is no overlap or confusion between them.
All tools share the 'framefetch_' prefix, but the suffixes mix nouns ('account', 'platform_capabilities') and verbs ('extract'), creating minor inconsistency. Still, the names are descriptive and easy to understand.
With 3 tools, the surface is minimal yet covers the essential workflow: check balance, extract data, and check capabilities. A slightly larger set might include a top-up tool, but the current count is reasonable for a focused API.
The tool set covers the core use case (extraction) and supporting operations (balance check, platform info). Missing a direct top-up or error-handling tool, but the account tool addresses the main failure mode (402).
Available Tools
3 toolsframefetch_accountARead-onlyInspect
Check this account's credit balance and recent usage. Read-only: never charges, and — unlike framefetch_extract — keeps working even at zero balance. Purpose: check credit balance and recent usage BEFORE running expensive framefetch_extract calls (transcript/frames/text_overlay can add up). When to use: at the start of a session, occasionally during a long batch of extract calls, or whenever framefetch_extract fails with a PAYMENT_REQUIRED (402) error — call this to confirm the balance, then top up. When NOT to use: before every single framefetch_extract call in a tight loop (pure overhead) — check periodically or reactively on a 402 instead. Returns: balance_micros (current credit balance), spend_7d_micros (spend over the trailing 7 days), calls_7d (call count over the trailing 7 days). All money values are micro-USD (1,000,000 = $1). If balance is low or zero: top up with x402 (USDC, no account needed) via POST /v1/topup, or buy credit with a card via POST /v1/checkout.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only nature ('never charges') and behavior at zero balance, matching the readOnlyHint annotation. No contradictions.
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?
Each sentence adds value, but description is relatively long. Front-loaded with purpose, but could be slightly tighter. Still efficient overall.
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 no output schema, description thoroughly explains return values, usage patterns, and error handling (402). Covers all needed context.
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?
No parameters in schema, so description compensates by detailing return fields (balance_micros, spend_7d_micros, calls_7d) with units and explanations. Baseline 4 for zero-param tools.
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?
Description starts with clear verb+resource: 'Check this account's credit balance and recent usage.' Distinguishes from sibling tools by contrasting with framefetch_extract's charging behavior.
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?
Explicitly states when to use (start of session, during long batch, on 402 error) and when not to use (before every call in a tight loop). Provides alternative actions for low balance.
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 structured data from ONE public social-video URL (YouTube incl. Shorts, TikTok, Instagram Reels, Pinterest, Reddit). Purpose: turn a video link into metadata (title, author, duration, date, thumbnail), insights (views/likes/comments), a transcript (captions, or Whisper when there are none — works on TikTok/Reddit too), an LLM digest (a 2-3 sentence gist plus topic tags summarizing the transcript), a structured VLM reading of the video (chapters, entities, products shown, claims, key moments as typed JSON — the video, understood), parametrically-sampled video frames, the on-screen text burned into those frames (OCR — captions, price tags, signage, lower-thirds), and/or a delta vs the previous fetch of the same url (engagement velocity per hour + title/thumbnail-change flags for tracking a video over time). When to use: you have a video URL and need its text, stats, frames, or on-screen text for analysis, summarization, or grounding a model. When NOT to use: non-video pages, private/login-walled content, or bulk crawling (one URL per call). Returns: one JSON object containing only the requested fields plus a cost block (micro-USD). Frames come back as time-limited signed image URLs; text_overlay returns one entry per frame with the OCR text, per-line confidence, and bounding boxes. Subtitles: set subtitle_format to "srt" or "vtt" to also get a ready-to-save subtitle file as a top-level subtitles string (built from the transcript's timed segments — the translated ones when "translate" is set); it requires "transcript" in fields and leaves the rest of the JSON unchanged. Cost/latency: metadata is sub-cent and fast; transcript is billed per audio-minute, frames per frame, and text_overlay per frame on top of that (all three also incur bandwidth for frames); digest is a small flat per-call add-on — request only the fields you need and downscale frames via width to control cost. Billing: a free tier covers light use; agents can also pay per call with x402 (USDC) with no account. Example: { "url": "https://www.youtube.com/watch?v=...", "fields": ["metadata","transcript"], "frames": { "mode": "fps", "fps": 1, "width": 480 } }
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public video URL from a supported platform. | |
| voice | No | 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. | |
| fields | No | 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. | |
| frames | No | Frame-sampling spec; required when "frames" or "text_overlay" is requested. | |
| translate | No | 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. | |
| verbosity | No | ||
| comments_cap | No | Max number of top-level comments the "comments" field returns (1–200, default 100). Inert unless "comments" is requested. | |
| subtitle_format | No | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description reinforces this by explaining the tool only reads data. It details behavioral traits like cost/latency, billing model, free tier, graceful degradation, and dependency between fields. No contradiction with annotations.
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 and detailed, with some repetition (e.g., graceful degradation mentioned multiple times). It is front-loaded with the core purpose and uses clear structure (purpose, usage, returns, cost, example), but could be more concise.
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's complexity (8 parameters, nested objects, no output schema), the description provides thorough context: parameter dependencies, field behaviors, cost impacts, error cases, and an example. It covers all necessary information for correct agent invocation.
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 description coverage is 88%, but the description adds significant value: it explains interactions between fields (e.g., 'digest' pulls in 'transcript'), defaults, error handling, and cost implications. For example, it clarifies that 'text_overlay' requires 'frames' and is auto-skipped above 200 frames.
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 extracts structured data from a single public social-video URL, listing supported platforms and specific data types (metadata, insights, transcript, etc.). It distinguishes itself from sibling tools (framefetch_account, framefetch_platform_capabilities) by focusing on video content extraction.
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 states when to use (analysis, summarization, grounding) and when not to use (non-video pages, private content, bulk crawling). While it doesn't name alternative tools for similar tasks, the guidance is clear and sufficient.
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
Return a JSON matrix of which data types (metadata, insights, transcript, frames) each supported platform provides — YouTube, YouTube Shorts, TikTok, Instagram Reels, Pinterest, Reddit. Purpose: check what is available for a platform BEFORE calling framefetch_extract, so you only request supported fields. No input required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate it. It adds workflow context (check before extract) and confirms no input needed. No contradictions or missing behavioral traits.
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?
Two sentences: first describes output, second gives purpose and guidance. Every sentence earns its place, no wasted words, well front-loaded.
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?
For a zero-parameter tool with readOnlyHint and no output schema, the description is fully complete: explains what it returns, why to use it, and how it fits with sibling tools.
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?
No parameters exist, and schema coverage is 100% (empty). The description states 'No input required,' which adds nothing beyond the schema but is appropriate. With 0 params, baseline is 4.
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, lists all platforms and data types, and explicitly distinguishes itself from framefetch_extract by stating it should be used before that tool to check availability.
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 guidance: 'check what is available for a platform BEFORE calling framefetch_extract, so you only request supported fields.' This tells the agent when to use this tool and its relationship to the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!