Skip to main content
Glama
README.md
# video-mcp — 视频文案提取 + 总结 MCP 服务

多平台视频 MCP:贴链接 → 提取字幕/口播文案 → 服务端蒸馏 → 只回 Markdown 摘要(省 token)。

> 背景:上游 yzfly/douyin-mcp-server 已于 2026-07-02 归档,解析代码在 2026-09 抖音 SSR 改版后失效。此为 fork 修复自建版(vault 镜像,服务器部署在 `/home/jerry/video-mcp`)。

## 工具

| 工具 | 参数 | 返回 |
|---|---|---|
| `summarize_video` | `url`, 可选 `lang` | Markdown 摘要(标题/要点/结论/时间戳),全文不进对话 |
| `get_transcript` | `url`, 可选 `out_dir` | 全文文本 + 落盘 `.md` 文件路径 |

平台自动识别:B站(`bilibili.com`/`b23.tv`)、YouTube(`youtube.com`/`youtu.be`)、抖音(`douyin.com`/`v.douyin.com`)。

## 引擎与配置(环境变量)

| 变量 | 默认 | 说明 |
|---|---|---|
| `ASR_API_KEY` | 必填 | 硅基流动 key(SenseVoice 口播转写;复用 douyin-mcp 那把) |
| `LLM_BASE_URL` | `https://api.deepseek.com/v1` | OpenAI 兼容端点;服务器上指 `http://127.0.0.1:8080/v1` 用本地 Qwen3.8 |
| `LLM_API_KEY` | 必填 | 对应端点 key(本地 llama.cpp 可任意非空) |
| `LLM_MODEL` | deepseek-chat | 模型名 |
| `LLM_CTX` | 200000 | 超过此 token 的字幕自动分段 map-reduce(默认单段直给,本地 Qwen3.8 200K 无需分段) |
| `DOUYIN_ENGINE` | `browser` | `browser`(本机 Kimi WebBridge 抓签名流)/ `tiktokdownloader`(规划中) |

## 抖音引擎说明(browser 模式)

抖音无公开字幕。`browser` 引擎复用本机真实浏览器会话(需先启动 Kimi WebBridge 守护进程 `~/.kimi-webbridge/bin/kimi-webbridge start`,浏览器需保持打开):

1. 新标签打开 `douyin.com/video/{id}`,等待视频元素就绪
2. Performance API 提取签名音频流(media-audio-*)URL
3. 下载 → ffmpeg(imageio-ffmpeg 自带静态二进制)转 wav
4. SenseVoice(硅基流动)→ 文案 → LLM 蒸馏

已知局限:依赖本机浏览器进程;服务器端自动化引擎(TikTokDownloader)为 TODO。

## 本地跑(stdio)

```bash
uv sync   # 或 uv run video-mcp
ASR_API_KEY=sk-... LLM_API_KEY=sk-... uv run video-mcp
```

## 服务器部署(规划)

```bash
# HTTP 模式
uv run video-mcp --transport http --host 127.0.0.1 --port 8310
# systemd 或 docker + Tailscale Serve 转发 → claude mcp add-remote / astrbot MCP 添加
```

## 验证记录

- 2026-09-05:手动链路全通(浏览器签名流 → ffmpeg → SenseVoice → 总结);B站/抖音在 Mac(webbridge)与 Linux 服务器(CDP headless Chromium)双端实测通过
- 上游 yzfly/douyin-mcp-server 2026-07-02 归档,解析失效(KeyError 'videoInfoRes'),故自建本项目

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation4/5

The two tools are related but have clear output differences: get_transcript writes the full transcript to a file, while summarize_video generates a Markdown summary. An agent could confuse them in edge cases, but the descriptions clarify their distinct purposes.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern in snake_case: get_transcript and summarize_video. This is fully consistent and predictable.

Tool Count3/5

Two tools is minimal for a video-focused MCP server, covering only transcription and summarization. It is not an extreme mismatch, but the surface feels thin for the broad 'video-mcp' name.

Completeness4/5

For the apparent purpose of extracting video transcripts and generating summaries, the two core workflows are covered. However, there is no direct way to retrieve the full transcript inline, which is a minor but workable gap.

Maintenance

ActivityMaintained
ResponsivenessNo issues