Skip to main content
Glama
MKirovBG

scribefy-mcp

by MKirovBG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

scribefy-mcp

MCP server for Scribefy — extract YouTube transcripts from Claude Desktop, Cursor, Windsurf, ChatGPT custom GPTs, or any other MCP-compatible client.

Live now — set it up in a minute below, or try the web app at scribefy.app.

Why

Most YouTube transcript tools live in browser extensions or one-off web UIs. This wraps Scribefy's API into the MCP standard so your AI assistant can pull a transcript whenever a user pastes a YouTube link — no manual copy-paste, no separate tabs.

Related MCP server: youtube-transcript-mcp

Requirements

  • Node 20+

  • A Scribefy account on the API + MCP plan ($25/mo) for an API key. You can install without a key first — the MCP host registers the server cleanly and you'll get a friendly nudge when you try to use a tool — then add your key from scribefy.app/dashboard to start extracting.

Setup

Claude Desktop

Open the config file (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "scribefy": {
      "command": "npx",
      "args": ["-y", "scribefy-mcp"],
      "env": {
        "SCRIBEFY_API_KEY": "sk_live_…"
      }
    }
  }
}

Restart Claude Desktop. The extract_transcript tool appears in the available-tools panel.

Cursor

Settings → Cursor Settings → MCP → Add new MCP server:

{
  "scribefy": {
    "command": "npx",
    "args": ["-y", "scribefy-mcp"],
    "env": {
      "SCRIBEFY_API_KEY": "sk_live_…"
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "scribefy": {
      "command": "npx",
      "args": ["-y", "scribefy-mcp"],
      "env": {
        "SCRIBEFY_API_KEY": "sk_live_…"
      }
    }
  }
}

Anywhere else

Any MCP host that supports stdio transport: spawn npx -y scribefy-mcp with SCRIBEFY_API_KEY in the env. The server speaks the standard MCP JSON-RPC over stdin/stdout.

Tools exposed

Four tools. Three are free (research toolkit); only extract_transcript charges credits.

extract_transcript

Pulls the transcript of a YouTube video.

Parameter

Type

Required

Description

url

string

yes

Full YouTube URL — youtube.com/watch?v=…, youtu.be/…, or youtube.com/shorts/…

lang

string

no

BCP-47 language code (e.g. en, es, fr, zh-Hans). Defaults to en

Returns: Markdown with title, channel, duration, language, and the transcript split into segments with timestamps.

Cost: 1 credit (≤15 min) → 8 credits (2 h+). Cached transcripts are free.

search_videos

Free-text YouTube search.

Parameter

Type

Required

Description

query

string

yes

Search query — same syntax YouTube's own search bar accepts

limit

number

no

Max results, 1–25 (default 10)

Returns: Markdown list of title / channel / duration / views / URL for each result.

Cost: Free.

get_video_metadata

Title, channel, duration, view count, upload date, and available caption tracks. Does not pull the transcript.

Parameter

Type

Required

Description

url

string

yes

Full YouTube URL

Returns: Markdown summary plus a list of every caption track (authored ✏ or auto-generated ⚙) with its language code.

Cost: Free. Use this to inspect a video before deciding whether to extract, or to discover which caption languages are available.

get_related_videos

YouTube's "Up next" feed for a video.

Parameter

Type

Required

Description

url

string

yes

Full YouTube URL of the seed video

limit

number

no

Max related videos, 1–25 (default 10)

Returns: Same shape as search_videos.

Cost: Free.

Tools coming in a future release

list_channel_videos and get_video_comments were planned for 0.3.0 but are deferred to 0.4.0 while we wait for upstream youtubei.js to publish fixes for YouTube's 2026 response-shape changes. Channel listing fails with HTTP 400 at the InnerTube layer, and info.getComments() is no longer attached to parsed VideoInfo. Both will return as soon as the library catches up.

Skills

The repo ships an Agent Skill (a SKILL.md your assistant loads on demand) that teaches it how to use these tools well — vet candidates with the free tools before spending credits, prefer authored captions, lean on the free transcript cache, and cite answers with timestamps.

  • skills/youtube-research — the YouTube research workflow: search → vet metadata → extract selectively → synthesize with [mm:ss] citations.

To use it in Claude Code, copy the folder into your project's .claude/skills/ (or ~/.claude/skills/ to have it everywhere). Open Plugins-compatible hosts detect it straight from the repo.

Configuration

Env var

Required

Default

Notes

SCRIBEFY_API_KEY

yes

—

sk_live_… (production) or sk_test_… (Scribefy test mode)

SCRIBEFY_API_BASE

no

https://api.scribefy.app

Override for staging (https://api-staging.scribefy.app) or self-hosted instances

Troubleshooting

SCRIBEFY_API_KEY is required Make sure the env block is set in your MCP host's config and the host actually loads it. Some hosts strip env vars by default — check their docs.

Scribefy rejected the API key Either the key is wrong, the key was revoked, or your subscription is no longer on the API + MCP plan. Check scribefy.app/dashboard.

Not enough credits The tool returns the remaining balance and the cost in the error message. Top up at scribefy.app/pricing.

The tool doesn't show up in my MCP client After editing the config, fully restart the client (not just the chat window). Tail the client's logs if available — most show MCP stderr there. The server prints scribefy-mcp: ready once it boots.

License

MIT

Available Tools

4 tools
extract_transcriptExtract a YouTube transcriptA

Pulls the transcript of a YouTube video and returns it as Markdown with timestamps. Use this whenever the user provides a YouTube URL and wants to summarise, quote, search, or otherwise process the video's spoken content.

Costs credits on first fetch (1 credit ≤15min, 2 credits 15–45min, 4 credits 45min–2h, 8 credits 2h+). Cached extractions are free — videos other Scribefy users have already extracted are cached for 30 days.

Returns the title, channel, duration, language, and the transcript itself split into segments with clickable timestamps.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull YouTube URL — youtube.com/watch?v=…, youtu.be/…, or shorts. Required.
langNoBCP-47 language code for the captions (e.g. 'en', 'es', 'fr', 'zh-Hans'). Defaults to 'en' if omitted.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses costs (credit tiers based on length), caching behavior (30 days free for cached extracts), and return content (title, channel, duration, language, transcript with clickable timestamps). 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.

Conciseness5/5

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

Every sentence is useful: purpose, usage, costs, caching, return structure. No redundancy or fluff. Well-organized into clear paragraphs.

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 no output schema, the description adequately explains what is returned (title, channel, duration, language, transcript with clickable timestamps). Parameter descriptions are covered in schema. No gaps.

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 description coverage is 100%. The description adds extra context to the url parameter with examples (youtube.com/watch?v=…, youtu.be/…, or shorts) and to lang with BCP-47 examples and default. This goes beyond the schema's format and pattern constraints.

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 it pulls a YouTube transcript and returns it as Markdown with timestamps. It uses a specific verb+resource and distinguishes from sibling tools (get_related_videos, get_video_metadata, search_videos) which perform different functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this whenever the user provides a YouTube URL and wants to summarise, quote, search, or otherwise process the video's spoken content.' It does not directly mention when not to use or compare to alternatives, but the use case is clearly defined and siblings are unrelated.

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

get_video_metadataGet metadata for a YouTube video (no transcript)A

Look up title, channel, duration, view count, upload date, and available caption tracks for a video. Does NOT pull the transcript — use extract_transcript for that. Free — no credits charged. Useful to inspect a video before deciding whether to extract, or to discover which caption languages are available.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull YouTube URL (youtube.com/watch?v=…, youtu.be/…, or shorts).

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It states the tool is free and lists what metadata is returned. It does not mention rate limits or auth needs, but for a read-only metadata lookup the transparency is satisfactory.

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 three sentences: what the tool returns, what it does not do (with alternative), and a use case. It is front-loaded and wastes no words.

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's simplicity (one parameter, no output schema), the description adequately explains the expected output and typical use case. No gaps remain for standard usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the single 'url' parameter (100% coverage). The tool description adds no additional parameter-specific semantics beyond the schema, so a baseline score of 3 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 explicitly states the tool looks up title, channel, duration, view count, upload date, and caption tracks. It contrasts with extract_transcript by noting it does NOT pull the transcript, effectively distinguishing from a key 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?

The description provides clear context for when to use this tool: to inspect a video before extracting or to discover caption languages. It explicitly names extract_transcript as the alternative for transcript retrieval, and mentions it's free with no credits charged.

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

search_videosSearch YouTube videos by free-text queryA

Search YouTube for videos matching a query string. Returns up to limit results (default 10, max 25) with title, channel, duration, view count, and URL. Free — no credits charged. Use this when the user asks 'find me videos about X' before chaining into extract_transcript on a specific result.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesFree-text search query. Same syntax YouTube's own search bar accepts.
limitNoMax results to return (1–25, default 10).

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, but description discloses default limit, max, and that it's free. Does not mention sorting or pagination, but the return fields are fully listed.

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?

Two sentences, first states purpose and key behavior, second gives usage guidance. No filler.

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?

For a tool with two well-documented parameters and no output schema, the description covers purpose, behavior, constraints, cost, and chaining instructions completely.

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 covers both parameters with descriptions; description adds valuable context on query syntax (same as YouTube search bar) and default/max for limit.

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 searches YouTube videos by query and lists returned fields. It distinguishes from sibling 'extract_transcript' by mentioning chaining.

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?

Explicitly advises using this tool when user asks to find videos, and to chain with 'extract_transcript' on a result. Also notes it's free and no credits charged.

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.

  1. 4 tool updatesv0.3.5
    • First observedextract_transcript
    • First observedget_related_videos
    • First observedget_video_metadata
    • First observedsearch_videos
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: extracting transcripts, getting related videos, retrieving metadata, and searching. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., extract_transcript, get_related_videos). The verbs vary but the pattern is uniform.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of YouTube video processing. The count is neither too thin nor too heavy.

Completeness5/5

The tool set covers the full workflow: search, metadata inspection, transcript extraction, and discovery of related content. No obvious gaps for the intended use case.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers