YouTube URL을 붙여넣고 자막을 가져오세요. 가입 없이 깔끔한 텍스트를 얻을 수 있습니다.
모든 YouTube 페이지에서 클릭 한 번으로 자막을 추출하세요. 다양한 출력 형식(RAG, JSON, Markdown)을 지원합니다.
rippr을 Claude, Cursor 또는 MCP 호환 클라이언트에 연결하세요. 각 자막을 ~/rippr/transcripts/에 저장하고 파일 경로를 모델에 반환합니다.
데스크톱 클라이언트 전용. rippr은 로컬 stdio 프로세스로 실행되므로 Claude Desktop, Claude Code CLI 및 Cursor에서 작동합니다. 로컬 프로세스를 생성할 수 없는 클라우드 호스팅 클라이언트(웹상의 claude.ai, Claude 모바일 앱 또는 휴대폰/웹상의 Claude Code)에서는 작동하지 않습니다.
npx rippr-mcpClaude Desktop에 추가 (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"rippr": {
"command": "npx",
"args": ["-y", "rippr-mcp"]
}
}
}그런 다음 다음과 같이 요청하세요: "Rip this YouTube video: [url]". 전체 도구 인터페이스는 mcp/README.md를 참조하세요.
Related MCP server: xendit-mcp
RAG (.txt) — 청킹 및 임베딩에 최적화된 단일 연속 텍스트 블록
Structured (.json) — 메타데이터가 포함된 타임스탬프 세그먼트
Readable (.md) — 헤더와 서식이 포함된 마크다운
최대 신뢰성을 위한 다중 전략 추출:
Innertube API — YouTube 내부 플레이어 API (Android 클라이언트)
HTML 스크래핑 — 페이지 소스에서 ytInitialPlayerResponse 파싱
자막 패널 — 최후의 수단으로 YouTube 내장 자막 패널 열기
다양한 형식(srv3, timedtext, JSON3)으로 파싱된 캡션 XML. 일시적인 오류 발생 시 지수 백오프(exponential backoff)를 사용하여 재시도합니다.
사용자의 컴퓨터에서 완전히 실행됩니다. 외부 서버로 데이터가 전송되지 않습니다. 계정이나 추적 기능이 없습니다. YouTube 자체 API와만 통신합니다.
MCP | 기능 |
AI를 위한 일본어 UX 규칙: 양식, 경어, 타이포그래피, 신뢰 신호 | |
라쿠텐 마켓플레이스, 도서 및 호텔 검색 | |
Xendit 결제 API: 인보이스, 지급, 잔액 |
Rippr은 커뮤니티에서 제작한 비공식 도구입니다. YouTube 또는 Google LLC와 제휴, 보증 또는 후원 관계가 아닙니다. YouTube는 Google LLC의 상표입니다.
Rippr은 YouTube 자체 앱이 사용하는 엔드포인트를 통해 공개적으로 사용 가능한 YouTube 자막 데이터에 액세스합니다. 사용은 YouTube 서비스 약관의 적용을 받으며, 사용에 따른 위험은 사용자 본인에게 있습니다. 작성자는 서비스 중단, 속도 제한, 계정 조치 또는 기타 사용 결과에 대해 어떠한 책임도 지지 않습니다.
YouTube가 추출을 방해하는 방식으로 내부 API를 변경할 경우, 예고 없이 도구가 작동하지 않을 수 있습니다. 장기적인 프로덕션 사용을 위해서는 API 키를 사용하는 공식 YouTube Data API v3를 고려하십시오(현재 이 패키지에서는 지원되지 않음).
Extract the full transcript from a YouTube video. By default, saves the transcript as a Markdown file to disk and returns a resource_link + metadata (title, channel, language, duration, word count, saved path, preview). The full transcript text is NOT returned by default — this keeps context lean and gives the user a persistent file they can reuse. After calling, always tell the user where the file was saved. If you need the transcript text later (summarize, search, extract quotes), read the returned resource rather than re-ripping. Pass return_text: true only for short clips or when the user explicitly asks for the transcript inline. Pass format: 'segments' to save timestamped JSON instead of Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL. Supports any YouTube URL format (watch, youtu.be, embed, shorts, or bare 11-char ID). | |
| format | No | Saved file format. 'text' writes a Markdown file with YAML frontmatter and a continuous transcript block (best for RAG/LLM). 'segments' writes a JSON file with timestamped segments (best for chapter markers, precise citations). Default: text. | |
| save_path | No | Optional override for where to save the transcript. Can be an absolute path, a ~/-relative path, a directory (file is named automatically), or a full file path. When you save outside the default directory, the returned resource_link still points to the saved file so it can be read later. Default: ~/rippr/transcripts/<slug>_<videoId>.<ext> | |
| return_text | No | If true, include the full transcript text in the tool response alongside the resource_link. Default: false. Use true only for short clips or when the user explicitly wants the transcript inline. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses default behavior (saves file, does not return text), rationale (keep context lean, persistent file), and side effects (saves to disk). Could explicitly mention idempotency or rate limits, but overall strong.
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?
Seven sentences, all contributing meaningful information. Front-loaded with purpose and key behavioral notes. No redundant or unnecessary content.
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?
Covers all critical aspects: default behavior, parameter usage, post-call action (tell user where saved). No output schema, but description is sufficient for agent to correctly invoke and follow up. Minor missing detail on resource_link format, but not essential.
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 100%, but description adds significant value: explains default behavior for format and return_text, supported URL formats, and save_path resolution details. Provides usage recommendations that go beyond schema descriptions.
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 states 'Extract the full transcript from a YouTube video' with a specific verb and resource, clearly defining the tool's function. No sibling tools exist, so differentiation is not an issue.
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: default saves file and returns metadata, advises against re-ripping by reading resource, specifies when to use return_text (short clips or explicit request) and format alternatives. Covers context and exclusions thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0rip_transcript4 fields changedInput schema / properties / format / descriptionPrevious value: -"Output format. 'text' returns a single continuous string (best for RAG/LLM). 'segments' returns timestamped segments. Default: text."New value: +"Saved file format. 'text' writes a Markdown file with YAML frontmatter and a continuous transcript block (best for RAG/LLM). 'segments' writes a JSON file with timestamped segments (best for chapter markers, precise citations). Default: text."Input schema / properties / return_textAdded value: +{
+ "description": "If true, include the full transcript text in the tool response alongside the resource_link. Default: false. Use true only for short clips or when the user explicitly wants the transcript inline.",
+ "type": "boolean"
+}Input schema / properties / save_pathAdded value: +{
+ "description": "Optional override for where to save the transcript. Can be an absolute path, a ~/-relative path, a directory (file is named automatically), or a full file path. When you save outside the default directory, the returned resource_link still points to the saved file so it can be read later. Default: ~/rippr/transcripts/<slug>_<videoId>.<ext>",
+ "type": "string"
+}Input schema / properties / url / descriptionPrevious value: -"YouTube video URL (e.g., https://www.youtube.com/watch?v=... or https://youtu.be/...)"New value: +"YouTube video URL. Supports any YouTube URL format (watch, youtu.be, embed, shorts, or bare 11-char ID)."v1.0.0rip_transcriptScored across 1 tool
With only one tool, there is no possibility of confusion. The single tool 'rip_transcript' has a clear and distinct purpose.
The single tool name 'rip_transcript' follows a consistent verb_noun pattern. No naming conflicts exist.
The server has only one tool, which is minimal but acceptable given its focused purpose of ripping YouTube transcripts. While slightly under-scoped, it provides a complete interface for its intended function.
The tool covers the core task of transcript extraction with options for format and inline text. However, it lacks complementary tools such as listing videos or batch processing, leaving minor gaps.
YouTube transcripts, video search, chapters and extractive summaries. No YouTube API key, no LLM.
YouTube transcripts for AI agents: text, JSON, SRT, or VTT in 150+ languages, with AI fallback.
Transcripts from YouTube videos, whole channels and playlists for AI agents, with bulk ZIP export.
YouTube transcripts for AI agents, including videos without captions (Pro API key).