Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@douyin-creator-mcp 找出最近7天互动率最高的3条作品"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这是非官方社区工具。 本项目未获抖音或其关联公司授权、认可或背书。项目使用 Playwright 操作浏览器；即使只读取本人账号中真实可见的数据，也可能违反平台条款或触发账号风控。使用前请阅读平台合规与非官方声明，确认已取得所需授权，并先执行风险确认。AGPL 只许可项目代码，不授予任何平台访问权、数据权或商标权。
douyin-mcp 在你的电脑上复用专用 Chrome 登录状态，将抖音创作者中心页面中真实可见的作品和经营指标保存到本地 SQLite，再通过 MCP 提供给支持 MCP 的 AI Agent。
📊 读取真实可见数据增量同步作品列表、播放、点赞、评论、分享、收藏、完播率和涨粉等页面可见指标。 | 🧠 让 Agent 查询和分析查询作品、对比表现、计算互动指标、生成复盘上下文，并导出 JSON 或 CSV。 |
🧾 结论附带证据返回采集时间、缓存新鲜度、字段覆盖率、缺失原因和质量警告，不用猜测值填空。 | 🔒 登录凭证留在本地Cookie 与浏览器状态保存在专用 profile 中，MCP 不向 Agent 返回认证材料。 |
它解决的是一个具体问题：
抖音创作者中心 → 本地结构化数据 → MCP → AI Agent当前范围为 Windows、本机运行、单用户、单抖音账号。本项目不提供多账号托管、云端采集、数据转售、未公开接口抓取，或绕过登录、安全验证、权限及风控的能力。
Related MCP server: douyin-mcp-server
Windows 10/11
Python 3.11 或更高版本
Google Chrome
一个支持 MCP 和终端操作的 Agent
直接告诉 Agent：
帮我克隆并安装 https://github.com/Kuhakucai/douyin-mcp 项目Agent 应克隆项目并运行 easy-install.ps1。脚本会创建项目专用 .venv、安装依赖、生成默认 .env、初始化数据库并执行环境诊断。
首次扫码登录、修改 MCP 客户端配置或同步真实数据前，Agent 应先展示平台风险并征得你的明确确认。
git clone https://github.com/Kuhakucai/douyin-mcp.git
cd douyin-mcp
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e .
Copy-Item .env.example .env
douyin-mcp init
douyin-mcp doctor也可以在已克隆的项目中运行一键脚本：
powershell -ExecutionPolicy Bypass -File .\easy-install.ps1阅读 PLATFORM_COMPLIANCE.md 后，由你明确授权 Agent 执行：
douyin-mcp acknowledge-platform-risk --yes安装结束后，douyin-mcp init 会输出包含本地绝对路径的 mcp_config。将它加入 MCP 客户端，然后重启客户端或新建会话。
通用配置结构如下，实际使用时请以 init 输出为准：
{
"mcpServers": {
"douyin-creator": {
"command": "D:/path/to/douyin-mcp/.venv/Scripts/python.exe",
"args": ["-m", "douyin_creator_mcp.server"],
"env": {
"MCP_TRANSPORT": "stdio",
"DATA_DIR": "D:/path/to/douyin-mcp/data",
"DOUYIN_BROWSER_PROFILE_DIR": "D:/path/to/douyin-mcp/data/browser-profile"
}
}
}
}连接成功并完成风险确认后，可以直接对 Agent 说：
检查我的抖音数据状态。如果还没有登录，打开浏览器让我扫码；
登录后同步作品列表，再分批同步最近 20 条作品详情。
完成后告诉我数据时间、字段覆盖率、缺失项和质量警告。首次需要登录时会打开可见 Chrome。完成扫码或安全验证后，请保持项目专用 Chrome 打开；可以切换到其他软件，但不要切换账号、手动跳转页面或关闭窗口。
首次使用或登录失效时打开可见 Chrome，由用户扫码或完成安全验证。
后续复用项目专用浏览器 profile，通常不需要重复登录。
增量读取虚拟滚动作品列表，保存播放、点赞、评论、分享和收藏等页面可见指标。
按需分批读取作品详情，采集完播率、5 秒完播率、平均观看时长、曝光和涨粉等页面可见指标。
查询作品列表、单条作品表现和历史快照。
对比 2～20 条作品的关键指标。
计算点赞率、收藏率、评论率、分享率、播放率和互动率。
使用透明、带版本的规则进行轻量潜力排序。
生成带数据时间、覆盖率、缺失项和证据引用的复盘上下文。
导出 JSON 或 CSV，便于进一步分析或备份。
返回缓存新鲜度、字段覆盖率、缺失原因和质量警告。
页面未显示的值保存为 null，不会用 0 或猜测值填充。
列表与详情分别保存为快照，不会混写数据来源。
派生比率只使用同一原始快照中的分子和分母，并记录公式版本。
首次成功同步后绑定当前账号，检测到误切账号时拒绝写入。
日常使用时，建议先检查缓存新鲜度，再决定是否打开浏览器同步：
检查我的抖音数据状态。只在缓存过期时更新作品列表和最近 20 条详情；
然后按最近 30 天比较完播率、5 秒完播率和互动率，给出复盘结论。
每条结论都说明数据时间、覆盖率、缺失项和对应作品证据。也可以直接提出具体问题：
“找出最近 30 天互动率最高的 5 条作品，并说明共同点。”
“对比这 3 条视频的完播率、收藏率和涨粉表现。”
“哪些作品值得做续集？说明排序依据和数据局限。”
“导出全部历史快照为 JSON。”
常用命令：
# 首次登录或登录失效
douyin-mcp login --timeout 180
# 同步作品列表
douyin-mcp sync
# 查看作品并取得 video_id
douyin-mcp videos --limit 20
# 每批最多处理 10 条；根据 next_cursor 继续
douyin-mcp details --recent-limit 20
douyin-mcp details --recent-limit 20 --cursor 10
# 查询单条作品表现
douyin-mcp performance <video_id> --period 30d
# 查看登录、缓存、任务和覆盖率
douyin-mcp status命令 | 用途 |
| 初始化目录和数据库，输出 MCP 配置 |
| 检查运行环境，不打开浏览器 |
| 确认已阅读并理解平台自动化访问风险 |
| 打开浏览器并等待登录 |
| 查看登录、缓存、同步任务和覆盖率 |
| 同步作品列表和列表页指标 |
| 分批同步指定或近期作品详情 |
| 分页查询本地作品 |
| 查询单条作品快照和派生指标 |
| 导出 JSON 或 CSV |
| 清除本地数据和专用浏览器 profile |
默认入口提供 13 个浏览器数据工具。
工具 | 用途 |
| 打开可见 Chrome，处理首次登录或重新登录 |
| 查询当前浏览器登录状态 |
| 查询新鲜度、任务、覆盖率、账号绑定和 profile 锁 |
| 按 TTL 同步列表、详情或全部数据 |
| 同步作品列表和列表指标 |
| 分批同步指定或近期作品详情指标 |
| 分页查询作品和最新指标 |
| 查询单作品快照和派生指标 |
| 对比 2～20 条作品 |
| 查询字段覆盖率和缺失原因 |
| 使用透明、带版本的规则进行轻量排序 |
| 生成带证据和警告的复盘上下文 |
| 导出 JSON 或 CSV |
所有工具使用内部账号键 browser-default，Agent 无需传递账号 ID。常见业务状态包括 completed、partial、cache_hit 和 user_action_required。
浏览器操作、数据结构化和 Agent 推理被分成三个清晰层次：
浏览器层：Playwright 操作项目专用 Chrome，读取用户在创作者中心页面中真实可见的内容，不能绕过登录、权限或平台验证。
数据层：本地服务将页面内容规范化为作品、指标快照、同步任务和质量状态，并保存到本机 SQLite。
MCP 层：FastMCP 暴露同步、查询、对比和复盘工具，Agent 不需要直接操作 Cookie 或理解页面 DOM。
MCP Client / Agent
│ stdio
▼
douyin_creator_mcp.server
│
├── BrowserService ── Playwright ── 专用 Chrome profile
│
└── Database ──────── data/douyin.sqlite列表同步负责发现作品和采集列表页指标，详情同步按批次访问作品详情页。两种来源分别保存为快照，不会互相覆盖。
页面显示什么就保存什么；未显示的值为 null，不会用 0 或推测值填充。
写入详情前校验作品身份；无法确认时拒绝写入。
同一批次、同一作品、同一来源只写一个快照；失败同步不会覆盖历史可信快照。
period=30d 等周期按快照采集时间筛选，all 表示全部本地历史。
部分作品可能被平台标记为暂不支持详情数据，此时返回 partial、失败原因和续跑游标。
潜力排序在样本少于 10 条时仅供参考，不代表平台官方评分。
页面 DOM、字段可见性和风控策略可能变化，使用时应关注覆盖率和质量警告。
登录状态保存在 data/browser-profile/，再次启动通常不需要重新扫码。
首次成功列表同步会基于作品标题和发布时间摘要建立不可逆账号指纹，不保存昵称、原始标题或作品 ID 作为身份信息。
检测到账号变化时返回 account_mismatch 并拒绝写入。
同一 profile 同时只允许一个同步进程；死亡进程留下的锁会在安全确认后自动恢复。
确认要更换账号时，运行 douyin-mcp purge --yes，然后重新登录和同步。
data/
├── browser-profile/ # 专用 Chrome 登录状态
├── douyin.sqlite # 作品、指标快照和同步任务
├── exports/ # JSON/CSV 导出
├── reports/ # 本地复盘产物
└── logs/以上目录、数据库、备份和浏览器诊断产物均被 .gitignore 排除，请勿使用 git add -f 提交。
MCP 不会把 Cookie、localStorage、sessionStorage、验证码或账号密码返回给 Agent。但作品信息以及你主动查询的创作数据会进入 Agent 上下文；如果 Agent 使用云端模型，还应遵守对应模型服务的数据政策。
导出与清除：
douyin-mcp export --format json --period all
douyin-mcp export --format csv --period 30d
# 不带 --yes 时只显示确认提示
douyin-mcp purge
douyin-mcp purge --yespurge --yes 会删除数据库、数据库备份、导出、报告和专用浏览器 profile，此操作不可恢复。
激活虚拟环境：
.\.venv\Scripts\Activate.ps1或者直接运行：
.\.venv\Scripts\douyin-mcp.exe doctor下面的执行策略只作用于本次命令：
powershell -ExecutionPolicy Bypass -File .\easy-install.ps1保持项目专用 Chrome 打开，完成扫码、验证码或安全验证，再重试同步。不要使用日常 Chrome profile 替换项目专用 profile。
另一个同步进程仍在使用专用浏览器。等待它结束后重试；如果原进程已经退出，锁会在安全确认后自动恢复。
查看 failures、coverage 和 next_cursor。常见原因包括作品暂不支持详情、页面未展示某项指标，或当前批次仍需继续。
git clone https://github.com/Kuhakucai/douyin-mcp.git
cd douyin-mcp
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e .
python -m pip install pytest
Copy-Item .env.example .envsrc/douyin_creator_mcp/
├── server.py # FastMCP 入口和 browser-only 容器
├── cli.py # 用户 CLI
├── config.py # 环境配置
├── browser/
│ ├── session.py # Playwright 与持久化 profile
│ ├── extractors.py # 列表/详情提取和规范化
│ └── profile_lock.py # 跨进程 profile 锁
├── services/
│ ├── browser_service.py # 同步、查询、对比、复盘和导出
│ └── metrics.py # 派生指标与排序公式
├── storage/
│ ├── db.py # SQLite、迁移与备份
│ └── schemas.sql # 数据表结构
└── tools/
└── browser_tools.py # 13 个 MCP 工具契约
easy-install.ps1 # Windows 一键安装页面读取和 DOM 处理放在 browser/。
可测试的业务逻辑放在 services/。
MCP 工具只做参数声明、服务调用和统一错误响应。
原始数据、派生指标和不同采集来源分开保存。
新字段必须定义缺失语义、数据来源、解析版本和测试样例。
不读取或返回浏览器认证材料，不接入未公开私有接口。
python -m compileall -q src涉及 DOM、指标提取或浏览器生命周期的变更，还应使用测试账号运行：
douyin-mcp doctor
douyin-mcp login --timeout 180
douyin-mcp sync
douyin-mcp details --recent-limit 5
douyin-mcp status验收时应核对登录态复用、页面声明数量、加载数量、解析数量、重复同步幂等性、详情身份校验、覆盖率和失败原因。真实账号数据和验收产物不得提交到仓库。
douyin-mcp 是独立维护的第三方开源项目，不是抖音、字节跳动或其关联公司的官方、授权、认证或合作产品。
抖音用户服务协议第 2.4、5.1、5.3 和 7.1 条涉及非商业许可、自动化访问、平台外处理或展示信息、向第三方提供信息以及账号处置风险。用户必须自行确认拥有合法账号、数据访问权，以及自动化访问、平台外处理或展示、向 Agent 或模型服务提供数据所需的全部书面授权。完整说明见平台合规与非官方声明。
本项目不会通过 MCP 返回 Cookie、localStorage、sessionStorage、验证码或账号密码，但作品信息和经营数据可能进入 MCP 客户端及 Agent 上下文。“本机运行”不代表业务数据一定不会离开本机。
项目基于 GNU Affero General Public License v3.0（AGPL-3.0-only）开源。AGPL 允许商业使用代码，但修改版分发及网络交互场景需要按许可证提供对应源代码。许可证不授予抖音平台访问权、数据权、商业使用平台或数据的权利，也不授予商标权。
Copyright (C) 2026 Kuhakucai。Kuhakucai 与 Puppetsho 是同一作者使用的 Git 提交身份，详见 AUTHORS.md。
欢迎提交 Issue 和 Pull Request。开始前请阅读：
在相同来源和时间语义下对比 2 至 20 条作品。
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 30d | |
| metrics | No | ||
| video_ids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions the range 2-20 and the constraints of same source/time, but does not disclose side effects, authorization needs, rate limits, or what happens if constraints are violated. The output schema exists but is not referenced in the description.
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 a single sentence, which is concise, but it lacks structure such as a breakdown of input parameters or output. It is not overly long, but the brevity sacrifices clarity.
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 has 3 parameters and an output schema, the description is incomplete. It does not explain how to set period or metrics, or what the output provides. With many sibling tools, more context is needed for correct selection and 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 0%, so the description must explain parameters. However, it only alludes to video_ids via the count 2-20, and does not describe period, metrics, or their meanings. The agent cannot infer correct usage without additional information.
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 states the tool compares 2 to 20 videos under the same source and time semantics, clearly distinguishing it from sibling tools like list_videos or get_video_performance. The verb 'compare' and resource 'videos' are specific. However, it is in Chinese and could be more explicit about what aspects are compared.
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?
No guidance is provided on when to use this tool versus alternatives such as rank_video_potential or get_video_performance. There is no mention of prerequisites, exclusions, or context that would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
导出本地快照和派生指标；V1 支持 JSON 与 CSV。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json | |
| period | No | all | |
| output_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It does not mention whether the export is read-only, destructive, or requires specific authentication. The term 'local' suggests data is exported from a local cache, but this is unclear.
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 very short—two sentences—with no redundant words. However, it omits critical details, sacrificing substance for brevity.
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 moderate complexity (3 parameters, output schema exists), the description is insufficient. It does not explain return values, parameter constraints, or how to handle different periods. Agents lack enough information to use the tool correctly.
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 0%, and the description only hint at the format parameter by mentioning JSON and CSV. The 'period' and 'output_path' parameters are entirely unexplained, leaving agents to guess their meaning.
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 exports local snapshots and derived metrics, and mentions supported formats (JSON and CSV). It distinguishes itself from sibling tools which focus on login, sync, listing, and analysis.
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 provides no guidance on when to use this tool versus other tools, no prerequisites, and no context about typical usage scenarios. Agents must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
为 Agent 返回带覆盖率、警告和证据引用的复盘上下文。
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | potential | |
| period | No | 30d | |
| recent_limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as side effects, authentication requirements, rate limits, or whether the tool is read-only or mutates data.
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 extremely concise (one short sentence) with no wasted text. However, it omits important information about parameters and usage, making it under-specified rather than appropriately 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?
Even with an output schema, the description fails to explain the three optional parameters or provide enough context for the agent to understand when and how to invoke the tool. The description alone is insufficient for a tool with 3 undocumented parameters.
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 0%, and the description does not mention any of the three parameters (focus, period, recent_limit) or their meaning, defaults, or allowed values. This leaves the agent without necessary context for correct parameter use.
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 review context with coverage, warnings, and evidence citations. The verb 'generate_review' plus the description specify the output, making it clear. However, it does not distinguish from sibling tools like 'rank_video_potential' or 'get_metric_coverage'.
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?
No guidance on when to use this tool versus alternatives. The description only states what it does, with no when-to-use, when-not-to-use, or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询关键指标覆盖率和数据质量警告。
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 30d |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or output format. The tool name implies browser automation but no specifics are given.
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 a single sentence, which is concise but overly sparse. It could include parameter details or usage context without significant bloat. Every sentence earns its place, but more information is needed.
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 has one optional parameter and an output schema, the description is incomplete. It does not explain the output, usage context, or how it fits with sibling tools. The agent would lack sufficient information to use it correctly.
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?
The input schema has one parameter 'period' with no description (0% schema coverage). The tool description does not explain the parameter's meaning or valid values, leaving the agent without guidance on what to provide.
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 queries key metric coverage and data quality warnings. The verb 'query' and resource 'metric coverage and data quality warnings' are specific. However, 'metric coverage' is ambiguous and could be clarified. It distinguishes from sibling tools that handle login, sync, lists, etc.
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?
There is no guidance on when to use this tool versus alternatives. The sibling tools include many for different purposes, but the description does not specify the context or prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取本地缓存、同步任务、指标覆盖率和 profile 锁状态，不打开浏览器。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately conveys key behavior: it is a read-only operation that does not open the browser. It lists the specific status items, adding context beyond the schema.
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?
Single, front-loaded sentence with no wasted words. Every element contributes to understanding the tool's purpose and behavior.
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 simple status tool with no input parameters and an output schema present (context indicates it exists), the description covers essential behavioral aspects. It could mention that the output includes the listed statuses, but the output schema presumably handles that.
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?
There are zero parameters; the description does not need to explain them. Baseline 4 is appropriate as it adds no burden.
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 it reads local cache, sync tasks, metric coverage, and profile lock status without opening the browser. This differentiates it from sibling tools that perform login, sync, or video fetching actions.
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 implicitly suggests using this tool to check status without browser action, but it does not provide explicit when-to-use versus when-not-to-use guidance or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询单条作品的列表、详情快照及派生指标。
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 30d | |
| video_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only lists what it returns without mentioning side effects, data freshness, authentication needs, or any constraints. It does not clarify if it is a read-only operation.
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 single sentence is concise but at the expense of valuable information. It front-loads the purpose but omits critical details about parameters and usage.
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 annotations, low schema coverage, and many sibling tools, the description is incomplete. It lacks parameter explanations and usage context, though the output schema may cover return values.
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 0%, and the description adds no meaning to the parameters. It does not explain the 'period' parameter's purpose, format, or default value, nor does it describe 'video_id' beyond the schema.
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 states it queries a single video's list, detail snapshot, and derived indicators. This specifies the verb and resource clearly and distinguishes from listing multiple videos or syncing details.
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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparison with sibling tools like douyin_browser_list_videos or douyin_browser_sync_video_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分页查询本地作品和最新列表指标快照。
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | publish_time_desc | |
| limit | No | ||
| offset | No | ||
| filters | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description does not disclose any behavioral traits beyond pagination, such as read-only nature, rate limits, or side effects.
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 a single short sentence, which is concise but omits important details; it is not structured for easy scanning.
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 4 parameters with no schema descriptions and no annotations, the description lacks essential context like pagination behavior or filter usage; an output schema exists but is not leveraged.
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 0%, and the description does not explain any parameters (sort, limit, offset, filters), leaving the agent without necessary context for their usage.
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 performs a paginated query for 'local works and latest list indicator snapshots', which distinguishes it from sibling tools like comparison or performance tools.
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?
No guidance on when to use this tool vs alternatives, no when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
确认平台风险后打开可见浏览器；首次登录或登录过期时需要扫码。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it opens a visible browser and requires QR code scanning. However, it lacks details on error handling, what happens if already logged in, side effects, or authentication requirements beyond scanning. More behavioral context is needed.
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 a single, compact sentence that conveys the core purpose and usage condition without waste. It is front-loaded and every part earns its place.
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 zero parameters and an output schema, the description is minimal. It does not explain what 'confirming platform risk' entails, specify prerequisites, or describe behavior on failure. For a login operation, more context about synchronous/asynchronous nature and expected outcomes would improve completeness.
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?
There are no parameters, so baseline 4 applies. The description adds no parameter info because none exist, and the schema coverage is complete. Nothing to deduct.
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 that the tool opens a visible browser for login after confirming platform risk, and specifies when it is needed (first login or expired login). The resource and verb are specific, and it distinguishes itself from siblings like status checking and data sync.
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 implies usage scenarios: when first logging in or after login expires, after platform risk confirmation. It does not explicitly state when not to use or mention alternatives like checking login status first, but the context provides a reasonable usage clue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询当前可见浏览器会话中的登录状态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states 'query' (implied read-only) but does not clarify side effects, required permissions, or the nature of the return value beyond what the output schema may provide.
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 a single sentence that conveys the core purpose without any superfluous words. It is optimally concise for a straightforward tool.
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 simplicity (no parameters, output schema exists), the description adequately explains its purpose. However, a brief note about expected return values (e.g., boolean or string) would enhance completeness, though not strictly required.
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?
With zero parameters, the description has no need to explain parameter semantics. The tool is parameterless, and the description appropriately addresses this minimal interface.
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 verb '查询' (query) and the resource '登录状态' (login status), specifically targeting the currently visible browser session. It effectively distinguishes from sibling tools like 'douyin_browser_login_start' and 'douyin_browser_get_status' by focusing solely on login status.
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?
No guidance is provided on when to use this tool versus alternatives, nor does it mention prerequisites or context. The description simply states what it does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按有版本的透明规则生成轻量潜力排序。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| period | No | 30d | |
| weights | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions 'lightweight' and 'versioned transparent rules,' but does not disclose side effects, auth requirements, rate limits, or what happens to data. This is insufficient for the agent to understand 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?
The description is a single sentence, which is concise, but it lacks sufficient detail. While brevity is positive, it does not earn its place because it omits critical information needed for correct tool use.
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 tool with 3 parameters and no enum constraints, the description is too thin. Even though an output schema exists, the description fails to explain what 'potential' means, how weights affect results, or what period options are valid. The agent would struggle to use this correctly.
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?
The input schema has 3 parameters with 0% description coverage, and the description does not explain any parameter semantics. The agent gets no help understanding 'limit', 'period', or 'weights' beyond their types and defaults.
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 states that it generates a lightweight potential ranking, which gives a basic idea of the tool's purpose. However, the term 'potential' is undefined, and it does not differentiate from sibling tools like 'douyin_browser_list_videos' or 'douyin_browser_get_video_performance'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
确认平台风险后同步作品列表及页面可见指标。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | visible | |
| force | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it syncs data after risk confirmation, lacking details on side effects, mutability, failure modes, rate limits, or what 'sync' entails (e.g., overwrite or append). This is insufficient for safe agentic invocation.
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 a single short sentence, which is concise but at the expense of omitting critical details. It front-loads the core action but lacks structure and completeness.
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 schema descriptions, no annotations, an output schema (content unknown), and many sibling tools, the description is severely incomplete. It fails to explain the tool's role within the family, parameter semantics, or return value structure.
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 0% and the description does not explain the two parameters (mode, force). The agent has no information about their purpose, allowed values, or impact on tool behavior.
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 syncs a list of works and visible metrics after risk confirmation. It identifies the action (sync) and resource (creator data). However, it does not differentiate from sibling tools like douyin_browser_sync_video_details or douyin_browser_sync_if_needed, which also perform syncing.
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?
No explicit guidance on when to use this tool versus alternatives. The description mentions a prerequisite (confirming platform risk) but does not specify when to use it instead of other sync tools or the expected context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
确认平台风险后，仅在缓存过期时同步列表、详情或全部数据。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | background_first | |
| scope | No | list | |
| recent_limit | No | ||
| max_age_hours | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates the tool is conditional and syncs data, but does not disclose authentication needs, rate limits, or side effects beyond the implied cache expiration logic.
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?
Single sentence with no wasted words. However, it could be structured more clearly with explicit parameter references.
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?
Despite an output schema existing, the description omits explanations for 4 parameters with no schema descriptions. It lacks details on parameter semantics and usage context, making it insufficient given the complexity.
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 0%. The description hints at 'scope' through 'list, details, or all', but does not explain 'mode', 'recent_limit', or 'max_age_hours'. Partial value for scope, but insufficient for other three parameters.
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 syncs data (list, details, or all) when cache expires after confirming platform risk. It gives a specific verb and resource, but does not explicitly distinguish it from sibling sync tools like douyin_browser_sync_creator_data, though the scope 'list, details, or all' partially differentiates.
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 mentions conditional execution ('after confirming platform risk' and 'only when cache expires'), providing implicit guidance on when to use. However, it lacks explicit when-not-to-use instructions or comparison to alternative sync tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
确认平台风险后分批采集作品详情页指标。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | visible | |
| force | No | ||
| cursor | No | ||
| video_ids | No | ||
| batch_size | No | ||
| recent_limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only hints at batch operation and risk confirmation, lacking details on safety, authentication, or side effects.
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?
Extremely concise (one sentence) but lacks structure; front-loads the prerequisite but omits essential information like parameter details.
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?
With 6 parameters, no schema descriptions, and zero behavioral context, the description is far too incomplete for agents to invoke correctly.
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 has 6 parameters with 0% description coverage; the description adds no meaning to any parameter, leaving their purpose entirely undocumented.
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 verb 'collect' and resource 'work detail page indicators' in batches, but does not specify what indicators are or clearly distinguish from siblings like douyin_browser_get_video_performance.
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?
Mentions prerequisite 'after confirming platform risk' but provides no guidance on when to use this tool vs alternatives or when not to use it.
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. Dates show when Glama detected each change.
v0.1.0douyin_browser_compare_videosdouyin_browser_export_datadouyin_browser_generate_reviewdouyin_browser_get_metric_coveragedouyin_browser_get_statusdouyin_browser_get_video_performancedouyin_browser_list_videosdouyin_browser_login_startdouyin_browser_login_statusdouyin_browser_rank_video_potentialdouyin_browser_sync_creator_datadouyin_browser_sync_if_neededdouyin_browser_sync_video_detailsScored across 13 tools
Most tools have distinct purposes, but there is some overlap among sync operations (sync_if_needed, sync_creator_data, sync_video_details) and status checks (get_status vs login_status), which could cause minor confusion.
All tools use snake_case with the 'douyin_browser_' prefix, but the verb patterns are not fully uniform (e.g., 'sync_if_needed' uses a condition, while others use straightforward verb_noun). Overall readable.
13 tools is a reasonable number for a Douyin creator MCP covering login, data sync, retrieval, analysis, and export. No obvious bloat or deficiency.
The tool set covers the core workflow (login, sync, list, compare, rank, review, export) for browser-based data access. Missing create/update operations, but these are outside the intended read-only analysis scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server: AI-agent access to Chinese social & trend signals — Douyin, Weibo, Xiaohongshu/RedNote,
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for ByteDance Seedance AI video generation
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/caidabai123/douyin-creator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server