The Yuque MCP Server enables interaction with Yuque (语雀) knowledge bases through Claude, providing comprehensive document management capabilities:
Available Tools:
search - Find documents by keywords using a search query (q parameter)
get_doc - Retrieve detailed content of a specific document (requires doc_id and book_id)
get_toc - Browse the knowledge base's table of contents and directory structure
create_doc - Add new documents with title and content, with optional target_uuid and action_mode for placement control
update_doc - Modify existing documents by updating their title, content, or slug path (requires doc_id)
Key Capabilities:
Search across documents using keyword queries
Retrieve full document content from specific knowledge bases
Browse and navigate knowledge base structure
Create and update documents for seamless content management
Integrate with Claude Desktop via MCP protocol for efficient workflows
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 MCP Server search for documentation about the frontend development workflow"
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.
语雀（Yuque）文档 Model Context Protocol (MCP) 服务器，提供文档搜索、目录浏览、内容获取和文档创建功能。
search: 搜索语雀文档
get_doc: 获取文档详细内容
get_toc: 获取知识库目录结构
create_doc: 创建新文档
update_doc: 更新现有文档
Related MCP server: Yuque MCP Server
npm installgit clone https://github.com/wangx-wx/yuque-mcp.git
cd yuque-mcp
npm install
npm run build在 Claude Desktop 配置文件中添加：
~/Library/Application Support/Claude/claude_desktop_config.json
%APPDATA%\Claude\claude_desktop_config.json
配置内容：
{
"mcpServers": {
"yuque": {
"command": "node",
"args": ["E:\\node\\yuque-mcp\\dist\\index.js"],
"env": {
"YUQUE_AUTH_TOKEN": "your-auth-token-here",
"YUQUE_BASE_URL": "https://www.yuque.com",
"YUQUE_GROUP_LOGIN": "your-group-login",
"YUQUE_BOOK_SLUG": "your-book-slug"
}
}
}
}claude mcp add yuque-mcp-asd \
--scope project \
--transport stdio \
-- node "/path/yuque-mcp/dist/index.js" \
--env YUQUE_AUTH_TOKEN=your-auth-token-here \
--env YUQUE_BASE_URL=https://www.leyaoyao.yuque.com \
--env YUQUE_GROUP_LOGIN=your-group-login \
--env YUQUE_BOOK_SLUG=your-book-slugclaude mcp add yuque-mcp-asd `
--scope project `
--transport stdio `
-- node "D:/yuque-mcp/dist/index.js" `
--env YUQUE_AUTH_TOKEN=your-auth-token-here `
--env YUQUE_BASE_URL=https://www.leyaoyao.yuque.com `
--env YUQUE_GROUP_LOGIN=your-group-login `
--env YUQUE_BOOK_SLUG=your-book-slug搜索语雀文档。
参数：
参数 | 类型 | 必填 | 说明 |
q | string | 是 | 搜索关键词 |
使用场景： 用户想查找特定内容的文档
示例：
搜索关键词 "TypeScript" 的文档获取知识库目录结构。
参数： 无（从环境变量读取知识库配置）
使用场景： 用户想浏览目录或导航文件夹结构
返回： 扁平化的目录项列表，包含 uuid 和 title
示例：
查看知识库的目录结构获取指定文档的详细内容。
参数：
参数 | 类型 | 必填 | 说明 |
doc_id | number | 是 | 文档 ID |
使用场景： 已有文档 ID，需要读取完整文档内容
示例：
获取文档 123456 的详细内容创建新文档并添加到目录结构中。
参数：
参数 | 类型 | 必填 | 说明 |
title | string | 是 | 文档标题 |
content | string | 是 | 文档内容（Markdown 格式） |
target_uuid | string | 否 | 目标节点 UUID（通过 get_toc 获取）。不填则添加到根节点 |
action_mode | string | 否 | 插入模式： |
使用场景： 用户想创建新文档
返回： 文档 ID、标题和访问 URL
示例：
创建标题为 "部署指南" 的文档，内容为 "# 部署\n\n..."更新现有文档的标题、内容或路径。
参数：
参数 | 类型 | 必填 | 说明 |
doc_id | string | 是 | 文档 ID 或路径 |
title | string | 否 | 新文档标题 |
content | string | 否 | 文档内容（Markdown 格式） |
slug | string | 否 | 新文档路径 |
使用场景： 修改已有文档的内容或标题
返回： 文档 ID、标题、路径、访问 URL 和更新时间
示例：
更新文档 abc123，将标题改为 "新标题"，内容改为 "# 新内容"yuque-mcp/
├── src/
│ ├── config/
│ │ └── env.ts # 环境变量配置
│ ├── models/
│ │ ├── types.ts # TypeScript 类型定义
│ │ └── responses.ts # 响应转换器
│ ├── api/
│ │ ├── client.ts # HTTP 客户端
│ │ └── yuque-api.ts # 语雀 API 封装
│ ├── tools/
│ │ ├── search.ts # search 工具实现
│ │ ├── get-doc.ts # get_doc 工具实现
│ │ ├── get-toc.ts # get_toc 工具实现
│ │ ├── create-doc.ts # create_doc 工具实现
│ │ └── update-doc.ts # update_doc 工具实现
│ ├── server.ts # MCP 服务器配置
│ └── index.ts # 入口文件
├── package.json
├── tsconfig.json
└── README.md帮我搜索关于 "TypeScript" 的语雀文档查看知识库的目录结构创建一个新文档，标题是 "部署指南"，内容如下：
# 部署指南
## 环境准备
- Node.js 18+
- MySQL 8.0
## 部署步骤
...更新文档 123456，标题改为 "部署指南 v2"，内容添加 "## 更新日志\n\n- 2024-01-01: 初始版本"先查看目录，找到 "技术文档" 分类的 uuid，然后在该分类下创建一个新文档MIT
Get detailed content of a specific Yuque document by doc_id
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Knowledge base (repository) ID | |
| doc_id | Yes | Document ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed content,' which implies a read-only operation, but it doesn't specify aspects like authentication requirements, rate limits, error handling, or the format of the returned content. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for a simple retrieval tool, earning a high score for conciseness.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed content' includes (e.g., text, metadata, formatting), potential errors, or usage constraints. For a tool with no structured behavioral data, this leaves the agent with insufficient context to use it effectively.
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 description coverage is 100%, with clear descriptions for both parameters (book_id as 'Knowledge base (repository) ID' and doc_id as 'Document ID'). The description adds minimal value beyond the schema by mentioning 'by doc_id,' which is redundant. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Get detailed content') and the resource ('a specific Yuque document by doc_id'), making the purpose immediately understandable. It doesn't explicitly differentiate from the sibling 'search' tool, which likely searches across documents rather than retrieving a specific one, so it misses the highest score for sibling differentiation.
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 alternatives like the sibling 'search' tool. It mentions retrieving a specific document by doc_id, which implies usage when the exact document ID is known, but this is not explicitly stated as a guideline or contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documents in Yuque (语雀). Use this tool to find documents by keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search keyword |
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 only states the basic action ('search for documents') without details on permissions, rate limits, pagination, or response format. This is inadequate for a tool with zero annotation coverage, as it leaves critical behavioral traits unspecified.
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 concise and front-loaded, consisting of two efficient sentences that directly convey the tool's purpose and basic usage. There's no wasted text, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like search constraints, result format, or error handling. For a search tool with no structured support, this leaves significant gaps in understanding how to use it effectively.
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 description coverage is 100%, with the single parameter 'q' documented as 'Search keyword.' The description adds minimal value by mentioning 'keywords' but doesn't provide additional semantics like search scope or syntax. This meets the baseline of 3 since the schema already does the heavy lifting.
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 ('search') and resource ('documents in Yuque'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_doc' (which likely retrieves a specific document), so it doesn't reach the highest score of 5.
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 minimal guidance with 'Use this tool to find documents by keywords,' but offers no explicit when-to-use rules, alternatives, or exclusions. There's no mention of when to choose this over 'get_doc' or any other context, leaving the agent with little direction.
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.0get_docsearchScored across 2 tools
The two tools have clearly distinct purposes: get_doc retrieves a specific document by ID, while search finds documents by keywords. There is no overlap or ambiguity between these operations.
Both tools follow a consistent verb_noun pattern (get_doc, search). The naming is straightforward and predictable, with no deviations in style.
With only 2 tools, the server feels thin for a document management domain. While get and search are essential, there are obvious gaps like create, update, delete, or list operations that would be expected for a complete Yuque integration.
The tool surface is severely incomplete for a Yuque document server. It lacks basic CRUD operations (create, update, delete), listing capabilities, and other domain-specific functions like managing repositories or users, leaving agents unable to perform full document workflows.
Search and query nTop's knowledge base and engineering guides from AI applications.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Search and read Vector Panda docs: API operations, pricing, storage tiers, measured benchmarks.
Provides metadata information to AI agents through the search API.
