yuque-ai-mcp

yuque_create_book_stack

Creates a Yuque knowledge base group (book stack) with a specified name and optional sort position, automatically renaming it after creation to work around Yuque's naming limitation.

Instructions

创建知识库分组（书架）并设定名称。需要 cookie+ctoken 认证。语雀 create 不能直接指定名字，本工具内部 create 后自动 edit 改名。body {name, target_rank}。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "yuque_create_book_stack"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	分组名称（必填）
`target_rank`	No	目标排序位（可选，默认 0）

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.0.0Nov 13, 2026

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and does disclose two non-obvious traits: the cookie+ctoken auth requirement and the internal create-then-edit-rename sequence. It stops short of saying what happens if the rename step fails (possibly a stack left with a default name) or what the response contains.

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?

Three compact sentences, front-loaded with the action and followed by the auth constraint and the internal rename behavior. The final body-parameter sentence is redundant with the schema and could be dropped.

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?

For a two-parameter create tool with no annotations and no output schema, the description covers auth and the create-then-rename behavior, which is the important part. It leaves open whether duplicate names are allowed, what is returned on success, and how partial failures surface.

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 description coverage is 100%, so both name and target_rank are already documented, including required/optional status and the default of 0. The trailing 'body {name, target_rank}' merely restates the schema and adds no format, constraint, or ordering semantics.

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?

States a specific verb and resource: create a knowledge-base group (bookshelf) and set its name. The agent knows exactly what gets produced, but the description never distinguishes this from yuque_rename_book_stack or yuque_update_book_stack by name, so sibling selection still relies on inference.

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?

Usage is implied by the verb — call this when you need a brand-new stack with a given name. The only explicit context is the auth prerequisite (cookie+ctoken); there is no statement of when to prefer rename/update/sort siblings or any when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server