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., "@toutiao-mcp 请帮我登录今日头条并发布文章，标题：测试标题，内容：测试内容，封面：/tmp/cover.png"
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.
一个 MCP（Model Context Protocol）服务器，通过 Puppeteer 浏览器自动化向今日头条发布文章：扫码登录、上传封面图、填写标题与正文、点击发布，全程模拟真人操作，无需头条开放平台 API Key。
发布机制学习自 jiaqi-lyu-de/news-autopublish-mcp，并做了精简（去掉新闻抓取模块，只保留头条发布能力）。
AI 客户端（Claude Desktop / 支持 MCP 的应用）
│ ① 调用 toutiao_login（返回二维码图片）
│ ② 用户手机扫码，Cookie 自动保存到 ~/.toutiao-mcp/cookies.json
│ ③ 调用 toutiao_publish_article(title, content, imagePath)
▼
Puppeteer 打开真实浏览器（复用系统 Chrome/Edge）
▼
打开头条 → 注入 Cookie 校验登录 → 点击"发布" → 上传封面图 → 填标题正文 → 点击发布Related MCP server: toutiao_mcp_server
使用者不需要 clone 代码、不需要 npm install，只需在 MCP 客户端配置里加一段，首次运行由 npx 自动拉取：
{
"mcpServers": {
"toutiao": {
"command": "npx",
"args": ["-y", "@the-thing/toutiao-mcp@latest"]
}
}
}使用者环境要求（只需满足两点）：
已安装 Node.js 18+（npx 随附）
本机装有 Google Chrome 或 Microsoft Edge（自动探测；或设置环境变量 PUPPETEER_EXECUTABLE_PATH 指向浏览器可执行文件）
登录 Cookie 位置：
~/.toutiao-mcp/cookies.json（用户主目录，跨项目共享登录态），登录后自动生成，无需手动配置。
git clone https://github.com/JessYan0913/toutiao-mcp.git
cd toutiao-mcp
npm install
npm run inspect # 打开 MCP Inspector 调试toutiao_login）调用后会自动弹出浏览器窗口并显示今日头条登录二维码，用手机「今日头条 / 抖音」App 扫码确认：
扫码成功后系统自动保存 Cookie，无需其他操作
二维码会同时以图片形式返回给 AI 客户端，可直接在对话界面展示
最长等待 5 分钟，超时需重新调用
toutiao_check_status，可选但推荐）用无头浏览器验证当前 Cookie 是否有效，返回 { isLoggedIn: true/false }。已登录时会自动刷新保存最新 Cookie。
toutiao_publish_article）必填参数：
参数 | 说明 | 约束 |
| 文章标题 | 2~30 个字，超出会被拒绝 |
| 文章正文 | 纯文本，自动填入富文本编辑器 |
| 本地封面图片路径 | 绝对路径，文件必须存在 |
发布完成后浏览器窗口会保留约 20 秒，请在浏览器中确认发布结果（建议手动检查一次是否成功上架）。
1. 请帮我登录今日头条（调用 toutiao_login）
2. 确认登录成功后，发布一篇头条文章：
- 标题：xxx
- 正文：xxx
- 封面图：C:\Users\me\Pictures\cover.png
（调用 toutiao_publish_article）工具 | 说明 | 参数 |
| 打开浏览器获取登录二维码并等待扫码，成功后自动保存 Cookie | 无 |
| 无头浏览器验证当前登录态，已登录时刷新 Cookie | 无 |
| 删除本地 Cookie（登出） | 无 |
| 发布文章：封面图 + 标题 + 正文，触发发布 |
|
校验图片路径存在、标题字数 2~30
启动有头浏览器 + 抗检测（隐藏 navigator.webdriver、伪装 Chrome UA、真实分辨率）
注入 Cookie → 校验登录态（未登录直接报错）
首页鼠标「移动 → 悬停 → 点击」发布图标，捕获新弹出的发布窗口
上传封面：点击上传区 → 弹窗上传按钮 → FileChooser 注入图片路径 → 等待处理 → 确认
标题输入框三击全选清空后键入；正文富文本编辑器 focus 后键入
点击发布按钮（连点两次兜底），返回成功
toutiao-mcp
├── client.js # 冒烟测试：列出已注册工具（node client.js）
├── src
│ ├── server.js # MCP server 入口（stdio 传输，注册 4 个工具）
│ ├── toutiao
│ │ ├── login.js # 扫码登录 + 后台轮询监听 + 自动存 Cookie
│ │ ├── status.js # 登录态判定（无头浏览器）
│ │ ├── logout.js # 登出（删 Cookie 文件）
│ │ └── publish.js # 核心：七步发布流程（Puppeteer 自动化）
│ └── utils
│ ├── browser.js # 浏览器启动：自动探测系统 Chrome/Edge（跨平台）
│ └── cookies.js # Cookie 持久化（~/.toutiao-mcp/cookies.json）
└── scripts # 调试与命令行辅助脚本现象 | 原因与处理 |
报错「未找到可用的 Chrome/Edge 浏览器」 | 本机未装 Chrome/Edge，或安装位置特殊；安装浏览器，或设置环境变量 |
报错「未发现登录信息或登录已失效」 | Cookie 过期，重新调用 |
发布后浏览器里没有文章 | 头条前端改版导致选择器失效；需在 |
登录后 Cookie 在哪 |
|
非官方通道：浏览器自动化模拟人工操作，违反今日头条平台用户协议，账号存在被风控/封禁的风险，请使用小号测试。
选择器脆弱：发布流程依赖硬编码 CSS 类名（集中在 src/toutiao/publish.js 顶部 TOUTIAO_CONFIG.selectors），头条前端改版后需同步更新。
需要图形环境：登录/发布使用有头浏览器，服务器部署需虚拟显示（如 Windows 桌面、Xvfb）。
凭证安全：Cookie 含敏感会话凭证且明文存储，请勿提交到仓库、注意保管。
ISC
检查今日头条登录状态（无头浏览器验证当前 Cookie 是否有效），已登录时会刷新本地 Cookie。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the use of a headless browser and a notable side effect: refreshing local cookie when logged in. However, it does not mention behavior on invalid cookie or error handling, so it's good but not exhaustive.
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, front-loaded with the primary action, and efficiently conveys both the mechanism and the side effect without waste.
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?
The core purpose and side effect are covered. However, the return value or status format is not described, and there's no output schema to compensate. For a simple tool this is a minor gap, but the description remains largely complete for 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?
The tool has zero parameters, so schema coverage is trivially 100%. Per the calibration baseline, 0 params earns a 4; the description appropriately adds no parameter details since there are none to clarify.
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's function: checking Toutiao login status via headless browser to validate cookie validity. It is a specific verb+resource action, and the mention of headless browser and cookie refresh distinguishes it from sibling tools like login/logout/publish.
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 when-to-use or alternative guidance is provided. The purpose implies usage for verifying login status before actions like publishing, but this is inferred rather than stated, lacking exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
登录今日头条：打开浏览器获取登录二维码并等待扫码，扫码成功后自动保存 Cookie 到本地 cookies.json。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It explains the main steps: opening a browser, obtaining a QR code, waiting for scanning, and automatically saving cookies to cookies.json. This is a meaningful side effect disclosure, though it omits potential timeout behavior or error handling.
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, front-loaded sentence that efficiently communicates the action, purpose, and side effect without extraneous 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?
The description provides a comprehensive overview of the login process and its side effect, which is sufficient given the lack of an output schema. It could explicitly mention that login is a prerequisite for sibling tools, but this is a minor omission.
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 schema has zero parameters, so the baseline is 4. The description does not need to add parameter details because none exist, and it does not attempt to explain any.
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 specific verb '登录' (login) and the resource '今日头条' (Toutiao), and outlines the login flow: open browser, get QR code, wait for scan, and save cookie. This distinctly separates it from sibling tools like check_status, logout, and publish_article.
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 the tool is for authenticating before using Toutiao-related operations, but it does not explicitly state when to use it versus alternatives. No exclusions or conditional guidance are provided, leaving usage context lightly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
退出登录：删除本地保存的 Cookie 文件 cookies.json。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the destructive action of deleting the local cookie file, which is transparent about the side effect. It does not need to mention permissions or reversibility for such a simple local 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 description is a single, concise sentence that front-loads the action and purpose. Every word earns its place, with no wasted or redundant 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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete. It accurately tells the agent what the tool does and the consequence, leaving no significant gaps for this scope.
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 is empty with zero parameters, so the baseline is 4. The description does not need to add parameter details since there are none, and it clearly explains the tool's action.
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 uses a specific verb '退出登录' (logout) and specifies the resource '删除本地保存的 Cookie 文件 cookies.json' (deleting local cookie file). It clearly states the tool's function and distinguishes it from siblings like login and check_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?
The description clearly implies the tool is used when a user wants to log out by deleting the local cookie file. While it does not explicitly mention when not to use it or name alternatives, the context is clear given the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发布今日头条文章：通过浏览器自动化设置封面图、标题与正文并触发发布。需要先登录（cookies.json 存在且有效）。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 文章标题（2-30 个字） | |
| content | Yes | 文章正文 | |
| imagePath | Yes | 本地封面图片路径（建议绝对路径） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the browser automation mechanism and login requirement, which is useful. However, it omits behavioral details such as whether publishing is immediate, what happens on failure, or if the tool waits for success confirmation.
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 packs the core action, mechanism, and prerequisite without redundant words. It is appropriately sized and front-loaded.
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 three clearly documented parameters and no output schema, the description adequately establishes the workflow and prerequisite. It could be more complete by mentioning expected outcomes or failure handling, but it is sufficient for an AI agent to select and invoke 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?
All three parameters are fully described in the schema (title, content, imagePath), so the description adds limited semantic value. It reinforces the role of each parameter in the automation flow but does not provide additional constraints or interpretations 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 clearly identifies the action (publish article), the target resource (头条/Toutiao), and the specific elements involved (cover image, title, body) via browser automation. This differentiates it from the sibling tools for login, status check, and logout.
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 explicitly states the prerequisite of a valid login (cookies.json), indicating this tool should be used after toutiao_login and before toutiao_logout. It provides clear context but does not explicitly list alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: login, check status, logout, and publish. The boundaries are clear with no overlapping responsibilities.
All tools follow the same verb_noun pattern with a consistent 'toutiao_' prefix (login, check_status, logout, publish_article). Naming is uniform and predictable.
With 4 tools, the set is well-scoped for the authentication and publishing workflow. Each tool fills a clear need without unnecessary bloat.
The tool covers the full login lifecycle (login, check, logout) and the core publishing action. No obvious gaps for the stated purpose of publishing to Toutiao.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Remote MCP server for China brand visibility, destination demand, and KOL discovery workflows.
Official Octoparse MCP server for template discovery, cloud tasks, and structured data export.
MCP server for ByteDance Seedance AI video generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JessYan0913/toutiao-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
