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., "@Yuque MCP Server get the TOC for my team's 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.
这是一个用于 Cursor 的语雀 MCP (Model Context Protocol) 服务器，可以让你在 Cursor 中直接通过语雀 URL 或知识库命名空间获取文档信息。
环境变量 | 必需 | 默认值 | 说明 |
| ✅ | 无 | 语雀 Cookie（单个 session 或完整 Cookie 字符串） |
| ❌ |
| 语雀基础 URL（企业私有部署需要） |
| ❌ | 无 | 默认知识库命名空间（如 |
快速配置示例：
# .env 文件
YUQUE_COOKIE=your-cookie-here
YUQUE_BASE_URL=https://your-company.yuque.com # 企业用户需要
YUQUE_NAMESPACE=username/repo # 可选Related MCP server: Yuque MCP Server
✨ 核心功能:
📋 通过语雀 URL 或命名空间+slug 获取文档详情
🔍 在知识库中搜索文档（标题和描述匹配）
📚 获取知识库完整目录结构（TOC）
📝 列出知识库所有文档
🍪 基于 Cookie 认证，免费用户可用
本服务器使用 Cookie 认证 + 无头浏览器的方式获取语雀文档：
✅ 使用 Puppeteer 无头浏览器模拟真实浏览器访问
✅ 通过设置 Cookie 自动登录
✅ 直接从页面提取文档内容
✅ 绕过 API 权限限制
✅ 无需语雀超级会员
语雀 MCP 支持两种 Cookie 配置方式：
_yuque_session（推荐，简单）登录语雀网站（如 https://www.yuque.com 或企业私有部署地址）
打开浏览器开发者工具（按 F12 或右键 → 检查）
切换到 Application（应用）或 存储 标签
在左侧找到 Cookies → 对应的语雀域名
找到名为 _yuque_session 的 Cookie
复制它的值（Value 列）
登录语雀网站后，打开浏览器开发者工具（F12）
切换到 Network（网络）标签
刷新页面或访问任意语雀文档
点击任意请求，找到 Request Headers（请求头）
找到 Cookie: 字段，复制完整的 Cookie 字符串
完整 Cookie 示例格式：
lang=zh-cn; _yuque_session=xxx; yuque_ctoken=xxx; current_theme=default; acw_tc=xxx⚠️ 注意:
Cookie 会过期（通常几天到几周），过期后需要重新获取
使用完整 Cookie 字符串通常更稳定，但包含更多敏感信息，请妥善保管
cd yuque-mcp
npm install在项目根目录创建 .env 文件。你可以复制 env.example 文件作为模板：
cp env.example .env然后编辑 .env 文件，填入你的配置：
# 语雀 Cookie（必需）
# 方式一：仅 _yuque_session 的值
YUQUE_COOKIE=n_FzpQWqYiQEgGAKM6Y9BYtxBrmoJD16z6Jfv4wlFVvUy3_O621jF6Gg9_6R59pueqqvebZW7EC6tqPoU6qD9A==
# 方式二：完整 Cookie 字符串（推荐，更稳定）
# YUQUE_COOKIE=lang=zh-cn; _yuque_session=xxx; yuque_ctoken=xxx; current_theme=default
# 可选：语雀基础 URL（企业私有部署时需要）
# 公有云用户可以不设置，默认为 https://www.yuque.com
# YUQUE_BASE_URL=https://your-company.yuque.com
# 可选：设置默认知识库命名空间
# 设置后可以直接通过 slug 获取文档，无需每次指定命名空间
# 支持中文用户名，例如：username/repo 或 用户名/知识库名
# YUQUE_NAMESPACE=username/repo💡 项目中提供了
env.example模板文件，包含详细的配置说明
环境变量详细说明:
环境变量 | 是否必需 | 说明 | 示例 |
| ✅ 必需 | 从浏览器获取的 Cookie，可以是单个 | 见上方示例 |
| ❌ 可选 | 语雀服务地址，企业私有部署时需要设置 |
|
| ❌ 可选 | 默认知识库命名空间，格式为 |
|
配置建议：
公有云用户：只需配置 YUQUE_COOKIE
企业用户：需要同时配置 YUQUE_COOKIE 和 YUQUE_BASE_URL
常用知识库：建议配置 YUQUE_NAMESPACE，简化后续操作
npm run build以下是不同场景下的完整配置示例：
.env 文件：
YUQUE_COOKIE=n_FzpQWqYiQEgGAKM6Y9BYtxBrmoJD16z6Jfv4wlFVvUy3_O621jF6Gg9_6R59pueqqvebZW7EC6tqPoU6qD9A==mcp.json 文件：
{
"mcpServers": {
"yuque": {
"command": "node",
"args": ["/Users/username/Desktop/guanlink-mcp/yuque-mcp/dist/index.js"]
}
}
}.env 文件：
# 企业语雀地址
YUQUE_BASE_URL=https://your-company.yuque.com
# 完整 Cookie 字符串（更稳定）
YUQUE_COOKIE=lang=zh-cn; _yuque_session=your-session-here; yuque_ctoken=your-token-here; current_theme=default
# 默认知识库（支持中文）
YUQUE_NAMESPACE=username/your-repo-namemcp.json 文件：
{
"mcpServers": {
"yuque": {
"command": "node",
"args": ["/Users/username/Desktop/guanlink-mcp/yuque-mcp/dist/index.js"]
}
}
}{
"mcpServers": {
"yuque": {
"command": "node",
"args": ["/Users/username/Desktop/guanlink-mcp/yuque-mcp/dist/index.js"],
"env": {
"YUQUE_BASE_URL": "https://your-company.yuque.com",
"YUQUE_COOKIE": "lang=zh-cn; _yuque_session=xxx; yuque_ctoken=xxx",
"YUQUE_NAMESPACE": "username/your-repo-name"
}
}
}
}💡 提示：推荐使用场景二（.env 文件），因为更新 Cookie 时无需修改 mcp.json
macOS: ~/.cursor/mcp.json 或 ~/.config/cursor/mcp.json
Linux: ~/.config/cursor/mcp.json
Windows: %APPDATA%\cursor\mcp.json
在项目目录下创建 .env 文件配置环境变量，然后编辑 Cursor 的 mcp.json：
{
"mcpServers": {
"yuque": {
"command": "node",
"args": [
"/Users/your-username/path/to/guanlink-mcp/yuque-mcp/dist/index.js"
]
}
}
}优点：
✅ 环境变量集中管理，便于更新
✅ 配置文件更简洁
✅ 敏感信息不暴露在 mcp.json 中
适合不想创建额外文件的场景：
{
"mcpServers": {
"yuque": {
"command": "node",
"args": [
"/Users/your-username/path/to/guanlink-mcp/yuque-mcp/dist/index.js"
],
"env": {
"YUQUE_COOKIE": "your-session-cookie-value-here"
}
}
}
}{
"mcpServers": {
"yuque": {
"command": "node",
"args": [
"/Users/your-username/path/to/guanlink-mcp/yuque-mcp/dist/index.js"
],
"env": {
"YUQUE_BASE_URL": "https://your-company.yuque.com",
"YUQUE_COOKIE": "lang=zh-cn; _yuque_session=xxx; yuque_ctoken=xxx",
"YUQUE_NAMESPACE": "username/repo"
}
}
}
}注意事项：
⚠️ 路径必须使用绝对路径
⚠️ Windows 用户注意路径分隔符，使用 \\ 或 /
⚠️ Cookie 中如果包含特殊字符，确保正确转义
⚠️ YUQUE_NAMESPACE 支持中文，如 "用户名/知识库名"
保存配置文件
重启 Cursor 使配置生效
在 Cursor 中，你应该能看到 Yuque MCP 服务已连接
配置完成后，重启 Cursor，你就可以在 Cursor 中使用语雀 MCP 服务了。
在 Cursor 中输入:
请帮我获取这个语雀文档的信息：https://www.yuque.com/username/repo/doc-slug或者如果你设置了默认知识库命名空间:
请帮我查看文档 doc-slug 的内容请在语雀知识库 username/repo 中搜索包含"API"的文档请显示 username/repo 这个知识库的目录结构请列出 username/repo 知识库中的所有文档获取单个语雀文档的详细信息。
参数:
docUrl (string, 可选): 语雀文档 URL
namespace (string, 可选): 知识库命名空间，格式为 username/repo
slug (string, 可选): 文档 slug
支持的调用方式:
// 方式 1: 使用 URL
{ docUrl: "https://www.yuque.com/username/repo/doc-slug" }
// 方式 2: 使用命名空间 + slug
{ namespace: "username/repo", slug: "doc-slug" }
// 方式 3: 如果设置了默认命名空间，只需提供 slug
{ slug: "doc-slug" }返回信息:
文档基本信息（标题、ID、格式、字数等）
作者信息
知识库信息
文档完整内容（Markdown 或 HTML）
统计数据（浏览量、点赞数、评论数）
获取知识库的完整目录结构。
参数:
namespace (string, 可选): 知识库命名空间，如果未提供则使用默认命名空间
返回信息:
知识库基本信息
完整的文档目录树
每个文档的标题和 slug
在知识库中搜索文档。
参数:
query (string, 必需): 搜索关键词
namespace (string, 可选): 知识库命名空间，如果未提供则使用默认命名空间
返回信息:
匹配的文档列表
每个文档的基本信息
📝 说明: 搜索会在文档标题和描述中进行关键词匹配（不区分大小写）。
列出知识库中的所有文档。
参数:
namespace (string, 可选): 知识库命名空间，如果未提供则使用默认命名空间
返回信息:
知识库基本信息
所有文档的列表
每个文档的基本信息
yuque-mcp/
├── src/
│ ├── index.ts # MCP 服务器入口
│ └── lib/
│ ├── api.ts # 语雀 API 调用
│ ├── browser-api.ts # 无头浏览器实现
│ ├── types.ts # TypeScript 类型定义
│ └── utils.ts # 工具函数
├── dist/ # 编译输出目录
├── package.json
├── tsconfig.json
├── env.example # 环境变量配置模板
├── .env # 环境变量配置（需基于 env.example 创建）
└── README.md重要文件说明：
env.example: 环境变量配置模板，包含详细注释
.env: 实际使用的环境变量文件（需自行创建，不要提交到 git）
src/lib/browser-api.ts: 使用 Puppeteer 实现的无头浏览器方案
dist/: TypeScript 编译后的 JavaScript 文件
# 安装依赖
npm install
# 构建
npm run build
# 开发模式（构建并运行）
npm run dev
# 格式化代码
npm run format症状: 提示 "语雀配置验证失败" 或 "Cookie 已过期"
解决方法:
✅ 检查 YUQUE_COOKIE 是否正确
✅ Cookie 可能已过期，重新从浏览器获取
✅ 确保已登录语雀网站
✅ 尝试使用完整 Cookie 字符串而不是仅 _yuque_session
✅ 企业用户检查 YUQUE_BASE_URL 是否配置正确
✅ 尝试清除浏览器缓存后重新登录，再获取新 Cookie
症状: 提示 "无法获取文档" 或 "文档不存在"
检查项:
✅ 文档 URL 或命名空间是否正确
✅ 文档是否为私有文档（需要登录后才能访问）
✅ 你的语雀账号是否有权限访问该文档
✅ Cookie 是否有效
✅ 企业用户：确认 YUQUE_BASE_URL 与实际访问的域名一致
✅ 如果使用了 YUQUE_NAMESPACE，确认格式正确（支持中文）
检查项:
✅ 检查 mcp.json 中的路径是否正确（必须是绝对路径）
✅ 确保已经运行 npm run build 构建项目
✅ 检查 dist/index.js 文件是否存在
✅ 重启 Cursor
✅ 查看 Cursor 的 MCP 日志，确认服务是否启动成功
Cookie 的有效期取决于语雀的设置，通常：
如果勾选了"记住我"：几周到几个月
如果没有勾选：几天到一周
建议：
在 .env 文件中保存 Cookie，过期后只需更新文件中的值
使用完整 Cookie 字符串通常比单独的 _yuque_session 有效期更长
定期（如每周）检查并更新 Cookie
症状: 公有云配置正常，但企业内部部署无法访问
解决方法:
✅ 确认设置了正确的 YUQUE_BASE_URL
✅ URL 格式应为 https://your-company.yuque.com（不带尾部斜杠）
✅ 确认网络可以访问该地址（可能需要 VPN）
✅ Cookie 必须从对应的企业语雀域名获取，不能混用
症状: 使用中文用户名或知识库名时报错
解决方法:
✅ YUQUE_NAMESPACE 支持中文，格式如："用户名/知识库名"
✅ 确保配置文件使用 UTF-8 编码
✅ 如果仍有问题，尝试使用 URL 中显示的英文 slug 代替中文名
⚠️ 重要提示:
❌ 不要在代码仓库中提交包含真实 Cookie 的配置文件
❌ 不要在公开的 GitHub 等平台分享包含 Cookie 的配置
⚠️ Cookie 相当于你的登录凭证，泄露后他人可以访问你的语雀账号
🔄 定期更新 Cookie（建议每月至少一次）
🚨 如果 Cookie 泄露，立即退出语雀所有设备的登录
使用 .env 文件（推荐）
# 在项目根目录创建 .env 文件
# 添加到 .gitignore 防止提交
echo ".env" >> .gitignore在 mcp.json 中配置
mcp.json 通常在用户目录下（~/.cursor/mcp.json），不会被 git 追踪
但要注意备份时不要泄露
企业用户额外注意
企业语雀可能有更严格的安全策略
定期检查会话状态
考虑使用只读权限的账号
如果你的项目使用 git，确保添加以下内容到 .gitignore：
# 环境变量
.env
.env.local
.env.*.local
# 配置文件（如果包含敏感信息）
*-config.json
mcp.json特性 | Jira MCP | Yuque MCP |
认证方式 | Personal Access Token | Session Cookie |
免费用户 | ✅ 可用 | ✅ 可用 |
Token 有效期 | 永久或自定义 | 几天到几周 |
配置难度 | 简单 | 简单 |
需要手动更新 | ❌ | ✅ (Cookie 过期时) |
TypeScript: 类型安全的 JavaScript
@modelcontextprotocol/sdk: MCP 协议 SDK
Puppeteer: 无头浏览器自动化
Chromium: 无头浏览器内核
undici: 高性能 HTTP 客户端（备用）
zod: 运行时类型验证
MIT License
支持获取文档评论
支持获取用户的所有知识库
支持批量导出文档
缓存机制优化性能
支持 Token 认证（给超级会员用户）
如有问题或建议，欢迎提 Issue！
从语雀 URL 或命名空间+slug 获取文档的详细信息。
支持的输入格式:
命名空间+Slug: 在 namespace 参数中指定 username/repo，在 slug 参数中指定文档 slug
返回的信息包括:
文档基本信息（标题、ID、格式、字数等）
作者信息
知识库信息
文档完整内容（Markdown 或 HTML）
统计数据（浏览量、点赞数、评论数）
| Name | Required | Description | Default |
|---|---|---|---|
| docUrl | No | 语雀文档 URL (例如: https://www.yuque.com/username/repo/doc-slug) | |
| namespace | No | 知识库命名空间 (例如: username/repo)，如果提供了 docUrl 则忽略此参数 | |
| slug | No | 文档 slug，需要与 namespace 一起使用 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by '获取'), returns detailed information including content and stats, and supports multiple input formats. However, it lacks details on error handling, rate limits, authentication needs, or response structure. For a tool with no annotations, this is adequate but leaves gaps in operational context.
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 well-structured and concise. It starts with a clear purpose statement, then lists supported input formats with examples, and finally enumerates the returned information in a bulleted list. Every sentence adds value without redundancy, 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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It covers the purpose, input methods, and return data. However, without an output schema, it could benefit from more detail on the response format (e.g., structure of '文档完整内容'). Still, it provides sufficient context for basic usage, justifying a score above minimum viable.
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 schema already documents all three parameters thoroughly. The description adds value by explaining the two input formats and how parameters interact (e.g., '如果提供了 docUrl 则忽略此参数' for namespace), but doesn't provide additional semantic meaning beyond what's in the schema. This meets the baseline for high schema coverage.
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 purpose: '获取文档的详细信息' (get detailed information about a document) from Yuque. It specifies the resource (Yuque document) and the action (retrieve details). However, it doesn't explicitly differentiate from sibling tools like 'get-yuque-toc' (which likely gets table of contents) or 'list-yuque-docs' (which likely lists documents), so it's not a perfect 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 usage context by detailing two supported input formats (URL vs. namespace+slug), which implies when to use each format. However, it doesn't explicitly state when to use this tool versus alternatives like 'search-yuque-docs' or 'get-yuque-toc', nor does it mention any prerequisites or exclusions. This leaves some ambiguity for the agent in selecting between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取语雀知识库的完整目录结构（TOC）。
可以查看知识库中所有文档的层级结构、标题和 slug。
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | 知识库命名空间 (例如: username/repo)，如果未提供则使用默认命名空间 |
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 describes what the tool does (gets TOC structure) but lacks critical behavioral details: it doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or the format of the returned data. For a tool with no annotation coverage, this is a significant gap in transparency.
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 appropriately concise with two sentences that directly address the tool's function and capabilities. The first sentence states the core purpose, and the second adds useful context about what can be viewed. There's no wasted language, though it could be slightly more structured with explicit usage guidance.
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 no annotations, no output schema, and the description lacks behavioral details, the description is incomplete. It adequately explains what the tool does but fails to address how it behaves, what it returns, or important contextual factors. For a tool that presumably returns structured data, the absence of output information is particularly problematic.
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 'namespace' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 purpose: '获取语雀知识库的完整目录结构（TOC）' (Get the complete table of contents structure for Yuque knowledge base). It specifies the verb ('获取' - get) and resource ('目录结构' - TOC structure), and distinguishes it from siblings by focusing on hierarchical structure rather than listing or searching documents. However, it doesn't explicitly differentiate from 'list-yuque-docs' which might also provide some structural information.
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 context by mentioning '可以查看知识库中所有文档的层级结构、标题和 slug' (Can view the hierarchical structure, titles, and slugs of all documents in the knowledge base), suggesting it's for understanding document organization. However, it doesn't explicitly state when to use this tool versus alternatives like 'list-yuque-docs' or 'search-yuque-docs', nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出指定知识库中的所有文档。
返回文档列表，包括标题、slug、更新时间等基本信息。
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | 知识库命名空间 (例如: username/repo)，如果未提供则使用默认命名空间 |
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 states the tool returns a list with basic information (title, slug, update time), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, error conditions, or what happens when namespace isn't provided (though the schema mentions default namespace). For a list operation with zero annotation coverage, this leaves significant gaps.
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 appropriately concise with two sentences that directly address purpose and return value. The first sentence states what the tool does, and the second describes the return format. There's no wasted text or unnecessary elaboration. However, it could be slightly more front-loaded by integrating the return information into the purpose statement for even tighter structure.
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 moderate complexity (list operation with one optional parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and return format but lacks important contextual information about behavioral traits, usage guidelines, and error handling. The absence of output schema means the description should ideally provide more detail about the return structure, but it only mentions basic fields without format or examples.
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 'namespace' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions '指定知识库' (specified knowledge base) which aligns with the namespace parameter, but provides no additional context about format, examples, or usage. With high schema coverage, the baseline of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 purpose with a specific verb ('列出' meaning 'list') and resource ('指定知识库中的所有文档' meaning 'all documents in the specified knowledge base'). It distinguishes from sibling tools like 'get-yuque-doc' (retrieves a single document) and 'search-yuque-docs' (searches documents), but doesn't explicitly differentiate from 'get-yuque-toc' (which might list table of contents). The purpose is clear but sibling differentiation could be more explicit.
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. It doesn't mention when to prefer 'list-yuque-docs' over 'search-yuque-docs' for filtering, or when 'get-yuque-toc' might be more appropriate. There's no discussion of prerequisites, context, or exclusions. The only implied usage is when you want to list all documents in a knowledge base, but no comparative guidance is given.
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 |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| namespace | No | 知识库命名空间 (例如: username/repo)，如果未提供则使用默认命名空间 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that searching occurs in document titles and descriptions, which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination, or what happens if no matches are found. For a search tool with zero annotation coverage, this is insufficient.
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 with two sentences that directly state the tool's function and scope. It's front-loaded with the main purpose, though it could be slightly more structured by explicitly mentioning parameters or usage context.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error handling, or how results are formatted. The mention of keyword matching in titles and descriptions is helpful but insufficient for full contextual understanding.
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 schema already documents both parameters ('query' as search keywords and 'namespace' as knowledge base namespace). The description implies the 'namespace' parameter specifies the knowledge base but doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate when 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 tool's purpose: '在指定的知识库中搜索文档' (search for documents in a specified knowledge base). It specifies the verb '搜索' (search) and resource '文档' (documents), but doesn't explicitly differentiate from sibling tools like 'list-yuque-docs' or 'get-yuque-doc' beyond mentioning keyword matching in titles and descriptions.
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 'list-yuque-docs' (which might list all documents) or 'get-yuque-doc' (which retrieves a specific document). It mentions searching within a knowledge base but doesn't specify scenarios where searching is preferable to listing or getting.
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.
v1.0.0get-yuque-docget-yuque-toclist-yuque-docssearch-yuque-docsEach tool has a clearly distinct purpose with no overlap: get-yuque-doc retrieves a single document's details, get-yuque-toc fetches a knowledge base's table of contents, list-yuque-docs lists all documents in a knowledge base, and search-yuque-docs searches within a knowledge base. The descriptions clearly differentiate these operations, eliminating any ambiguity.
All tool names follow a consistent verb-noun pattern with hyphens: get-yuque-doc, get-yuque-toc, list-yuque-docs, and search-yuque-docs. The naming is uniform, predictable, and readable, with no deviations in style or convention.
With 4 tools, the server is well-scoped for basic document retrieval and navigation in Yuque, covering core operations like fetching, listing, searching, and getting TOC. However, it lacks CRUD operations (e.g., create, update, delete), making it slightly under-equipped for a full document management system, though reasonable for a read-only interface.
The tool set provides good read-only coverage for accessing and navigating Yuque documents and knowledge bases, but there are notable gaps in CRUD operations (no create, update, or delete tools) and other lifecycle actions like commenting or version management. This limits agents to retrieval tasks without full document management capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
Read spaces, collections, pages and content; search docs and manage GitBook organization spaces.
Search everything you save: YouTube, articles, podcasts, PDFs, Notion, Obsidian. API key or OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/saoqixiaomm/yuque-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
