The Yuque MCP Server connects AI assistants to your Yuque knowledge base, enabling full read/write management of content across the following areas:
User
Retrieve details about the current authenticated Yuque account
Search
Search for documents (doc) or knowledge bases/repos (repo) by keyword
Books (知识库)
List, get, create, and update knowledge bases (name, slug, visibility, type)
Documents
List, get, create, and update documents within books, supporting Markdown, Lake, and HTML formats
Table of Contents (TOC)
Get and update a book's TOC (append, move, or reorganize nodes)
Notes (小记)
List, get, create, and update personal notes with pagination and status filtering
Structured Resources (Boards)
Read, create, and update board resources (mindmap, flowchart, architecture diagram) embedded in documents via text or JSON DSL
Additional features: supports personal/team tokens and custom hosts, with a CLI for easy setup with popular MCP clients (Claude Desktop, VS Code, Cursor, etc.).
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 my Yuque docs for meeting notes"
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.
Let AI assistants read and write your Yuque (语雀) knowledge basethrough the Model Context Protocol.
Quick Start · Tools · Troubleshooting · Docs · 中文文档
Once connected, ask your assistant things like:
"Search my Yuque for everything about canary releases and give me a one-page summary."
"Turn today's meeting notes into a doc in my Tech Research book."
"Add a flowchart of this deployment pipeline to the design doc."
1. Get a token — create one at Yuque Developer Settings. If you use a team token bound to a Yuque space, also note the space host (e.g. https://your-space.yuque.com) — you will pass it as --host.
2. Install — one command locates the right config file for your OS and merges a yuque entry into it, without touching other servers:
npx yuque-mcp install --token=YOUR_TOKEN --client=cursorSupported clients: claude-desktop · vscode · cursor · windsurf · cline · trae · qoder · opencode. Prefer an interactive flow? Run npx yuque-mcp setup.
Register the server directly:
claude mcp add yuque -- npx -y yuque-mcp --token=YOUR_TOKENAny client that supports stdio transport works — see docs/clients.md for per-client config paths.
{
"mcpServers": {
"yuque": {
"command": "npx",
"args": ["-y", "yuque-mcp"],
"env": { "YUQUE_TOKEN": "YOUR_TOKEN" }
}
}
}3. Restart your client and start asking.
Related MCP server: Yuque MCP Server
Setting | Env var / CLI flag | Description |
Token (required) |
| Personal or team Yuque API token |
Host (optional) |
| Site or space host, e.g. |
Site roots are normalized to /api/v2; when unset, the host defaults to https://www.yuque.com/api/v2.
# Team token / private deployment
npx yuque-mcp install --token=YOUR_TOKEN --client=cursor --host=https://your-space.yuque.comYUQUE_PERSONAL_TOKEN, YUQUE_BASE_URL, and --base-url still work as legacy fallbacks. Precedence: YUQUE_TOKEN > YUQUE_PERSONAL_TOKEN > --token, and YUQUE_HOST > --host > YUQUE_BASE_URL > --base-url. New configs should use YUQUE_TOKEN and YUQUE_HOST.
Each tool maps to exactly one Yuque API route.
Category | Tool | Description |
User |
| Get the authenticated user for the current token |
Search |
| Search docs or repos, with paging |
Books |
| List books (知识库) of a user |
| Get a book by ID or namespace | |
| Create a book | |
| Update name, slug, description, or visibility | |
Docs |
| List docs in a book, with paging |
| Get full content — markdown, | |
| Create a doc in a book | |
| Update a doc's body or metadata | |
TOC |
| Get a book's table of contents |
| Append or move a single TOC node | |
Notes |
| List notes (小记), with paging and status filter |
| Get a note with full content | |
| Create a note | |
| Update a note | |
Boards |
| Read a board (mindmap / flowchart / diagram) from a doc |
| Create a board in a doc | |
| Update a board in a doc |
In particular, yuque_update_doc cannot combine a markdown body with title / slug / public changes in a single call — update metadata separately. The full contract, including format routing between the YMD markdown API and the legacy document API, is documented in docs/capability-scope.md.
Not covered (yet): comments, attachment upload and file management, permission and member management, section-level doc edits, and structured resources other than boards.
The create/update tools modify real content in your knowledge base, and the server can do whatever your token can do. Keep the token secret, and prefer a space-scoped team token (with YUQUE_HOST) when you only work within one space. To report a vulnerability, see SECURITY.md.
Error | Solution |
| Set |
| Token invalid or expired — regenerate it |
| Too many requests — wait a moment and retry |
| Target permanently deleted or endpoint deprecated — check the doc/book exists |
Tool not found | Update to the latest version: |
| Install Node.js v18 or later |
git clone https://github.com/yuque/yuque-mcp-server.git
cd yuque-mcp-server
npm install
npm test # run tests
npm run build # compile TypeScript
npm run dev # dev mode with hot reloadArchitecture, tech stack, and the full tool contract live in docs/. Contributions are welcome — see CONTRIBUTING.md.
Yuque AI Ecosystem — skills and plugins built on top of this server
Create a new book (知识库) for the current user
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | User login name | |
| name | Yes | Book name | |
| slug | Yes | Book slug (URL-friendly identifier) | |
| description | No | Book description | |
| public | No | Public visibility: 0 (private) or 1 (public) | |
| repo_type | No | Book type: Book, Design, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'create a new book' without disclosing side effects, permissions required, idempotency, or error behavior. Fails to inform agent about important behavioral traits.
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?
Single sentence, no redundancy, efficiently conveys the core purpose.
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?
Despite 100% schema coverage, the description omits details on behavior of optional parameters (public, repo_type), return format, and success/failure indicators. Insufficient for a creation tool with no output schema.
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 covers all 6 parameters with descriptions. The description adds 'for the current user', linking login to user context but not adding significant meaning beyond schema. Baseline 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?
The description states a specific verb 'Create' and resource 'book', with additional context 'for the current user'. It clearly distinguishes from sibling tools like yuque_create_doc or yuque_create_note.
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 on when to use this tool versus alternatives like yuque_update_book or yuque_list_books. Does not mention prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new document in a repo/book
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") | |
| title | Yes | Document title | |
| slug | No | Document slug (URL-friendly identifier) | |
| body | No | Document content (markdown or lake format) | |
| format | No | Content format: markdown, lake, html | |
| public | No | Public visibility: 0 (private) or 1 (public) |
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 states the action and does not disclose any side effects, required permissions, or return behavior. This is a significant gap for a mutation tool.
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 with no wasted words. It is front-loaded with the core purpose.
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 create tool with complete schema coverage, the description is minimally viable. However, with no output schema or annotations, it does not inform the agent about return values or side effects. Adequate but with clear gaps.
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 fully documents all six parameters. The description adds no additional meaning beyond what the schema already provides, so baseline 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?
The description clearly states the action ('Create') and the target resource ('a new document in a repo/book'). It effectively distinguishes from sibling tools like update_doc and delete_doc.
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?
Usage is implied rather than explicitly stated. The description gives no when-to-use guidance or alternatives, but as a create operation it is clear when it would be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new note (小记)
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Note content (plain text or markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authorization requirements, idempotency, or side effects. The creation action is implicitly clear but lacks depth.
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 extremely concise with a single sentence that provides essential information without verbosity.
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 one-parameter tool, the description is minimally adequate but lacks details on return values, error handling, or success indicators. The Chinese term adds some context.
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 covers the single parameter 'body' fully (100% coverage). The tool description adds no extra semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'note', with a Chinese translation for context. However, it does not differentiate from sibling create tools like yuque_create_doc or yuque_create_book.
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. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a structured resource in a Yuque document. Currently resource_type only supports board: mindmap, flowchart, or architecturediagram.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes | Resource type. Currently only board is supported. | |
| doc_id | No | Yuque document ID. Provide either doc_id or url, but not both. | |
| url | No | Yuque document URL. Provide either url or doc_id, but not both. | |
| type | Yes | Board type: mindmap, flowchart, or architecturediagram. | |
| dsl | Yes | Board text DSL content. | |
| insert_after_lake_id | No | Insert after a top-level Lake node. Omit to append to the document end. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description does not address behavioral traits such as side effects, authorization needs, or what happens when doc_id/url is omitted (the resource may not be attached to a document). The description only mentions supported types, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences. The first sentence states the purpose, and the second adds critical detail about the supported resource types. Every sentence serves a purpose without redundancy.
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 6 parameters and no output schema. The description does not explain the behavior when doc_id/url are omitted, the meaning of insert_after_lake_id, or what the tool returns. This leaves significant gaps for a complex tool.
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 detailed descriptions for all parameters. The description adds minimal value beyond the schema, only clarifying that resource_type is limited to 'board' and listing the board types. Baseline 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?
The description clearly states the tool creates a structured resource in a Yuque document and specifies that resource_type only supports 'board' with subtypes mindmap, flowchart, or architecturediagram. This clearly distinguishes it from sibling tools like yuque_create_doc or yuque_create_book.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like yuque_create_doc. The name and description imply it's for creating resources within a document, but it does not state when to prefer this over other create tools or how it relates to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific book (知识库) by ID or namespace
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Book ID or namespace (e.g., "user/book_slug") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the operation is a get (read), but doesn't disclose auth requirements, side effects, or output format. Minimal behavioral 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 a single concise sentence that conveys the essential information without unnecessary words.
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 get tool with one required parameter and no output schema, the description is minimally adequate. It doesn't explain what a 'book' (知识库) is, but the context is likely known.
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% with the parameter documented as 'Book ID or namespace (e.g., "user/book_slug")'. The description echoes this but adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (book), and the method (by ID or namespace). It distinguishes from siblings like yuque_list_books (list all) and yuque_create_book (create).
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 on when to use this tool vs alternatives, no exclusions or prerequisites. With 18 sibling tools, the description should provide context for choosing this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific document with full content
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") | |
| doc_id | Yes | Document ID or slug | |
| format | No | Content format to read. Omit or use markdown to read through the YMD-compatible flow; use lake/html for the legacy document API. | |
| include_lake | No | Include raw Lake format body (preserves Mermaid source code, diagrams, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It lacks details on behavioral traits such as authorization needs, rate limits, error handling, or what 'full content' entails (e.g., if it returns metadata only). The schema parameters cover format, but the description doesn't mention them.
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 with no fluff. It is front-loaded and clear, though slightly more context (e.g., what 'full content' refers to) would improve it without sacrificing 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?
The description is complete enough for a simple get operation, but since there is no output schema, some return format information would be helpful. Given the tool's complexity and the richness of sibling tools, a bit more context (e.g., typical use case) would improve completeness.
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% with clear parameter descriptions. The description adds the concept of 'full content' but doesn't enhance parameter understanding beyond the schema. 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?
The description clearly states the verb 'Get', the resource 'specific document', and the outcome 'with full content'. It effectively distinguishes from sibling tools that list documents, get notes, or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single document, but it doesn't specify when to use this over siblings like yuque_get_note or yuque_get_book. No explicit guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific note with full content
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Note 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. It discloses that the tool returns 'full content', implying a read operation with no side effects, but does not mention permissions, rate limits, or other behavioral constraints.
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 short sentence with no unnecessary words. It is very concise, though it could be slightly more informative without losing brevity.
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 retrieval tool with one required parameter and no output schema, the description is largely complete. It indicates the return includes full content, which is adequate for an agent to understand the tool's purpose.
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% (note_id described as 'Note ID'), so baseline is 3. The tool description adds no additional meaning beyond the schema; it doesn't explain where to find note_id or its format.
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 retrieves a specific note with its full content. The verb 'get' and resource 'note' are specific, but it does not differentiate from other 'get' tools like yuque_get_doc or yuque_get_book among siblings.
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, nor does it mention prerequisites or exclusions. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a structured resource view from a Yuque document. Currently resource_type only supports board; pass the raw resource_id, not board://.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes | Resource type. Currently only board is supported. | |
| doc_id | No | Yuque document ID. Provide either doc_id or url, but not both. | |
| url | No | Yuque document URL. Provide either url or doc_id, but not both. | |
| resource_id | Yes | Raw board resource ID from board://<resource_id>; do not pass the full board:// locator. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb 'Read' implies a non-destructive operation, but there is no mention of error handling, authentication requirements, or behavior when the resource is missing. The baseline is set to 3 due to the minimal risk of a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and every word adds value. No redundancy or fluff.
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 lacks an output schema, so the description should explain what the structured view contains. It does not mention the return format or fields. For a read tool, this is a notable gap, though the schema coverage is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions. The description adds value by clarifying that resource_id is the raw ID (not the full board:// locator) and that resource_type is limited to board, which is not fully detailed in the schema enum alone.
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 reads a structured resource view from a Yuque document. It specifies the only supported resource_type (board) and how to correctly provide the resource_id, distinguishing it from sibling tools like create/update.
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 does not explicitly guide when to use this tool over alternatives like yuque_create_resource or yuque_update_resource. It only hints at the current limitation to board, but lacks context on when retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the table of contents (TOC) for a repo/book
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") |
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 'Get' without mentioning return format, pagination, auth requirements, or any side effects. This is a significant gap for a tool that has no structured annotations to clarify behavior.
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 with no wasted words. It is appropriately sized for a simple retrieval tool, though it could be slightly expanded to include usage context without becoming verbose.
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 single-parameter read tool, the description is adequate but minimal. With no output schema, it does not explain what the TOC structure looks like or what fields the response contains. It is sufficient for basic understanding but lacks depth for an agent to anticipate the return format or error cases.
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 provides 100% coverage for the single parameter with a description including an example. The main description adds the synonym 'repo/book', which is a minor clarification but does not significantly augment the schema's information. Baseline 3 is appropriate given 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 uses a specific verb ('Get') and resource ('table of contents (TOC) for a repo/book'), clearly distinguishing it from siblings like yuque_get_repo, yuque_list_docs, and the complementary yuque_update_toc. The scope is unambiguous.
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 by naming the resource, but it does not explicitly state when to choose this over alternatives or any exclusions. For example, it doesn't note that this returns the TOC structure while yuque_list_docs returns doc metadata. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current authenticated user information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the context that the tool returns information about the authenticated user, implying an authentication requirement. However, with no annotations, it carries the full burden and does not disclose response format, error behavior, or any side effects. It is more than a tautology but lacks depth.
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 clear sentence, front-loaded with the verb and resource. Every word is necessary, and there is no extraneous information.
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 zero-parameter tool, the description is minimally adequate. However, it does not specify what 'user information' includes, and the absence of an output schema and annotations leaves the agent without details on return values or error handling. It is concise but could be more descriptive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The baseline score for no parameters is 4, and the description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'current authenticated user information'. This distinguishes it from sibling tools that handle groups, repos, docs, etc. It is immediately obvious what this tool does.
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 explicit guidance on when to use this tool versus alternatives. It is implied that this is for fetching the authenticated user's info, but there are no exclusions, prerequisites, or reference to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all books (知识库) for the current user
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | User login name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation (listing books), but does not confirm read-only behavior or disclose any side effects. The lack of annotations makes a score of 3 appropriate as it is functional but incomplete.
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 with no wasted words, but the ambiguity between 'current user' and the 'login' parameter slightly detracts from its efficiency. It remains mostly concise but could be improved.
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 no output schema, the description does not mention what is returned (e.g., list of book ids or titles). It does not address pagination, filtering, or the scope of 'all books'. For a list operation, more context on the output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage describing 'login' as 'User login name', but the description says 'for the current user', creating ambiguity: does it list books of the authenticated user or of the user specified by 'login'? This inconsistency fails to clarify the parameter's role, providing less value than a baseline 3.
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 'List all books' with a specific noun (知识库) and targets the current user, making the purpose understandable. However, it does not explicitly differentiate from sibling 'yuque_get_book' which retrieves a single book, but the name 'list' implies the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies listing all books for a user, but does not mention alternatives like 'yuque_get_book' for specific books, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all documents in a repo/book
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It accurately states a read-only listing action with a defined resource scope, but does not disclose pagination, ordering, or return format details. This is acceptable for a simple list operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no filler words. Every word adds value, making it highly concise and well-structured.
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 tool with one fully documented parameter and no nested objects, the description is nearly complete. It clearly states the operation and resource, though it could mention the return type (a list) more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter (repo_id) with type and example. The description adds minimal additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('documents in a repo/book'), and the scope is unambiguous. It distinguishes this tool from siblings like yuque_get_doc (single document) and yuque_list_doc_versions (versions of a document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: to list all documents in a repository. It does not explicitly state when not to use it or mention alternatives, but the context is clear given the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all notes (小记) for the current user with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: 0 (normal), 9 (deleted) | |
| page | No | Page number (default: 1) | |
| limit | No | Number of notes per page (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'list', implying a read operation but lacks detail on default sorting, whether deleted notes are included by default, or any other behavioral traits. The description does not compensate for the absence of annotations.
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?
A single clear sentence with all essential information front-loaded. No redundant words. The description is appropriately sized.
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 list tool with few parameters and no output schema, the description gives enough basic info but lacks details like default ordering, return format, or any behavioral context. It is adequate but not comprehensive.
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%, so all parameters are already described. The description adds clarification of the resource type but adds no new parameter semantics beyond the schema. Baseline 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?
The description clearly states the action (list), the resource (notes, clarified with Chinese term 小记), and scope (current user) with pagination. It effectively distinguishes from sibling tools that list other resources like books or 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?
No guidance on when to use this tool versus alternatives. It doesn't specify conditions for filtering or when not to use pagination. Siblings like yuque_search are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documents or repos in Yuque
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| type | Yes | Search type: doc (documents), repo (knowledge bases) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose behavioral traits such as rate limits, result limits, authentication needs, or whether it returns full content or metadata. The tool's behavior is not sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and directly states the tool's purpose.
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?
Despite having only 2 well-described parameters and no output schema, the description fails to explain what the search returns (e.g., list of IDs, snippets). The tool's output and behavior remain unclear, making the description incomplete.
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%, with both parameters described. The description adds no additional meaning beyond what the schema already provides; for high coverage, a 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?
The description clearly states the action (search) and resources (documents or repos). However, it does not differentiate from sibling listing tools like yuque_list_docs or yuque_list_books, missing an opportunity to clarify the distinction between search and list.
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. There is no mention of use cases, exclusions, or when a different tool (e.g., listing) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a book (知识库)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Book ID or namespace (e.g., "user/book_slug") | |
| name | No | New book name | |
| slug | No | New book slug | |
| description | No | New book description | |
| public | No | Public visibility: 0 (private) or 1 (public) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'Update', implying mutation, but offers no information about side effects, permissions, reversibility, or return behavior.
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?
Extremely concise (one sentence), but it is under-specified. While not verbose, the lack of additional context hurts its effectiveness. It is adequate but not excellent.
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 absence of output schema and annotations, the description is too minimal. It does not explain what the tool returns, prerequisites, or any behavioral details. For a 5-parameter tool, this is incomplete.
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 extra parameter meaning beyond what the schema already provides.
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 states 'Update a book (知识库)', which is a clear verb+resource pair. However, it does not specify what aspects can be updated, relying on the schema. It distinguishes from create/get siblings but lacks detail.
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 usage guidance provided. There is no mention of when to use this tool versus other update tools (e.g., yuque_update_doc) or any prerequisites/context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing document
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") | |
| doc_id | Yes | Document ID or slug | |
| title | No | New document title | |
| slug | No | New document slug | |
| body | No | New document content | |
| format | No | Content format for body. Omit or use markdown to write through the YMD-compatible flow; use lake/html for the legacy document API. | |
| public | No | Public visibility: 0 (private) or 1 (public) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'Update', which implies mutation but does not clarify destructive actions, permission requirements, or whether fields are merged or replaced.
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 is front-loaded and concise. However, it is so minimal that it misses context, but it earns points for brevity.
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?
With 7 parameters (2 required) and no output schema, the description is too brief. It does not explain return values, side effects, or usage prerequisites, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, so the schema provides adequate meaning. The description adds no additional parameter info, but the baseline of 3 is appropriate given full 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 'Update an existing document' clearly states the action and resource, and the tool name includes 'doc' which distinguishes it from other update tools like 'update_book'. However, it lacks specificity about what document fields are updated.
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 siblings like 'yuque_update_note' or 'yuque_update_book'. The description neither states the context nor provides exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing note
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | Note ID | |
| body | Yes | New note content (plain text or markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, and the description provides no behavioral details. For a mutation tool, critical information such as whether the update is partial or full, what happens if the note_id does not exist, or authentication requirements is entirely missing.
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 only one sentence, which is concise, but it sacrifices necessary detail. It is not optimally structured as it front-loads only a generic action without 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 no output schema and no annotations, the description is incomplete. It does not explain what the tool returns, nor does it specify behavioral aspects like idempotency or error handling. For a simple mutation with 2 parameters, this is insufficient.
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 parameter descriptions for note_id and body. The description 'Update an existing note' adds no additional meaning beyond the schema. Baseline of 3 is appropriate since schema already documents 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 'Update an existing note' provides a clear verb+resource combination, indicating what the tool does. However, with siblings like yuque_update_doc and yuque_update_book, it does not differentiate what makes a 'note' distinct, but the resource name itself serves as 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?
No usage guidelines are provided. The description does not indicate when to use this tool versus the many sibling update tools, nor does it mention any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a structured resource in a Yuque document. Currently resource_type only supports board; provide exactly one of text or dsl.
| Name | Required | Description | Default |
|---|---|---|---|
| resource_type | Yes | Resource type. Currently only board is supported. | |
| doc_id | No | Yuque document ID. Provide either doc_id or url, but not both. | |
| url | No | Yuque document URL. Provide either url or doc_id, but not both. | |
| resource_id | Yes | Raw board resource ID from board://<resource_id>; do not pass the full board:// locator. | |
| text | No | New board text DSL. Mutually exclusive with dsl. | |
| dsl | No | Board JSON DSL object. It is passed through to Yuque public v2 as-is. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that resource_type is limited to 'board' and that text and dsl are mutually exclusive, but it does not mention side effects, permissions required, idempotency, or what happens to existing data. The description is adequate but not comprehensive.
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 two sentences, front-loaded with the action and resource. Every sentence is concise and contains essential information with no redundancy.
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 6 parameters, no output schema, and no annotations, the description covers the basic operation but lacks details on return values, error conditions, or prerequisites. It adequately describes the input constraints but is incomplete for a full understanding of the tool's behavior.
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 each parameter having a description. The description adds the mutual exclusivity rule ('provide exactly one of text or dsl') which is already implied by the schema descriptions, and restates the resource_type enum limitation. The added value over the schema is minimal, earning a baseline score of 3.
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 'update' and the resource type 'structured resource in a Yuque document'. It mentions the current limitation to 'board' and the mutually exclusive 'text' and 'dsl' fields, making the purpose distinct from sibling tools like yuque_update_doc. However, it does not explicitly differentiate from all siblings.
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 a rule for selecting between text and dsl ('provide exactly one'), but it gives no guidance on when to use this tool versus alternatives such as yuque_update_doc or yuque_update_book. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the table of contents (TOC) for a repo/book. The toc_data must be a single-operation JSON object (not an array). Required fields: "action" (e.g. "appendNode"), "action_mode" ("child" or "sibling"), "target_uuid" (empty string for root level). For new nodes: include "type" ("TITLE" or "DOC") and "title". To move existing nodes: use "node_uuid" instead. Example: {"action":"appendNode","action_mode":"child","target_uuid":"","type":"TITLE","title":"New Section"}
| Name | Required | Description | Default |
|---|---|---|---|
| repo_id | Yes | Repo ID or namespace (e.g., "mygroup/mybook") | |
| toc_data | Yes | Single-operation JSON object. Must include "action" (e.g. "appendNode"), "action_mode" ("child"|"sibling"), "target_uuid" (empty string = root). For new nodes add "type"+"title"; to move existing nodes use "node_uuid". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It explains the TOC structure and actions but does not disclose whether updates are incremental or destructive, nor does it mention authorization needs or side effects. The detailed format helps but leaves 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer but each sentence provides essential details. It front-loads the purpose, then systematically explains parameters. Could be slightly more concise, but no redundant information.
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?
No output schema exists, and the description does not explain return values or error conditions. It covers usage well but lacks context on outcomes, prerequisites, or error handling, which is important for a mutation tool.
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. The description adds significant value by explaining the JSON structure of toc_data in detail, including required fields, example, and the distinction between new and existing nodes, going beyond the schema's basic description.
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 updates the table of contents (TOC) for a repo/book, using a specific verb and resource. It is distinct from sibling tools like yuque_get_toc (read) and yuque_update_book (book metadata), providing no ambiguity.
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 gives detailed structure requirements for toc_data and examples, implicitly guiding usage. However, it lacks explicit when-to-use versus alternatives like yuque_update_book or yuque_update_doc, which handle different resources.
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_create_bookyuque_create_docyuque_create_noteyuque_create_resourceyuque_get_bookyuque_get_docyuque_get_noteyuque_get_resourceyuque_get_tocyuque_get_useryuque_list_booksyuque_list_docsyuque_list_notesyuque_searchyuque_update_bookyuque_update_docyuque_update_noteyuque_update_resourceyuque_update_tocScored across 19 tools
Each tool targets a specific resource type and action (e.g., create, get, list, update) with clear naming prefixes like yuque_create_book, yuque_get_doc, etc. No two tools have overlapping purposes, making selection unambiguous.
All tools follow a consistent 'yuque_verb_noun' pattern using lowercase snake_case. The verbs are uniform (create, get, list, update) and the nouns correspond to resource types (book, doc, note, resource, toc), ensuring predictability.
With 19 tools covering books, docs, notes, resources, TOC, search, and user info, the count is on the higher side but still reasonable for a platform with multiple resource types. Each tool serves a distinct purpose without redundancy.
The toolset lacks delete operations for any resource type (books, docs, notes, resources, TOC). There is also no listing for resources or TOC items. These gaps prevent full lifecycle management and may cause agent failures when cleanup is needed.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
DocBase MCP server for AI agents
MCP server for AI dialogue using various LLM models via AceDataCloud
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
