Skip to main content
Glama
Sign In
yuque-ai-mcp

yuque-ai-mcp

by yehuoshun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

yuque_web_get_doc

Retrieve complete Yuque document details, including body content in Markdown, Lake, or LakeSheet format, using cookie-based web API access without membership or token rate limits.

Instructions

Cookie-based: Get full document detail with body/content. Supports markdown/lake/lakesheet formats. Returns richer fields than v2 get_doc (54 fields including abilities, joinToken, etc.). No membership required, no Token rate limiting. GET /api/docs/{id}?book_id={book_id}. id supports doc slug; book_id supports namespace/slug (e.g. yehuoshun/utuif2) or numeric. 详见 references/api/doc_api.md

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": {
      "id": "<id>",
      "book_id": "<book_id>"
    },
    "name": "yuque_web_get_doc"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDocument ID or slug (required)
rawNoReturn raw full JSON (default false, returns trimmed fields)
book_idYesRepository ID, namespace or slug (e.g. yehuoshun/utuif2), or numeric (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • changedInput schema / properties / book_id / description
      Previous value: -"Repository ID (numeric, required)"New value: +"Repository ID, namespace or slug (e.g. yehuoshun/utuif2), or numeric (required)"
    • changedInput schema / properties / id / description
      Previous value: -"Document ID (numeric, required)"New value: +"Document ID or slug (required)"
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations exist, so the description must carry the whole burden, and it mostly does: auth mechanism (cookie), absence of membership/Token limits, the underlying GET endpoint, and the 54-field richer payload are all disclosed. Missing only explicit read-only/side-effect framing and pagination or size limits, which are minor for a fetch.

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?

A single dense, front-loaded paragraph: capability, format support, comparison to the sibling, auth constraints, endpoint, and parameter formats in that order. The trailing Chinese doc reference earns its place as a pointer, though the paragraph is packed tightly enough that it reads as a spec dump rather than prose.

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?

With no output schema, the description correctly compensates by naming the return payload richness (54 fields incl. abilities, joinToken) and the raw-vs-trimmed distinction. Auth and parameter formats are fully covered; only behavioral detail like whether trimmed output drops body content is left unstated.

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 100%, so the schema already documents id, book_id, and raw. The description repeats the same facts (slug support, namespace/slug or numeric book_id, raw returning untrimmed JSON) without adding syntax or edge-case meaning, so this is baseline.

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?

States a specific verb and resource ('Get full document detail with body/content') and immediately differentiates itself from the sibling yuque_get_doc by calling that one 'v2 get_doc' with fewer fields. An agent can pick between them without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear selection context: cookie-based, no membership needed, no Token rate limiting, richer than v2 get_doc. It does not state explicit when-not conditions (e.g. when the token-based yuque_get_doc is preferable), but the tradeoff is implied strongly enough to route most calls.

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

Deploy Server

Other Tools