yuque-mcp-plus

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, but there is some ambiguity with aliases like yuque_get_docs/yuque_list_docs and yuque_get_repos/yuque_list_repos, which could cause confusion despite being for compatibility. Additionally, generic tools like yuque_request and yuque_multipart_request overlap in functionality with more specific tools, potentially leading to misselection.
Naming Consistency5/5
All tools follow a consistent yuque_verb_noun naming pattern using snake_case, with verbs like create, get, update, delete, and list. Aliases are explicitly noted for compatibility but maintain the same structure, ensuring predictability and readability throughout the tool set.
Tool Count3/5
With 35 tools, the count is borderline high for a Yuque API wrapper, as it includes many specific operations and aliases that might feel heavy. While it covers extensive functionality, a more streamlined set could reduce complexity without losing core capabilities, making it slightly over-scoped.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for Yuque's domain, including repositories, documents, TOC nodes, groups, and users. It handles creation, retrieval, updating, deletion, searching, and statistics, with no obvious gaps that would hinder agent workflows, ensuring complete surface coverage.
Average 2.8/5 across 35 of 35 tools scored. Lowest: 1.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 MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but offers no behavioral details. It omits critical mutation context: error handling for duplicate names, whether the operation is atomic, required authentication scope, or what distinguishes success from failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief (three words), the description is under-specified rather than appropriately concise. For a 6-parameter mutation tool with no annotations, this length fails to front-load essential behavioral or contextual information, leaving the agent under-informed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Severely inadequate for a creation tool with owner-type enums and public/private flags. No output schema, annotations, or description text explains return values, side effects, or the relationship between ownerLogin and ownerType fields.
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?
The input schema has 100% description coverage with clear field definitions (name, slug, ownerType, etc.). The description adds no parameter-specific guidance, but with comprehensive schema documentation, the baseline score of 3 is appropriate per rubric guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a repository.' is a tautology that merely restates the tool name in verb-noun form. It fails to specify what constitutes a repository in the Yuque context (knowledge base vs. code repository) and does not differentiate from sibling tools like yuque_update_repo or yuque_create_doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., yuque_update_repo), nor prerequisites such as required permissions or ownership constraints. The agent receives no signals about workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, yet provides no information about result pagination limits (despite having a page parameter), result schema, case sensitivity, or rate limiting. The agent cannot determine if this is read-only or what the search returns without trial invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words ('Search Yuque content.'), it is technically concise, but severely under-loaded for a four-parameter tool with no annotations. The single sentence fails to earn its place by providing insufficient information density.
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 four parameters, 100% schema coverage but minimal descriptions therein, no annotations, and no output schema, the description inadequately prepares the agent to interpret results or understand search scope. It should explain what Yuque content comprises or what the search returns.
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% with all four parameters documented. The description adds no parameter-specific semantics (e.g., explaining query syntax, page size defaults, or that repoId restricts scope), but baseline 3 is warranted given the schema carries the full load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a basic verb ('Search') and resource ('Yuque content'), but fails to specify the searchable entity types (DOC, BOOK, USER per the schema enum) or distinguish from sibling list/get operations like yuque_get_docs or yuque_list_docs. It is minimally informative and borders on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use search versus alternatives like yuque_get_docs, yuque_list_docs, or yuque_get_repo. No mention of prerequisites, required authentication scope, or when the optional repoId filter should be applied.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions 'Update' implying mutation, but fails to disclose whether this performs a partial update (PATCH) or full replacement (PUT), does not mention idempotency, side effects, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single 3-word sentence. While not verbose, it is under-specified to the point where the sentence fails to earn its place—it conveys no information beyond what is obvious from the tool name, representing under-specification rather than efficient conciseness.
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 6 parameters, no output schema, and no annotations, the tool requires substantial descriptive context. The description fails to explain the partial update capability (all optional parameters), the identification mechanism for the repository, or expected outcomes, leaving critical gaps for an AI agent attempting to use the tool.
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%, establishing a baseline of 3. The description adds semantic grouping by labeling the fields as 'metadata', but provides no additional context on parameter relationships (e.g., that repoId OR repoNamespace must be provided) or the partial update semantics implied by zero required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update repository metadata' restates the tool name ('yuque_update_repo') with minimal expansion. While it identifies the verb ('Update') and resource ('repository'), it fails to distinguish from sibling tools like 'yuque_update_repository_toc' or clarify what constitutes 'metadata' in this context versus other update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as requiring either 'repoId' or 'repoNamespace' to identify the target repository, despite having 6 parameters with 0 required fields.
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?
With no annotations provided, the description carries the full burden of disclosure. While 'Delete' implies destruction, it fails to disclose critical behavioral traits: whether the deletion is permanent/irreversible, whether child documents are cascade-deleted or orphaned, and what authorization is required. This gap is dangerous for a destructive operation.
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?
Extremely brief (3 words). While it wastes no words, it is under-specified rather than elegantly concise. The brevity fails to front-load critical safety information for a destructive action.
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?
Inadequate for a destructive repository operation. With no output schema and no annotations, the description should explain the relationship between the two identification parameters (ID vs namespace) and cascade behavior. It provides none of this context.
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% (repoId and repoNamespace are both documented). The description adds no additional parameter clarifications (e.g., whether both are required or if one suffices for identification), meeting the baseline expectation when the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the obvious ('Delete a repository' restates the function name yuque_delete_repo). While it identifies the resource type (distinguishing from siblings like delete_doc), it adds minimal semantic value beyond the name itself, bordering on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus alternatives (e.g., when to archive vs delete), no prerequisites (ownership/permissions), and no warning about the consequences for contained documents.
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, leaving full burden to description. The description omits safety characteristics (read-only vs mutation), error conditions (what happens if neither repoId nor repoNamespace provided), or return value format. Only implies read operation via 'Get'.
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?
Extremely concise at three words, but excessively so. Structure is fine (verb + object) but content is too minimal to provide value. Not verbose, but under-specified.
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?
Insufficient for tool complexity. With 2 optional parameters (mutually exclusive or alternative identifiers) and no output schema, description should explain parameter relationships or expected behavior. Sibling tools suggest rich ecosystem requiring differentiation.
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%, with both repoId and repoNamespace documented in the schema. Description adds no parameter semantics beyond schema, which warrants baseline score 3 per rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get repository detail' is tautological, essentially restating the tool name 'yuque_get_repo'. It fails to distinguish from sibling 'yuque_get_repos' (list operation) or clarify that this retrieves a single repository versus multiple.
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?
Provides no guidance on when to use this tool versus alternatives like 'yuque_get_repos' or 'yuque_get_default_repository'. Does not explain that neither parameter is required (0 required params), implying users must provide at least one identifier without stating this logic.
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?
With no annotations provided, the description carries the full disclosure burden yet fails to specify partial update semantics (whether omitted optional fields like title/body/format preserve existing values or are cleared), versioning behavior, or what response is returned.
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 single sentence is appropriately brief and front-loaded, but suffers from under-specification rather than efficient information delivery given the tool's complexity.
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?
For a 6-parameter mutation operation with no output schema or annotations, the description is inadequate. It lacks context about the Yuque platform, error conditions, field mutability rules, or the interaction between docId and repository identifiers.
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%, providing the baseline score. The description adds no parameter relationships (e.g., whether repoId and repoNamespace are mutually exclusive options) or semantic constraints beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Update an existing doc" merely expands the camelCase tool name into a sentence without adding specificity. It fails to distinguish from siblings like yuque_create_doc or indicate which document attributes can be modified.
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 provided on when to use this tool versus yuque_create_doc (create vs update) or yuque_get_doc (read vs mutate), nor any mention of prerequisites like authentication or repository membership requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description carries the full burden but discloses nothing regarding read-only nature, pagination behavior, rate limits, or return structure despite being a 'list' operation that typically returns collections.
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?
Extremely concise single sentence with no redundancy, though arguably insufficient given the complete absence of behavioral context and output schema.
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?
With no output schema, no annotations, and three optional filter parameters, the description fails to explain the listing behavior, pagination, or return format. The alias explanation is the only context provided.
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%, providing complete documentation of the three optional filtering parameters. Description adds no parameter-specific guidance, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies the tool as an alias of yuque_get_repos and explains the naming rationale ('compatibility with official naming'), but fails to describe the actual function of listing repositories, requiring inference from the tool name.
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?
Implies interchangeability with yuque_get_repos but provides no explicit guidance on when to prefer this tool versus the canonical version, nor when to use this versus other repository tools like yuque_get_repo (singular).
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, so the description carries full disclosure burden. It fails to specify what metrics are returned, whether the operation is read-only, or any rate limiting concerns. Beyond the implicit 'Get', no behavioral traits are disclosed.
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?
Single sentence with no redundancy, but brevity crosses into under-specification. Lacks front-loaded differentiators or scope definitions that would help distinguish from sibling tools.
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 three specific sibling statistics tools and no output schema or annotations, the description should clarify what statistics 'overall' includes. It fails to compensate for missing structured data or explain the relationship to specific statistic variants.
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 has 100% description coverage for the single 'login' parameter ('Group login.'). The main description adds minimal semantic value beyond the schema, merely confirming this relates to a 'group'. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('overall statistics for a group'), but critically fails to distinguish from siblings yuque_group_book_stats, yuque_group_doc_stats, and yuque_group_member_stats. It does not clarify what 'overall' encompasses versus these specific variants.
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 provided on when to use this tool versus the specific group statistics siblings (book/doc/member stats). No mention of prerequisites, required permissions, or alternatives.
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. While 'Get' implies a read-only operation, the description lacks disclosure about error handling (e.g., 404 behavior), response format (Markdown vs HTML), or authentication requirements.
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?
Extremely brief single sentence with no redundancy or wasted words. However, maximizing conciseness sacrifices necessary context, making it too minimal rather than appropriately sized for the tool's complexity.
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?
With 3 parameters (2 optional), no annotations, and no output schema, the description is insufficient. It fails to explain the relationship between the required docId and optional repo parameters, nor does it hint at the return structure for this document retrieval operation.
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?
The input schema has 100% description coverage, establishing a baseline of 3. The description adds no parameter-specific context (e.g., explaining that repoId and repoNamespace are mutually exclusive optional scoping parameters), but does not need to compensate given the complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action (Get) and resource (doc detail) plus the key identifier (doc ID), which minimally distinguishes it from sibling list operations like 'yuque_get_docs'. However, it does not clarify what 'detail' encompasses compared to 'yuque_get_doc_version' or other retrieval tools, and largely restates the tool name.
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?
Provides no guidance on when to use this versus 'yuque_get_docs' or 'yuque_list_docs', nor does it explain when the optional repoId or repoNamespace parameters are required (e.g., for private repositories vs public access).
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, yet the description adds no behavioral context: it doesn't confirm the read-only nature, mention return format, hint at pagination behavior, or disclose 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?
Extremely terse (5 words) and front-loaded with the verb, but underspecified rather than efficiently concise given the parameter complexity.
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?
Insufficient for a 4-parameter pagination tool with no output schema: lacks guidance on repository identification logic, pagination cursor behavior, and return structure.
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 has 100% description coverage, establishing baseline 3. The description adds no additional semantics (e.g., that repoId and repoNamespace are mutually exclusive options, or pagination defaults).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('List') and resource ('docs in a repository'), but fails to distinguish from sibling tools 'yuque_list_docs' and 'yuque_get_doc' (singular), leaving ambiguity about when to use each.
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?
Provides no guidance on which repository identifier to use (repoId vs repoNamespace, both optional in schema) or when to prefer this tool over 'yuque_list_docs' or 'yuque_get_doc'.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but reveals nothing beyond the operation type. It omits what specific statistics are returned (count, views, size), whether the operation is read-only, or any permission requirements specific to group data access.
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?
Extremely concise at five words. While no words are wasted, the description is under-specified rather than efficiently informative. It front-loads the action but lacks supporting context that would justify its brevity.
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?
Inadequate for a statistics retrieval tool with no output schema. The description fails to specify what statistical metrics are returned (document counts, view statistics, storage usage), leaving the LLM with no understanding of the tool's utility or return value structure.
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?
Input schema has 100% coverage ('Group login.') and the description mentions no parameters. While the schema adequately documents the single required field, the description adds no semantic value regarding what constitutes a group login or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Provides a specific verb ('Get') and resource ('repository statistics for a group'), but fails to distinguish from siblings like 'yuque_group_stats' (general group stats) or clarify that 'book' in the name maps to 'repository' in the description. The terminology gap and lack of scope differentiation create ambiguity in a dense toolset.
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 provided on when to use this versus 'yuque_group_stats', 'yuque_get_repo', or other similar retrieval tools. Given the numerous sibling statistics and repository tools, the absence of selection criteria forces the LLM to guess based on naming conventions alone.
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?
With no annotations provided, the description carries full burden but reveals only that this is a read operation. It omits what specific statistics are returned (counts, views, etc.), error handling for invalid groups, rate limits, or authentication requirements.
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?
Extremely brief at six words with no redundancy. While efficient, the extreme brevity may be underspecified given the lack of behavioral annotations or output schema, though this reflects completeness rather than structural issues.
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?
Despite having only one parameter, the tool lacks critical context: no output schema is provided, no annotations indicate destructive/read-only status, and the description fails to clarify the return data structure or distinguish from related group statistics endpoints.
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% (single parameter with description 'Group login'), establishing baseline 3. The description mentions 'for a group' which aligns with the parameter but adds no additional semantic context about login format, validation rules, or examples beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Get) and resource (document statistics for a group), but fails to distinguish from siblings like 'yuque_group_stats' or 'yuque_group_book_stats', leaving ambiguity about when to select this specific endpoint versus broader group statistics.
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?
Contains no guidance on when to use this tool versus alternatives (e.g., yuque_group_stats), prerequisites for the group login parameter, or conditions where this should be preferred over repository-level document queries.
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, so description carries full burden. 'Delete' implies destruction but lacks critical disclosure: permanence vs soft-delete, authentication requirements, cascading effects (TOC removal), or error handling for non-existent IDs.
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?
Extremely brief (3 words) with no redundancy, but underspecified rather than optimally concise. Given destructive nature and unexplained optional parameters, the brevity leaves critical gaps rather than earning efficiency points.
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?
Insufficient for a destructive 3-parameter tool with no annotations or output schema. Missing: behavioral safety details, optional parameter rationale, return value description, and sibling differentiation expected for deletion operations.
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%, establishing baseline 3. Mentions 'by ID' hinting at docId, but adds no semantic value for the optional repoId/repoNamespace parameters (why they exist, validation rules, or when to include them).
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?
Clear verb (Delete) + resource (doc) + identifier method (by ID). Specifies 'doc' distinguishing from sibling tools yuque_delete_repo and yuque_delete_toc_node. Could be 5 if it explicitly contrasted with repo/toc deletion or clarified Yuque-specific behavior.
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?
Provides no guidance on when to use versus alternatives (e.g., yuque_update_doc for archiving), nor does it explain the optional repoId/repoNamespace parameters or why only docId is required.
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?
With no annotations provided, the description carries the full disclosure burden but provides minimal behavioral context. It states the alias relationship but does not clarify that this is a read-only operation, what data structure it returns, error conditions, or whether it requires authentication/authorization.
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 single-sentence description is efficiently structured and front-loaded with the essential alias information. Every word serves a purpose, though extreme brevity is insufficient given the lack of supporting annotations or output schema.
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?
Without annotations or output schema, the description should explain return values and operational behavior. Merely stating 'alias' leaves critical gaps in the agent's understanding of what invoking this tool actually accomplishes or returns.
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?
Input schema has 100% description coverage (repoId and repoNamespace are fully documented). The description adds no parameter-specific context (e.g., mutual exclusivity rules, namespace format examples), warranting the baseline score of 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an alias of 'yuque_get_repository_toc_tree' and mentions 'official naming' compatibility, which provides relational context. However, it fails to state what the tool actually does (retrieves table of contents), relying entirely on the tool name and the referenced sibling tool's presumed functionality.
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 phrase 'for compatibility with official naming' weakly implies when this variant might be preferred over the sibling tool. However, there is no explicit guidance on when to use this versus yuque_get_repository_toc_tree, or whether there are behavioral differences between the two.
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure but offers minimal detail. It fails to explain the hierarchical manipulation behavior (child vs sibling, append vs prepend), does not clarify that targetUuid is an alias for parentUuid, and omits mutation consequences such as whether the operation is atomic or how it affects document visibility.
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 single sentence is efficient and contains no redundant words. It front-loads the action (Create) and specifies the resource types immediately, making it easy to parse.
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?
For a 9-parameter mutation tool involving complex hierarchical positioning (parent/sibling relationships, append/prepend logic), the description is inadequate. It lacks explanation of the tree structure mechanics, positioning behavior, and the alias relationship between targetUuid and parentUuid that is critical for correct invocation.
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 100% schema description coverage, the baseline is 3. The description reinforces the nodeType enum values (TITLE/LINK) providing semantic context beyond the schema's generic 'Node type' label. However, it does not compensate for vague schema descriptions like 'TOC action mode' or explain the UUID relationships.
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 clearly states the verb (Create), the resource (TITLE or LINK node), and the location (repository TOC tree). It effectively distinguishes from siblings like yuque_create_doc and yuque_create_repo by specifying 'TOC tree'. However, it does not differentiate from yuque_update_repository_toc or yuque_update_toc, leaving potential ambiguity about when to create vs update.
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 explicit guidance is provided on when to use this tool versus alternatives like yuque_update_toc. It does not explain when to choose TITLE versus LINK types, nor does it mention prerequisites such as requiring either repoId or repoNamespace.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic deletion action. It fails to disclose whether deletion is permanent, how the server resolves the delete strategy when parentUuid is omitted (mentioned only in the schema), or whether child nodes are affected.
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 a single, efficient sentence with zero redundancy. Every word earns its place by conveying the action, target type, and location context upfront.
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's moderate complexity (6 parameters with interdependencies like targetUuid being an alias of parentUuid, an enum for actionMode, and a destructive operation), the single-sentence description is insufficient. It lacks explanation of output behavior and the semantic distinctions between optional parameter combinations.
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%, establishing a baseline of 3. The description mentions 'TITLE or LINK' node types, which adds semantic context not explicitly constrained in the schema, but does not elaborate on the relationship between repoId/repoNamespace or clarify the alias relationship between parentUuid and targetUuid mentioned in the schema.
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 uses a specific verb ('Delete') and clearly identifies the resource ('TITLE or LINK node from the repository TOC tree'), which distinguishes it from sibling tools like yuque_delete_doc or yuque_delete_repo. However, it lacks context on what distinguishes TITLE from LINK nodes or when to prefer this over yuque_update_repository_toc.
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 provides no guidance on when to use this tool versus alternatives (e.g., yuque_update_repository_toc), nor does it mention prerequisites such as requiring either repoId or repoNamespace to identify the target repository.
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, so description carries full burden. While 'Get' implies read-only, it does not explicitly confirm safe/non-destructive behavior, disclose what data structure is returned, or explain what constitutes a document 'version' in Yuque.
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?
Extremely brief at 5 words with no wasted words and front-loaded action verb. However, extreme brevity comes at the expense of necessary context for a versioning tool.
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?
Insufficient for a version control operation. With no output schema or annotations, the description should explain that this retrieves historical content, what the version contains, or how it relates to the current document, but provides none of this.
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 has 100% description coverage for the single versionId parameter. The description adds no semantic information about the parameter, but baseline 3 applies per scoring rules for high schema coverage.
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?
Clear verb 'Get' and resource 'document version', with 'specific' distinguishing it from sibling yuque_list_doc_versions. However, it fails to clarify the critical distinction from yuque_get_doc (historical version vs current document).
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 on when to use this tool versus siblings like yuque_get_doc or yuque_list_doc_versions. Missing crucial prerequisite: that versionId must typically be obtained from yuque_list_doc_versions first.
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, so description carries full burden. Only states 'List' implying read-only, but omits pagination behavior, rate limits, result ordering, or what data fields are returned. Does not clarify that all parameters are optional with complex interdependencies.
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?
Single sentence of 11 words is appropriately concise and front-loaded with the action verb. However, extreme brevity leaves gaps given the tool has 3 optional parameters with non-obvious interactions.
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?
Insufficient for a tool with 3 optional parameters and ambiguous sibling relationships. Lacks output guidance (no output schema), pagination info, and fails to resolve the apparent redundancy with 'yuque_list_repos'.
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% with adequate field descriptions. Description adds context 'current user or a specified user' which loosely maps to parameters, but does not explain parameter relationships (userId vs ownerLogin) or when to use ownerType. Baseline 3 appropriate given schema quality.
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?
Clear verb 'List' and resource 'Yuque repositories' with scope 'for the current user or a specified user'. However, fails to distinguish from sibling tool 'yuque_list_repos' which appears to serve an identical purpose based on naming.
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 explicit guidance on when to use versus alternatives (particularly 'yuque_list_repos' or 'yuque_get_repo'), no prerequisites mentioned, and no guidance on parameter selection between userId vs ownerLogin/ownerType.
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, so description carries full burden. States 'Get' implying read-only but does not disclose what statistics are returned (counts? activity metrics?), rate limits, or whether data is real-time versus cached. Missing behavioral context for a statistics endpoint.
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?
Single sentence, front-loaded with verb. Appropriate length for the information conveyed, though arguably under-sized for the complexity of behavioral disclosure needed. No wasted words.
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?
Adequate for low complexity (1 param, no nesting) but clear gaps remain. With no output schema, description should indicate what statistical data is returned to help agents select over alternatives like list_group_members.
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 has 100% coverage with 'Group login' described. Description mentions 'for a group' aligning with the login parameter but adds no syntax details, format examples, or where to obtain the login value. Baseline 3 appropriate since schema carries full load.
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?
Clear verb ('Get') and resource ('member statistics') with scope ('for a group'). Distinguishes from siblings like yuque_group_stats (general stats) and yuque_list_group_members (listing vs statistics), though could specify what statistics are returned.
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 on when to use this versus yuque_list_group_members or other sibling tools. No mention of prerequisites like group membership requirements or when statistics are available versus raw member lists.
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?
With no annotations provided, the description carries the full disclosure burden but offers minimal behavioral context. It does not explain what the endpoint returns, whether it has side effects, rate limits, or if it requires authentication to succeed.
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?
Extremely concise at six words. While not wasteful, it is under-specified for the behavioral transparency needed. A brief addition about the endpoint's purpose would improve this without sacrificing 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 zero parameters and likely simple health-check semantics, the description is minimally sufficient. However, with many sibling tools available, clarifying this tool's specific role (e.g., 'auth/connection test') would improve completeness.
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?
Input schema contains zero parameters, triggering the baseline score of 4. The description appropriately implies no configuration is needed for this endpoint call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it calls the Yuque hello endpoint, identifying the service and specific endpoint. However, it fails to explain what the hello endpoint actually does (e.g., connectivity test, auth verification) or why an agent would invoke it versus alternatives like yuque_request.
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 provided on when to use this tool versus the generic yuque_request tool or other alternatives. No mention of prerequisites, typical use cases (e.g., testing credentials), or when to avoid using it.
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?
With no annotations provided, description carries full disclosure burden but states only the basic operation. Missing: pagination behavior, sort order (chronological?), maximum versions returned, and whether current version is included.
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?
Six-word description is efficiently front-loaded with no redundancy. However, brevity leaves behavioral gaps given lack of annotations and output schema.
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?
Minimum viable for a single-parameter list operation with no output schema. Would benefit from stating what version metadata (timestamp, author, etc.) is returned in the list.
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% (docId is fully documented as 'Yuque doc ID'), establishing baseline 3. Description adds no additional parameter context (e.g., where to find this ID).
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?
Clear specific verb (List) and resource (document versions). Plural 'versions' implicitly distinguishes from sibling 'yuque_get_doc_version' (singular), though explicit comparison would strengthen this.
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 provided on when to use this versus 'yuque_get_doc_version' or prerequisites for accessing version history.
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, so description carries full burden, yet it omits pagination behavior, return data structure, authentication requirements, and 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?
Single sentence with no redundancy, though arguably too minimal given the lack of annotations and output schema.
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?
Without an output schema, the description fails to indicate what member data is returned (e.g., user IDs, names, roles) or pagination behavior, leaving significant gaps for an API listing tool.
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 has 100% description coverage for the single 'login' parameter. Description adds no additional parameter context, but none is needed given complete schema documentation.
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?
Clear verb (List) and resource (members of a group/team), but does not explicitly differentiate from sibling yuque_group_member_stats which handles statistics rather than member listings.
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?
Provides no guidance on when to use this tool versus alternatives like yuque_group_member_stats, nor prerequisites for accessing group membership data.
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, placing the full burden of behavioral disclosure on the description. The description fails to disclose that this is a destructive operation (irreversible removal), whether the user’s content is reassigned or deleted, or what error occurs if the userId is not a member.
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 single sentence 'Remove a member from a group.' is efficiently structured and front-loaded with the action verb. It contains no redundant words, though it is arguably underspecified given the tool's destructive nature and lack of annotations.
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?
For a destructive group management operation with no annotations and no output schema, the description is inadequate. It omits critical safety context such as permission requirements, cascade effects on user data, and confirmation that the operation permanently severs the group relationship.
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 100% schema description coverage, the schema already fully documents both parameters ('Group login' and 'Yuque user ID'), establishing the baseline of 3. The description adds minimal semantic value beyond mapping 'group' and 'member' to these parameters.
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 uses the specific verb 'Remove' with the clear resource 'member from a group,' accurately describing the operation. However, it does not distinguish from the sibling tool `yuque_update_group_member` (which modifies membership roles rather than removing entirely), which could cause selection confusion.
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 provides no guidance on when to use this tool versus alternatives (e.g., `yuque_update_group_member`), no prerequisites (such as requiring the user to be a current member), and no warnings about irreversibility.
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, so the description carries the full burden of behavioral disclosure. It fails to mention permission requirements, preconditions (that the user must already be a group member), idempotency, or side effects of the mutation.
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?
Single sentence with five words, zero redundancy, immediately conveys the core action without extraneous information.
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?
Inadequate for a mutation tool with no annotations or output schema. Missing critical context about authentication requirements, authorization levels needed to modify roles, and expected behavior when the target user is not already a member.
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% with clear descriptions for all three parameters (login, userId, role with value mappings). The description adds minimal semantic value beyond what the schema already provides, meeting the baseline for high-coverage schemas.
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?
"Update a group member role" provides a clear verb (update) and resource (group member role). However, it does not differentiate from sibling yuque_remove_group_member or clarify when to update roles versus remove members entirely.
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 provided on when to use this tool versus alternatives, prerequisites (e.g., requiring admin/owner permissions), or expected workflows for role management.
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?
With no annotations provided, the description carries the full disclosure burden. While 'raw' hints at the payload format, it fails to specify whether this replaces the entire TOC or partial updates, what authentication/permissions are required, or that only 'payload' is strictly required while repoId/repoNamespace are optional identifiers.
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 a single efficient sentence with no redundancy. However, given the complexity of the operation (mutation with nested object payload) and the presence of many similar siblings, it is arguably too terse and could benefit from front-loading the constraint that this requires manual payload construction.
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 mutation tool with no annotations and no output schema, the description adequately identifies the operation but leaves critical gaps. It should clarify payload structure expectations, explain that repoId/repoNamespace are alternative identifiers (not both required), and hint at atomicity or side effects of TOC updates.
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?
Input schema has 100% description coverage (baseline 3), so the schema adequately documents each field. The description adds minimal semantic value beyond labeling the payload as 'raw,' which reinforces the schema's 'object' type but does not explain the payload's expected structure or the relationship between repoId and repoNamespace (either can identify the repository).
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 uses a specific verb ('Send') and identifies the resource ('repository TOC API'), and the term 'raw' distinguishes it from higher-level TOC manipulation siblings like yuque_update_toc or yuque_create_toc_node. However, it does not explicitly clarify when to use this low-level endpoint versus the more granular node-specific tools.
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 prefer this tool over siblings (yuque_update_toc, yuque_create_toc_node) or what prerequisites are needed. The description hints at low-level API access ('raw payload') but does not state that the agent must construct the payload manually versus using structured parameters.
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?
Zero annotations are provided, so the description carries the full disclosure burden for what is clearly a mutation operation ('update'). However, it reveals nothing about side effects (e.g., whether this restructures documents), authorization requirements, idempotency, or rate limits. The alias reference suggests identical behavior to the sibling, but defers all behavioral transparency.
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 efficient at 11 words in a single sentence. Every word earns its place: it identifies the alias target and the rationale. No redundancy or filler content.
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?
For a mutation tool with a nested object payload (containing unknown TOC structure) and no output schema, the description is insufficient. It provides no insight into the payload structure, expected return values, or operational consequences, relying entirely on the sibling tool's documentation which may not always be visible in context.
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?
Input schema has 100% description coverage (repoId, repoNamespace, payload are all described). The description adds no parameter-specific semantics, syntax examples, or validation rules beyond what the schema provides, meriting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an alias of yuque_update_repository_toc and explains the compatibility rationale, but fails to state what functional operation it performs (updating a table of contents). An agent selecting this tool would not understand the action semantics without cross-referencing the sibling tool.
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 phrase 'for compatibility with official naming' implies a specific usage context (when adhering to official Yuque API nomenclature), but lacks explicit guidance on when to prefer this alias over the canonical yuque_update_repository_toc or vice versa. No prerequisites or exclusion criteria are provided.
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?
With no annotations provided, the description carries full disclosure burden but only explains TOC attachment behavior. It fails to disclose that this is a mutating write operation, potential failure modes (duplicate titles, invalid repo), return value structure, or whether the operation is idempotent.
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?
Extremely terse at two sentences with no waste, and properly front-loaded with the primary action. However, given the 7-parameter complexity, lack of annotations, and mutation nature, the description is undersized—failing to explain critical behavioral aspects that would guide proper invocation.
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?
Inadequate for a creation tool with no output schema and no annotations. Missing: return value documentation, repoId vs repoNamespace relationship (both optional in schema but likely one required), format default behavior, and confirmation that this performs a write operation.
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?
While schema coverage is 100% (baseline 3), the description adds valuable semantic context for parentUuid specifically—explaining that the doc attaches 'under that TOC node' rather than merely identifying it as a UUID, clarifying the hierarchical relationship implied by the parameter.
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 clear verb ('Create') and resource ('doc'), distinguishing from sibling tools like yuque_update_doc and yuque_delete_doc. However, it could explicitly identify this as a Yuque document versus generic documentation to further differentiate from repo/table of contents creation tools.
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?
Provides implicit guidance by explaining the parentUuid attachment behavior (when to use that parameter), but lacks explicit when-to-use guidance versus siblings like yuque_create_toc_node or prerequisites like requiring valid repo credentials.
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, yet description fails to disclose critical behavioral traits: authentication requirements needed for 'current' user resolution, what user attributes are returned, or error behavior when unauthenticated. Carries minimal behavioral burden.
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?
Extremely brief (5 words), but no wasted language. Front-loaded action verb. However, given lack of supporting metadata (annotations/output schema), appropriate length would include slightly more context.
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?
Adequate for a simple zero-parameter read operation, but gaps remain: no mention of return structure (user profile fields) despite absent output schema, and silent on auth/session requirements which are critical for 'current' user semantics.
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?
Zero parameters present; per scoring rules, baseline is 4. Description correctly implies no inputs are needed to retrieve the current user context.
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?
Clear verb ('Get') and specific resource ('current Yuque user'). Effectively distinguishes from sibling tools that operate on repos, docs, and groups by targeting the authenticated user entity.
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?
Provides no guidance on when to invoke (e.g., to check authentication status or retrieve user ID for subsequent calls) nor prerequisites (authentication requirements). No alternatives or exclusions mentioned.
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, so description must carry full burden. It fails to disclose behavioral details: what happens to the original location (is it removed or copied?), implications of actionMode 'child' vs 'sibling', or whether the operation is atomic/reversible. Only mentions UUIDs are used.
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?
Single sentence, front-loaded with verb 'Move'. No redundant words. Efficiently conveys core operation without extraneous information.
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?
Adequate for identifying the tool's function, but incomplete given complexity: no mention of return values (no output schema), silent on parameter interdependencies (docId resolves nodeUuid), and omits behavioral implications of position and actionMode enums.
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% with all 8 parameters documented. Description provides baseline context mapping 'doc' to docId and 'TOC node' to nodeUuid, but adds no syntax details, valid formats, or explanations of the parentUuid/targetUuid alias relationship beyond the schema.
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 specific action 'Move' and resources 'doc or TOC node' with destination 'another parent'. Distinguishes from siblings like create_doc or delete_toc_node by focusing on relocation, though doesn't explicitly clarify difference from update_toc.
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?
Provides no guidance on when to use this tool versus alternatives like update_toc or update_repository_toc. Does not mention prerequisites (e.g., needing UUIDs from get_toc) or the relationship between docId and nodeUuid parameters (mutual exclusivity).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'multipart' indicating the HTTP mechanism, it fails to disclose mutation safety, auth requirements, rate limits, return value structure, or potential side effects of uploading files to arbitrary paths.
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 a single, efficient sentence with no wasted words. It front-loads the key identifier ('Generic Yuque multipart request') and qualifies it with use cases. It is appropriately concise, though the complexity of this generic tool arguably warrants a second sentence explaining its role as an escape hatch.
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 100% schema coverage and 5 well-documented parameters, the description provides the minimum viable context for a low-level HTTP utility. However, as a generic 'escape hatch' tool among many specific resource-oriented siblings, it should explicitly state that this is for operations not covered by specific tools (like attachment uploads) and warn about the low-level nature of the operation.
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%, establishing a baseline of 3. The description adds domain context ('multipart,' 'upload-style') that helps clarify the intent behind the `files` and `fields` parameters, but does not elaborate on specific parameter syntax, validation rules, or interdependencies beyond what the schema already documents.
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 identifies this as a multipart request tool for 'upload-style endpoints' and 'attachment workflows,' providing a clear verb (request) and resource scope. It implicitly distinguishes this from the sibling `yuque_request` tool by specifying 'multipart,' though it could explicitly clarify when to choose this over the generic request tool.
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 implies usage context through examples like 'attachment workflows' and 'upload-style endpoints,' suggesting when it might be needed. However, it lacks explicit guidance on when NOT to use this tool (e.g., for standard JSON API calls) or direct comparison to the `yuque_request` sibling.
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. Successfully conveys this returns a hierarchical structure ('tree', 'nested') and is comprehensive ('full'). Missing behavioral details like performance characteristics, rate limits, or whether this is an expensive operation compared to flat TOC retrieval.
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?
Single sentence, front-loaded with the action, zero redundancy. Every phrase earns its place: 'full' signals completeness, 'tree' signals hierarchy, 'nested directories and docs' specifies scope.
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?
Adequate for a 2-parameter read operation without output schema. Covers core purpose but has gaps regarding sibling tool relationships and parameter usage logic. Should explain how this differs from 'yuque_get_toc' (likely flat vs hierarchical) to ensure correct agent selection.
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% with clear descriptions for repoId and repoNamespace. Description adds no parameter-specific details, meeting baseline 3. Does not compensate for the schema's lack of guidance on parameter mutual exclusivity (which identifier to use when).
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?
Clear verb (Get) and resource (repository TOC tree) with scope details (full, nested directories and docs). However, lacks explicit differentiation from sibling tool 'yuque_get_toc', leaving ambiguity about which TOC retrieval tool to select.
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?
Provides no guidance on when to use this versus 'yuque_get_toc' or other repository navigation tools. Also fails to clarify that while both repoId and repoNamespace are optional in schema, at least one is required to identify the target repository.
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 carry full behavioral disclosure burden. It states nothing about read/write status, return values, pagination behavior, or side effects, merely identifying the alias relationship.
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?
Single sentence with zero waste. Every word earns its place by conveying the alias relationship and the rationale ('compatibility'), appropriate for a tool that genuinely is just an alias.
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 4 parameters, no annotations, and no output schema, the description is insufficient. It identifies the alias but omits what the tool actually returns, what authentication is required, or how pagination behaves (despite limit/offset parameters).
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?
Input schema has 100% description coverage (repoId, repoNamespace, limit, offset all documented), establishing baseline 3. The description adds no parameter context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as an alias of yuque_get_docs but fails to specify what operation is actually performed (listing/retrieving documents). It relies on the reader inferring functionality from the sibling tool name rather than stating it directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the sibling tool (yuque_get_docs) and explains the specific condition for using this variant: 'for compatibility with official naming.' This provides clear guidance on when to use this tool versus its functional equivalent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but only states the basic action. It does not indicate whether this is a read-only operation, what permissions are required, whether the results are paginated, or what data structure is returned. For a list operation, some safety or scope context should be provided when annotations are absent.
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 a single, front-loaded sentence with no wasted words. The structure logically flows from action (List) to object (groups/teams) to scope (user context). Minor deduction for the ambiguous 'or teams' conjunction which could confuse users about whether these are separate entities.
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 low complexity (one optional parameter, no nested objects), the description adequately covers the basic invocation pattern. However, for a tool without annotations or output schema, it lacks completeness regarding authentication requirements, rate limiting, or the structure/pagination of returned group data that would help an agent handle the response properly.
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?
The schema has 100% coverage with 'Optional Yuque user ID'. The description adds meaningful semantic context by stating the tool works for 'current user or a specified user', which clarifies the default behavior when the optional parameter is omitted (returns current user's groups). This goes beyond the schema's type information.
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 clearly states the verb ('List') and resource ('groups or teams') with scope限定 ('for the current user or a specified user'). However, it uses 'groups or teams' without clarifying if these are distinct concepts or synonyms, and does not explicitly distinguish from siblings like 'yuque_list_group_members' (which lists members, not groups).
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 implies usage patterns by contrasting 'current user' versus 'specified user', which suggests when to provide the userId parameter versus omitting it. However, it provides no explicit guidance on when to use this tool versus alternatives like 'yuque_get_repos' or what prerequisites might exist for viewing another user's groups.
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?
Provides valuable behavioral context by disclosing the dual-source resolution logic (server config vs. heuristic), which is not captured in annotations. However, with zero annotations provided, the description should explicitly state this is a read-only operation and describe the return structure, which it omits.
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?
Single, efficient sentence front-loaded with the action verb 'Resolve'. The mechanism detail ('using server config or a fallback heuristic') earns its place by explaining the zero-parameter behavior.
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?
Appropriate for a simple lookup tool with no parameters and no output schema. The heuristic explanation provides necessary context for understanding how the default is determined, though explicitly stating the return type (repository object) would improve completeness.
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?
Input schema contains zero parameters, establishing baseline score of 4 per rubric. The description correctly implies no user input is needed for the resolution logic.
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 clearly that it determines (resolves) the default repository and explains the mechanism (server config or fallback heuristic), distinguishing it from sibling tools like `yuque_get_repo` which likely require specific IDs. However, it does not explicitly contrast with alternatives by name.
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?
Implies usage through specificity - one would use this when needing the default repository without specifying an ID. However, lacks explicit guidance on when to prefer this over `yuque_get_repos` or how the fallback heuristic behaves when multiple repos exist.
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, so description carries full burden. While 'passthrough' indicates direct API proxying, it fails to disclose that this supports destructive operations (DELETE, PUT), lacks rate limit warnings, or return value structure despite being a generic HTTP wrapper.
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?
Single 12-word sentence with zero waste. Front-loaded with the generic nature, followed immediately by the scope constraint. Every word earns its place.
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?
Adequate for a passthrough tool but missing critical safety context given it supports all HTTP methods including DELETE with no annotations or output schema. Should warn about destructive capabilities and auth requirements.
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 has 100% description coverage with clear descriptions for method, path, params, and body. Description contains minimal parameter-specific semantics, but with complete schema coverage, no compensation is needed; baseline 3 is appropriate.
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?
Excellent clarity: 'Generic Yuque OpenAPI request passthrough' specifies the verb/pattern, and 'for endpoints not wrapped by dedicated tools' clearly scopes it against the extensive sibling tool list (create_doc, get_doc, etc.).
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?
Clear when-to-use ('endpoints not wrapped by dedicated tools'), which implicitly defines when NOT to use it (use specific siblings instead). However, lacks explicit guidance to 'prefer dedicated tools first' or examples of covered endpoints.
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-plus MCP server](https://glama.ai/mcp/servers/MichealJou/yuque-mcp-plus/badges/card.svg)](https://glama.ai/mcp/servers/MichealJou/yuque-mcp-plus)

Score Badge

Copy to your README.md:

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

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/MichealJou/yuque-mcp-plus'

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