A
licenseA
qualityA
maintenanceMCP 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.
5
8
675
45
MIT
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
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.7/5.0
Tool DescriptionsA
Average 4.8/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a clearly distinct concern: account balance, single-URL extraction, platform capability lookup, and YouTube search. There is no overlap in purpose or inputs.
Naming Consistency4/5
All tools share the consistent 'framefetch_' prefix, but the suffix is a mix of verbs (extract, search) and nouns (account, platform_capabilities). This is a minor deviation from a strictly uniform verb/noun pattern, but names remain predictable and readable.
Tool Count5/5
Four tools is well-scoped for a video-data extraction service. Each tool serves a necessary function, and the count feels neither sparse nor excessive.
Completeness5/5
The tools cover the full workflow: check balance before expensive calls (account), confirm capabilities before extraction (platform_capabilities), find videos (search), and extract data from a specific URL (extract). No obvious gaps exist for the server's stated purpose of one-by-one extraction from public social video URLs.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.9/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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"]}.
ParametersJSON Schema
| 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 100); 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), it discloses cost behavior ('Cost scales with what you request'), caching ('Never cached' for ask), degradation warnings ('never charged'), auth options (x402), and one-call-per-URL constraint. These are material behavioral traits not captured in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is front-loaded with purpose, then exclusions, return shape, cost/auth, and an example. Each section adds necessary context for a complex tool, though the `fields` parameter description is dense and could be slightly trimmed without losing value.
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?
The description thoroughly explains return concept ('only requested fields + cost block'), but not the exact JSON shapes, deferring to 'https://framefetch.net/docs'. Without an output schema, this is a minor gap. Still, it covers dependencies, degradation, platform limits, and auth, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds rich semantics: field dependencies (digest→transcript, audio_digest→digest), degradation rules, frames specifics (required when frames/text_overlay requested), cache impact on billing, and `voice` default. This goes far beyond the schema descriptions.
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 opens with a specific verb and resource: 'Extract data from ONE public social-video URL (YouTube incl. Shorts, TikTok, Instagram Reels, Pinterest, Reddit)'. It clearly distinguishes from siblings by explicitly stating when NOT to use it (non-video pages, private/login-walled content, bulk crawling).
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?
Provides explicit 'When NOT to use' conditions (non-video, private, bulk) and a concrete usage example. It also gives guidance on field selection via 'see `fields`' and notes cost scaling, helping the agent choose between this and other tools.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.7/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cache | No | false = fresh, billed search. | |
| limit | No | Default 10. | |
| query | Yes | 2-200 chars. | |
| platform | No |
Tool Definition Quality
A4.6/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
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!
Related MCP Servers
- 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.02MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.