Click on "Deploy 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., "@yuque list documents in my project knowledge base"
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.
一个基于 Session Cookie 的语雀 MCP (Model Context Protocol) 服务器，让你可以在 Claude Desktop、Cursor、WorkBuddy 等 AI 客户端中直接读取语雀文档。
A Model Context Protocol (MCP) server for reading Yuque documents via session cookie, compatible with Claude Desktop, Cursor, WorkBuddy, and other MCP clients.
提供 3 个 MCP 工具：
工具 | 说明 |
| 读取语雀文档，返回渲染后的文本内容。 |
| 推荐。读取语雀 Lake/API 源内容并转换为可读 Markdown，保留表格、PlantUML/Mermaid 图表、代码块、图片、链接和画板摘要。 |
| 列出知识库中的所有文档。 |
技术栈：aiohttp + Playwright（可选渲染）+ BeautifulSoup4
pip install yuque-mcp-tool
# 如果需要 Playwright 渲染功能（推荐）
python -m playwright install chromium或者从源码安装：
git clone https://github.com/andy8663/yuque-mcp-tool.git
cd yuque-mcp-tool
pip install -e .方法一：Application 面板（推荐）
登录 语雀
按 F12 打开浏览器开发者工具
切换到 Application（应用）面板
左侧展开 Cookies → 点击 https://www.yuque.com
在 Cookie 列表中找到 _yuque_session，复制其 Value 列的值
方法二：Console 命令
登录 语雀
按 F12 打开浏览器开发者工具
在 Console 中输入：
document.cookie.split('; ').find(c => c.startsWith('_yuque_session=')).split('=')[1]复制输出的值
⚠️ 如果
_yuque_session被标记为HttpOnly，方法二将无法读取，请使用方法一。Session Cookie 有效期约 30 天，过期后需重新获取。
根据你使用的客户端，选择对应的配置方式（见下方配置示例）。
编辑 ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）或 %APPDATA%\Claude\claude_desktop_config.json（Windows）：
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}编辑项目根目录下的 .cursor/mcp.json：
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}在 WorkBuddy 的 MCP 配置文件中添加：
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}如果未通过
pip install安装，也可以使用python -m yuque_mcp作为command，args留空。
变量名 | 必填 | 默认值 | 说明 |
| 是 | — | 语雀 Session Cookie（ |
| 否 |
| 默认语雀主机地址，用于补全短路径 URL |
| 否 | — | Playwright 浏览器通道，如 |
| 否 | — | Chromium/Chrome 可执行文件的绝对路径 |
| 否 |
| 渲染模式： |
重新登录语雀网站，获取新的 _yuque_session 值并更新配置。
如果系统已安装 Chrome，可以设置 YUQUE_BROWSER_CHANNEL=chrome 以使用系统 Chrome，无需额外安装 Playwright 自带 Chromium。
在配置中使用 Python 的完整路径作为 command，例如：
macOS: /usr/bin/python3
Windows: C:/Users/你的用户名/AppData/Local/Programs/Python/Python312/python.exe
如果文档位于团队子域名下（如 ogtd9v.yuque.com），可以将 YUQUE_HOST 设为常用子域名；也可以直接传完整文档 URL，工具会从 URL 推导实际 host。
MIT License — 详见 LICENSE。
Related MCP server: Yuque MCP Server
Provides 3 MCP tools:
Tool | Description |
| Read a Yuque document and return the rendered text content. |
| Recommended. Read the Yuque Lake/API source content and convert it to readable Markdown, preserving tables, PlantUML/Mermaid diagrams, code blocks, images, links, and board summaries. |
| List all documents in a Yuque knowledge base. |
Tech stack: aiohttp + Playwright (optional rendering) + BeautifulSoup4
pip install yuque-mcp-tool
# If you need Playwright rendering (recommended)
python -m playwright install chromiumOr install from source:
git clone https://github.com/andy8663/yuque-mcp-tool.git
cd yuque-mcp-tool
pip install -e .Method 1: Application Panel (Recommended)
Log in to Yuque
Press F12 to open browser DevTools
Switch to the Application tab
Expand Cookies in the left sidebar → click https://www.yuque.com
Find _yuque_session in the cookie list and copy its Value
Method 2: Console Command
Log in to Yuque
Press F12 to open browser DevTools
In the Console, run:
document.cookie.split('; ').find(c => c.startsWith('_yuque_session=')).split('=')[1]Copy the output value
⚠️ If
_yuque_sessionis marked asHttpOnly, Method 2 will not work — use Method 1 instead.The session cookie is valid for approximately 30 days.
Choose the configuration for your client below.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}Edit .cursor/mcp.json in your project root:
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}Add to your WorkBuddy MCP configuration:
{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}{
"mcpServers": {
"yuque": {
"command": "yuque-mcp",
"env": {
"YUQUE_SESSION": "YOUR_YUQUE_SESSION",
"YUQUE_HOST": "https://www.yuque.com"
}
}
}
}If you haven't installed via
pip install, you can usepython -m yuque_mcpas thecommandinstead.
Variable | Required | Default | Description |
| Yes | — | Yuque session cookie ( |
| No |
| Default Yuque host for short-path URL completion |
| No | — | Playwright browser channel, e.g. |
| No | — | Absolute path to a Chromium/Chrome executable |
| No |
| Rendering mode: |
Re-log in to Yuque, obtain a new _yuque_session value, and update your configuration.
If Chrome is installed on your system, set YUQUE_BROWSER_CHANNEL=chrome to use the system Chrome without installing Playwright's bundled Chromium.
Use the full path to your Python executable as the command in your configuration:
macOS: /usr/bin/python3
Windows: C:/Users/your-username/AppData/Local/Programs/Python/Python312/python.exe
If your documents are on a team subdomain (e.g. ogtd9v.yuque.com), set YUQUE_HOST to your common subdomain. You can also pass full document URLs directly — the tool derives the actual host from the URL.
MIT License — see LICENSE.
List all documents in a Yuque repository
| Name | Required | Description | Default |
|---|---|---|---|
| repo_slug | Yes | The repository slug or full repository URL (e.g., cc9c0g/rebell or https://example.yuque.com/cc9c0g/rebell) | |
| host | No | Optional Yuque host to use when repo_slug is not a full URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It only mentions 'list all documents', failing to note that it's a read-only operation, any authentication needs, or potential pagination. No side effects or limitations are mentioned.
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 action and resource. No redundancy, but might be too brief for complete understanding.
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 tool has no output schema, so the description should compensate by explaining return values (e.g., list of document titles, IDs). It doesn't. Also missing details on pagination, sorting, or filtering, which are common for list operations.
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 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already describes for repo_slug and host.
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 'list' and the resource 'documents' scoped to a 'Yuque repository', effectively distinguishing it from sibling tools that read individual documents.
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 like yuque_read or yuque_read_markdown. The description merely states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Yuque document by URL. Returns the full rendered content.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The Yuque document URL to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read operation returning content, but does not explicitly state read-only nature, access requirements, or potential side effects. Given no annotations, description carries full burden; it is adequate but not detailed.
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?
Two concise sentences, no unnecessary words. Every sentence adds value: action, method, and return type. Highly efficient.
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 read tool with one parameter and no output schema, the description adequately covers what it does and returns. Could mention error cases or format, but minimal gaps for this low 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?
Parameter schema has 100% coverage with a clear description. The tool description merely restates the parameter usage ('by URL') without adding new meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 clearly states verb ('Read') and resource ('Yuque document') and specifies return type ('full rendered content'). Differentiates from siblings by focusing on rendered content vs markdown (yuque_read_markdown) or listing (yuque_list_docs).
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?
Description implies when to use: when you have a document URL and want the full rendered content. Does not explicitly state when not to use or mention alternatives, but context of sibling tools provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Yuque document by URL using Yuque Lake/API source content and convert it to readable Markdown with tables, PlantUML, Mermaid, code blocks, images, links, and board summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The Yuque document URL to read | |
| include_stats | No | Whether to include Markdown conversion statistics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the read and conversion operation but does not explicitly state it is read-only, nor does it disclose auth needs, rate limits, or error behavior. Adequate but lacks safety disclaimers.
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 efficiently conveys the tool's functionality. It is concise and front-loaded, though it could be restructured for clarity by splitting into two sentences.
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 low complexity (2 parameters, no output schema, no annotations), the description sufficiently covers the tool's purpose and output (specific Markdown elements). It is complete enough for an agent to understand what the tool does and when to use it.
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% with descriptions for both parameters. The description adds general context about the conversion but does not provide additional details beyond the schema, such as format or constraints for the 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 it reads a Yuque document by URL and converts to Markdown with specific elements. It distinguishes from siblings: yuque_list_docs (listing) and yuque_read (likely raw reading), making the tool's specific purpose clear.
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 for converting Yuque documents to Markdown but does not explicitly state when to use this tool versus alternatives like yuque_read or yuque_list_docs, nor does it provide exclusions or prerequisites.
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.
v1.0.0yuque_list_docsyuque_readyuque_read_markdownScored across 3 tools
The three tools are distinct: one lists documents, and two read documents in different formats. However, the two read tools have overlapping purposes (both read a document by URL), which could cause minor confusion.
All tools share a 'yuque_' prefix and use verb_noun for most, but 'yuque_read' lacks a noun suffix, creating slight inconsistency with 'yuque_list_docs' and 'yuque_read_markdown'.
With only 3 tools, the server is severely under-scoped for a platform like Yuque, which typically requires many more operations (create, update, delete, etc.).
The server only provides read and list functionality, missing essential CRUD operations. It is extremely incomplete for the Yuque domain.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
Convert files, URLs, and documents to clean, AI-ready Markdown via MCP.
Parse PDF/Word/PPT/HTML to Markdown; tables as JSON, image extraction, RAG chunking, page ranges.
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
