yuque-mcp

by Lorwy

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some redundancy between `yuque_get_doc` and `yuque_get_doc_by_book_id` (and similarly for TOC). However, the descriptions clearly differentiate them by the way the book is specified.
Naming Consistency5/5
All tools follow a consistent `yuque_<verb>_<noun>` pattern, with variants like `_by_book_id` for clarity. No mixing of styles or inconsistent verbs.
Tool Count5/5
14 tools cover the main read operations for a knowledge base platform: document retrieval, version history, repositories, TOC, user info, groups, search, and heartbeat. The scope is well-balanced.
Completeness2/5
All tools are read-only; there are no create, update, or delete operations. For a comprehensive Yuque interaction, this is a major gap. The server appears to intentionally limit to read, but it lacks essential write capabilities.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states it's a read operation with permission requirement. It does not disclose behavioral traits like error handling, data limits, or the structure of the returned directory. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. However, it is not concise in a helpful way; it omits necessary details. The structure with '权限要求:' and '参数:' is clear, but the content is too minimal to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, it still lacks completeness: it does not mention the scope of the directory (e.g., full tree or flat list), depth, or any filtering. For a tool that returns a TOC, the description is insufficiently detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only repeats the parameter name ('book_id: 知识库 ID') without adding any meaning beyond the schema. It does not explain what a knowledge base ID is, how to obtain it, its format, or any constraints. This fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '通过知识库 ID 获取目录' (get directory by knowledge base ID). This is a specific verb+resource, and it distinguishes from sibling tools like yuque_get_toc (which might not take a book_id) and yuque_get_doc (which gets a document, not a directory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '权限要求: read', indicating it's a read operation, but it does not provide any guidance on when to use this tool versus alternatives, such as yuque_get_toc or other get tools. No context about prerequisites or use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it requires 'read' permission, but beyond that, no behavioral traits are disclosed. Without annotations, the description should cover aspects like idempotency, side effects, or return structure; it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose followed by permission and a parameter list. It is front-loaded with the purpose. Every sentence adds value, though the parameter list could be integrated into a more narrative structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return values. However, it lacks information about pagination, sorting, or behavior when the toc is large. For a simple retrieval tool, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema description coverage is 0%, the description adds Chinese explanations for each parameter ('团队/用户 login' and '知识库 slug'), providing semantic meaning that the schema (with only English titles) lacks. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取知识库目录' (get repository table of contents), which clearly indicates the tool's function. However, it does not differentiate from sibling tools like yuque_get_toc_by_book_id, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. While it mentions a permission requirement, it lacks context on prerequisites or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a read permission requirement, but with no annotations, it carries the full burden of behavioral disclosure. It does not describe side effects, mutability, or any other behavioral traits beyond the permission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, starting with the core purpose, then permission, then parameters. Every part serves a clear function with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and moderate parameter count, the description adequately covers permission and parameter meanings. However, it lacks comparison with similar tools and does not mention potential error conditions or limitations, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are described with brief Chinese labels (e.g., '团队/用户 login', '知识库 slug'), adding context beyond the schema's titles. Though not exhaustive, this meaningfully aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取文档详情' (get document details), which clearly indicates the action and resource. However, it does not differentiate from sibling tools like yuque_get_doc_by_book_id or yuque_get_docs, missing an opportunity to clarify uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required parameters and a read permission, but provides no guidance on when to use this tool versus its siblings. There is no mention of alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only discloses the read permission requirement, but lacks details on rate limits, idempotency, or other behavioral traits beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with clear sections for permission and parameter. It is concise but could optionally include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an output schema present, the tool is simple. The description covers the basic purpose and parameter, but lacks usage guidelines and behavioral context, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only a minimal label for the 'id' parameter ('版本 ID'), without example, format, or additional context. This provides some meaning but insufficiently compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a document version ('获取文档历史版本详情'), using a specific verb and resource. It distinguishes from sibling 'yuque_get_doc_versions' which likely lists versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a permission requirement ('权限要求: read'), providing some context, but does not explicitly state when to use this tool versus alternatives like yuque_get_doc_versions or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 a 'read' permission, suggesting it is read-only, but lacks details on pagination, rate limits, or detailed behavior of parameters like role and offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single line for purpose and bullet points for permission and parameters. Every sentence adds value, but the structure is basic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and 3 parameters, the description covers the core purpose and parameter meanings but lacks completeness in behavioral aspects such as pagination, error handling, or team semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'id' is a user ID or login, 'role' is an optional filter, and 'offset' is an optional offset. This adds meaning beyond the schema, though it could be more specific (e.g., valid role values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 list of teams for a specified user). It uses a specific verb (get) and resource (user groups), and it is distinct from sibling tools like yuque_get_user_info or yuque_get_group_repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a permission requirement ('权限要求: read') and lists optional filters (role, offset), which imply usage context but do not explicitly state when to use this tool vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses permission requirement ('权限要求: read'), which is helpful given no annotations. However, no details on return format, ordering, pagination, or whether full content is included. With no annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and structured with bullet points for parameters and permission. Front-loaded purpose. Could be more concise by removing redundant '参数:' label, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and an existing output schema (unseen), the description covers permission but lacks guidance on when to list vs single version, and no mention of list properties like ordering or limits. Adequate for a simple list tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains 'doc_id' is a document ID, adding minimal meaning beyond the schema (which has 0% coverage). For a simple string parameter, this is adequate but insufficient to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '获取文档历史版本列表' (get document version list), specifying verb 'get' and resource 'document versions'. This distinguishes from sibling 'yuque_get_doc_version' which retrieves a single version, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests use when needing a list of versions, but lacks explicit when-to-use vs alternatives like 'yuque_get_doc_version'. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds the permission requirement ('权限要求: read'), indicating the tool is read-only. However, it does not disclose pagination behavior, rate limits, or other traits beyond the basic read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the main purpose, followed by permission and a parameter list. Every line serves a purpose with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (covering return values) and a simple parameter set, the description adequately covers the tool's purpose, required parameter, and optional parameters. It could mention pagination behavior more explicitly, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides brief explanations for all parameters (e.g., 'login: 团队 login'), adding meaning beyond the schema. However, it does not specify allowed values for 'type' or explain default pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取') and the resource ('团队的知识库列表'), distinguishing it from sibling tools like yuque_get_user_repos or yuque_get_repo. It specifies it's for a team's repo list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus siblings like yuque_get_user_repos or yuque_get_repo. The description lacks context for choosing this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the read permission, implying a safe operation, but does not mention other behavioral traits like error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose, permission line, and parameter list. It is front-loaded but could benefit from more structured formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two required parameters and an existing output schema, the description covers purpose, parameters, and permissions adequately. It is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters in Chinese: '团队/用户 login' and '知识库 slug'. This adds meaningful semantics beyond the schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取知识库详情' (get repository details), clearly indicating the verb and resource. However, it does not differentiate it from sibling tools like yuque_get_group_repos or yuque_get_doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes a permission requirement ('权限要求: read'), providing context for when to use. However, it lacks explicit guidance on alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions a read permission requirement. It does not disclose behavioral traits such as pagination behavior, error handling, or response format. For a read operation, minimal transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear header and list of parameters. No unnecessary words. Could be slightly improved by grouping or formatting, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers parameters well and has an output schema (not shown), the description lacks details on pagination defaults, error conditions, or response structure. Adequate for a straightforward list tool but missing some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaningful information for each parameter: login (用户 login), offset (偏移量), limit (每页数量), type (知识库类型, with examples Book/Design/System). This adds value beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states '获取指定用户的知识库列表' (get repository list for a specified user). Distinguishes from sibling tools like `yuque_get_repo` (single repo) and `yuque_get_group_repos` (group repos) by specifying 'user repos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions permission requirement ('read') and lists parameters. However, no guidance on when to use this tool versus alternatives, or exclusions. The distinction from sibling tools is implied by the description but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the 'read' permission but lacks details on pagination behavior, ordering, rate limits, or handling of empty results. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line purpose and a bulleted parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required) and an output schema exists, the description covers parameter semantics adequately. However, it does not mention return value structure or pagination behavior. The output schema likely fills some gaps, making the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for all parameters: group_login (team/user login), book_slug (knowledge base slug), offset (optional), limit (per page count), optional_properties (additional attributes like body). This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取知识库的文档列表' (get document list of knowledge base), using a specific verb and resource. It distinguishes from sibling tools like yuque_get_doc (single doc) and yuque_get_doc_by_book_id (doc by book ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as when listing documents vs. getting a single document. The context is implied but not articulated, leaving the agent without clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions permission requirement ('read'), but lacks disclosure of side effects, pagination behavior, or result limits. With no annotations, description should carry more weight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise bullet list format with front-loaded purpose and permission. Could be more structured but no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters; output schema exists for return values. Lacks usage context, error handling, or limitations, but adequate for a search tool with sibling 'get' tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds meaning for all parameters: 'q' as search keyword, 'type' with examples (doc/repo/user), and brief explanations for scope, page, offset. Provides value beyond schema but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'perform a general search in Yuque' with a specific verb and resource. It inherently distinguishes from sibling 'get' tools which retrieve specific entities by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs alternatives. Implicit from name, but no conditional or exclusionary statements provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the permission requirement, which hints at read-only behavior. However, it does not disclose potential side effects, error handling, or rate limits. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear structure: one line for purpose, one line for permission, and a bulleted list of parameters. No unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description does not need to explain return values. It covers the permission and parameter meanings. However, it lacks information on error scenarios or pagination behavior beyond comments. Overall, it is fairly complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds Chinese labels for each parameter (e.g., 'book_id: 知识库 ID', 'page_size: 评论每页数量'). This provides context beyond the schema titles. It does not explain formats or allowed values, but for the optional pagination parameters, it clarifies they relate to comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取文档详情' means 'get document details') and the resource ('通过知识库 ID' means 'by knowledge base ID'). It distinguishes from siblings like yuque_get_doc (likely by document ID) and yuque_get_docs (list docs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions permission requirement ('权限要求: read') but does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify exclusions or prerequisites beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses permission requirement (read) and non-destructive nature (heartbeat). Missing details on response or side effects, but adequate for a simple ping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences with no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, simple functionality, and presence of an output schema, the description fully covers what an agent needs: test connection with read permission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline score 4 as per rule. Description adds no param info, which is unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a heartbeat check to test API connectivity, using specific verb 'test' and resource 'connection to Yuque API'. Distinct from sibling tools which focus on content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but the simple nature of the tool makes usage context obvious. However, it does not mention when not to use or provide alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses required permission ('read') and lists return fields, adding value beyond the schema. No mention of side effects, but as a read-only operation, this is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded, with clear sections for permission and return. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, permission, and return fields. With an output schema present, the description is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. Description adds nothing extra, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves user details for the current token, with specific fields listed. It is unambiguous and distinct from sibling tools that focus on documents or repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. Usage is implied (when you need current user info) but not contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![yuque-mcp MCP server](https://glama.ai/mcp/servers/Lorwy/yuque-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Lorwy/yuque-mcp)

Score Badge

Copy to your README.md:

[![yuque-mcp MCP server](https://glama.ai/mcp/servers/Lorwy/yuque-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Lorwy/yuque-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lorwy/yuque-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server