yuque-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation3/5
Several convenience wrappers overlap with core tools: yuque_get_repository_overview duplicates yuque_get_repo_toc, yuque_create_document_with_toc overlaps yuque_create_doc, and yuque_search_and_read overlaps yuque_search_docs. These pairs create ambiguity about which tool to select for a given task.
Naming Consistency4/5
All tools follow a clear yuque_ verb_noun convention in snake_case. Minor deviations like add/remove vs create/delete for group users and composite suffixes (with_toc, from_file) are still readable and predictable.
Tool Count2/5
With 28 tools, the server exceeds the typical comfortable range and includes several redundant composite wrappers that inflate the count. The core domain could be covered with fewer tools, though the breadth of resources (users, groups, repos, docs) partially justifies the number.
Completeness5/5
The tool set covers full lifecycle for groups, repos, and docs: create, read, update, delete, list, and search operations are all present, plus membership management. No obvious critical gaps hinder typical workflows, and file-based document updates add useful functionality.
Average 3/5 across 28 of 28 tools scored. Lowest: 2.1/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 is passing
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?
No annotations are provided, so the description must disclose behavior fully. It only says 'Update', which implies mutation but does not mention side effects, required permissions, reversibility, or what happens to unspecified fields. For a mutation tool, this is a severe lack of transparency.
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 is a single short sentence, which is concise but severely under-specified. It provides minimal information and does not earn its place by conveying essential details, making it more an under-specification than effective conciseness.
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?
With four parameters, no output schema, and no annotations, the description is far too thin. It fails to explain what fields can be updated, how the login parameter works, or what the response looks like, making it inadequate for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the four parameters (name, login, new_login, description). It does not clarify the role of login as the identifier or how new_login and description are used, leaving the agent without critical semantic guidance.
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 action (update) and the resource (Yuque group), and it distinguishes from siblings like create_group and delete_group by using 'update'. However, it does not specify what aspects of the group can be updated, so it's not as specific as it could be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_group or delete_group. The description gives no context about prerequisites, typical use cases, or conditions that would make this tool the right choice.
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, the description carries the full burden of behavior disclosure. It merely states 'Update an existing Yuque repository,' which is nearly tautological and reveals nothing about permissions, idempotency, partial vs. full update semantics, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise and front-loaded—every word earns its place. It lacks depth, but the brevity itself is appropriate and not padded with fluff.
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?
For a tool with five parameters, no annotations, no output schema, and no parameter descriptions, the description is severely under-specified. It provides no context on required fields, update behavior, or response expectations, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names none of the five parameters (name, slug, public, namespace, description). It adds no meaning beyond the bare field names, forcing the agent to rely entirely on the schema without additional guidance.
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 'update' and resource 'Yuque repository', clearly distinguishing it from sibling update tools like yuque_update_doc and yuque_update_group. However, it lacks details about what fields or aspects can be updated, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no mentions of prerequisites, exclusions, or decision criteria, leaving the agent without context for selecting this tool over other Yuque repo or doc tools.
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. It only states a generic 'update' operation, without disclosing that the tool actually supports multiple actions (append, prepend, insert, move, remove, edit) that go beyond simple updates. Mutation traits and potential side effects are not addressed.
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 is concise in length (one sentence) but is under-specified, which undermines its usefulness. It does not include any additional structured information or elaboration that would help an agent invoke the tool correctly, making it unhelpfully terse rather than effectively concise.
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?
Given the tool's complexity (13 parameters, 3 enums, multiple action types), the description is completely inadequate. It lacks any explanation of required parameters, action modes, or expected behavior, and there is no output schema to clarify return values. The description does not nearly provide enough context for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the 13 parameters. Since schema description coverage is 0%, the description fails to compensate by explaining what any of the parameters (e.g., action, node_type, target_uuid) mean or how they relate to the tool's behavior.
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 'Update Yuque repository TOC nodes' uses a specific verb and resource, clearly indicating it modifies the table of contents of a Yuque repository. It distinguishes from sibling tools like yuque_get_repo_toc (which retrieves) and yuque_create_document_with_toc (which creates), so the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusions, leaving the agent without context for selecting this tool over others like yuque_update_repo or yuque_get_repo_toc.
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, the description carries the full burden but only restates the action without disclosing side effects, permission requirements, error handling, or response format. The mutation nature is implied but not elaborated, leaving significant behavioral ambiguity.
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 description is brief and word-efficient, but it essentially restates the tool name without adding new information. It is under-specified rather than elegantly concise, so it doesn't fully earn its place.
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?
This is a mutation tool with three parameters, no annotations, and no output schema. The description does not explain what the created group entity entails, whether login is a unique identifier, or what the response will look like, making it insufficient for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of the parameters (name, login, description). The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the bare schema, failing to compensate for the lack of 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?
The description clearly states the action (create) and the resource (a new Yuque group), which is unambiguous. It doesn't explicitly distinguish from sibling group tools like update or delete, but the verb 'create' inherently differentiates it, earning a score just below the top.
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 such as yuque_list_groups, yuque_update_group, or yuque_delete_group. There are no prerequisites, scenarios, 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?
With no annotations, the description carries full burden for behavioral disclosure. It implies a mutation (add/update) but does not mention permissions, idempotency, side effects, or behavior on existing memberships. No information about response or errors is given.
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 concise sentence with no filler or redundant information. It is front-loaded with the verb and resource. However, its brevity comes at the cost of omitting necessary detail, which is penalized in other dimensions.
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 no output schema, no annotations, and zero parameter documentation, the description is incomplete. It does not explain role semantics, identifier formats, or behavioral nuances. The tool is simple, but the context is too sparse for an agent to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. The 'role' parameter is constrained to 0 or 1, but no labels or meanings are provided. 'group' and 'user' are not clarified (e.g., identifier type). The description adds no value beyond parameter names.
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 action ('Add or update') and the resource ('a user membership in a Yuque group'), which distinguishes it from the sibling tool 'yuque_remove_group_user'. However, it does not explicitly mention the 'role' parameter or the fact that it can serve both creation and update, slightly blurring the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'yuque_remove_group_user' or 'yuque_list_group_users'. The description implies the operation but does not state preconditions, common scenarios, or exclusions.
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, the description carries the full burden of behavioral disclosure. It only says 'Create a new Yuque doc' — this implies it creates rather than updates, but does not mention permissions, duplicate slug behavior, response format, or whether the 'public' field controls visibility. This minimal disclosure is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than appropriately sized. It does not waste words, but it also does not provide enough information to be considered well-structured for the agent's needs.
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 six parameters, no annotations, and no output schema, the description is far too incomplete. It provides no information about return values, side effects, or distinctions from similar create tools, leaving the agent to infer critical usage details from the schema and sibling tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters. It adds no meaning beyond the input schema, whose property names are self-explanatory but still lack context such as the meaning of 'namespace' or the 'public' enum.
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 and resource ('Create a new Yuque doc') and is clearly understood. However, it does not distinguish this from sibling tools like yuque_create_document_with_toc or yuque_create_doc_from_file, which also create Yuque docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like yuque_create_document_with_toc and yuque_create_doc_from_file, the description should indicate which scenario this base create tool is for, but it does not.
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 present, and the description provides no behavioral details beyond the verb 'get'. It does not mention read-only status, error handling, pagination, or return format, placing the full burden on the description, which it fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is efficient. However, it verges on under-specification, a tautological restatement of the tool name with only 'entries' added as detail.
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 no annotations, no output schema, and 0% parameter description coverage, the description is severely lacking. It does not explain what TOC entries are, how the namespace should be formatted, or what response to expect, making it insufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'namespace' has no description in the schema (0% coverage) and is not explained in the tool description. While the name suggests the repo namespace, the description adds no additional semantics, leaving the agent to infer format or required meaning.
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 action (Get) and resource (repo TOC entries), making the tool's purpose understandable. However, it does not differentiate from sibling tools like yuque_list_docs or yuque_get_repo, lacking any specificity about the structure or use case.
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?
There is no guidance on when to choose this tool over alternatives such as yuque_list_docs or yuque_update_toc. The description only restates the function, leaving the agent without context for selection.
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, the description carries the full burden of disclosing side effects, permissions, and update semantics. It only reveals that the tool updates an existing doc and accepts slug/doc_id as identifiers, but does not explain whether updates are partial or full, what happens if both identifiers are provided, or what the response looks like.
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 fluff, making it efficient. However, it is somewhat under-specified for an 8-parameter tool, but that sacrifice is acceptable for conciseness.
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?
The description is severely incomplete given the tool's complexity. There is no output schema, no annotations, and the description only covers the basic action, leaving update semantics, field interactions, and return behavior entirely unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to the parameters by indicating that slug or doc_id are identifier alternatives. However, it doesn't clarify the roles of body, title, format, public, new_slug, or namespace, leaving 8 parameters with 0% schema coverage largely unexplained.
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 action ('Update'), the resource ('Yuque doc'), and the identifier method ('by slug or doc_id'). This distinguishes it from sibling tools like create_doc, delete_doc, and get_doc, though it doesn't explicitly mention the updatable fields (title, body, etc.), which are left to the schema.
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?
There is no guidance on when to use this tool versus alternatives like update_doc_from_file, nor any mention of prerequisites or exclusions. The description is purely a functional statement without contextual cue.
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 of behavioral disclosure. It only states the operation ('Get a group') without mentioning return format, error handling (e.g., not found), authentication requirements, or rate limits. As a read operation, the absence of annotations makes the description insufficiently transparent.
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, concise sentence that is easy to read and front-loaded with the action. However, the phrase 'or id' is an unnecessary addition that creates ambiguity, given the schema only has 'login'. Despite this, it is appropriately sized for a simple lookup tool, with no fluff.
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 simplicity and lack of output schema, the description is still incomplete: it does not explain what the return value contains, what happens if the group is not found, or how this tool differs from the many sibling group-related tools (e.g., yuque_list_groups). The minimal description leaves significant gaps for an agent to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies 'login' as the lookup key and also mentions 'id', but the schema only supports 'login'. This adds minimal semantic value and introduces a discrepancy that could mislead the agent about the accepted parameters. No format or validation details are provided beyond the schema's minLength constraint.
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 ('Get') and resource ('group') and indicates the lookup method ('by login or id'). It clearly distinguishes from sibling tools like yuque_list_groups (which lists all groups). However, the mention of 'id' is not reflected in the input schema, which only includes 'login', creating slight ambiguity about how the tool actually identifies a group.
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 offers no guidance on when to use this tool versus alternatives. It does not mention that it retrieves a single group by login, in contrast to list_groups for listing all, nor does it state any prerequisites or exclusions. This is a simple tool, but the lack of context leaves the agent to infer usage from the description 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 the full burden of behavioral disclosure. It only states 'Get a repo by namespace,' which adds no insight beyond the tool name. It does not disclose error behavior, return payload characteristics, or any side effects.
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. It is appropriately concise for the simplicity of the tool, though it lacks explanatory detail that would make it more useful.
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?
The tool has two parameters, no annotations, and no output schema, yet the description provides only minimal information. It does not explain what a repo is, what the response contains, or how the 'type' parameter affects results. This is insufficient given the rich set of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'namespace' as the lookup key, giving some semantic context for that parameter. However, the 'type' parameter is not mentioned, and with 0% schema description coverage, the description fails to compensate for the missing parameter 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?
The description clearly identifies the action ('Get') and resource ('repo') and specifies the lookup mechanism ('by namespace'). However, it does not explicitly distinguish from sibling tools like yuque_get_repository_overview or yuque_get_repo_toc, so it is clear but lacks differentiation.
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 such as yuque_list_repos or yuque_get_repository_overview. It mentions no use cases, prerequisites, or when-not-to-use scenarios.
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. It only says 'Update,' implying mutation, but omits important details like whether content is fully replaced, what happens to metadata, permissions required, or side effects. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core action. However, it is arguably too short for the tool's complexity, but that is a completeness issue rather than a conciseness issue.
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?
The tool has 8 parameters, no annotations, and no output schema. The description provides only a minimal statement of function, lacking context on how to identify the target document (e.g., slug vs doc_id), acceptable file formats, return behavior, or error scenarios. This is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal parameter meaning. It hints at file_path via 'local file content' but provides no explanation for the other 7 parameters (namespace, slug, doc_id, title, format, public, new_slug). The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update document body from local file content.' It specifies the action (update) and resource (document body), and the mention of 'from local file content' distinguishes it from sibling tools like yuque_update_doc. However, it doesn't explicitly differentiate from alternatives or name sibling 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 usage guidance is provided. The description simply states what the tool does without indicating when to choose it over alternatives such as yuque_update_doc or yuque_create_doc_from_file. There is no mention of prerequisites, exclusions, or context.
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, the description must carry the full burden of behavioral disclosure. It mentions 'attach to TOC' but omits crucial behaviors such as how file_path is read (local filesystem access), whether an existing slug is overwritten, what happens on missing files, or permission requirements.
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 sentence that is concise and front-loaded with the primary action. No words are wasted, and the structure is clear and scannable.
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?
Given the complexity (7 parameters, no annotations, no output schema), the description is grossly insufficient. It fails to explain what 'attach to TOC' means, how to specify the parent TOC node, what the format enum values imply, or how public/private settings work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for any of the 7 parameters. It does not explain namespace, slug, title, format, public, parent_uuid, or even file_path semantics beyond the vague 'local file content'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create), the resource (document), the source (local file content), and the additional action (attach to TOC). This distinguishes it from sibling tools like yuque_create_doc (which creates from provided content) and yuque_update_doc_from_file (which updates).
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 does not explicitly state when to use this tool versus alternatives. It only implies usage for local file content, but offers no exclusions or comparisons to yuque_create_doc or yuque_update_doc_from_file.
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. It only states the basic action, omitting details about pagination (offset), filtering (type), the effect of include_membered, or authentication/rate limits. While this is a read-only operation, the lack of behavioral context is a significant gap.
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, front-loaded sentence that efficiently communicates the core purpose. There is no verbose filler or unnecessary information, making it a model of conciseness even though it under-specifies other dimensions.
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?
Given the tool has 5 parameters, no output schema, and no annotations, a one-sentence description is grossly incomplete. It does not explain the meaning of parameters, the types of repos, or the return format. The complexity of the tool is not matched by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 5 parameters, and the description does not compensate by explaining any of them. Parameter names like 'user' and 'group' are somewhat self-explanatory, but 'include_membered' and the enum for 'type' are ambiguous. The description adds no value beyond the bare bones of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List repos under a user or group.' It uses a specific verb ('List') and resource ('repos'), and the scope ('under a user or group') distinguishes it from sibling tools like yuque_get_my_repositories and yuque_get_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of specific use cases, exclusions, or comparisons to similar list tools (e.g., yuque_get_my_repositories, yuque_list_docs). The description implies a general listing function but offers no decision-making context.
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, the description carries the full burden but only states the basic action. It does not disclose atomicity, side effects, required TOC existence, failure modes, or any mutation risks. The description is too minimal to provide meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, efficiently conveying the core purpose without wasted words. It is appropriately front-loaded, though it could have included more details without sacrificing conciseness.
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?
Given 7 parameters, no annotations, and no output schema, the description is vastly incomplete. It neither explains the TOC attachment semantics nor provides context for parameter values or operational expectations, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the 7 parameters. It does not add meaning to properties like public, parent_uuid, namespace, or format, leaving the agent without sufficient guidance to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a document and attaches it to TOC in one call, using specific verbs and resources. It clearly distinguishes from sibling tools like yuque_create_doc and yuque_update_toc by clarifying the combined action.
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 for combined create-and-attach operations but does not explicitly state when to prefer this over separate calls, nor does it mention alternatives or exclusions. The context is inferred rather than clearly communicated.
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, the description must carry the full burden of behavioral disclosure. The only additional trait it mentions is 'requires confirmation,' which is already reflected in the schema's confirm and confirm_text parameters. It does not disclose that the deletion is permanent, what happens to associated resources, or any permission requirements.
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, front-loaded sentence with no redundant words. It directly states the action and a critical safety note, achieving maximum conciseness without sacrificing clarity.
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 tool with three required parameters and no annotations or output schema, the description is incomplete. It lacks details on the confirmation flow (what confirm_text should be), the return value, and side effects, making it unsafe for an agent to invoke without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not explain what 'login' refers to (group identifier?), what 'confirm_text' should contain, or how 'confirm' relates to the confirmation process. The hint 'requires confirmation' adds minimal semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Delete' and the specific resource 'Yuque group', making the tool's action unmistakable. It is distinct from sibling tools that delete repos or docs, so there is no ambiguity about the target resource.
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 explicit guidance on when to use this tool versus alternatives like yuque_delete_repo or yuque_delete_doc. It lacks any context about prerequisites or conditions (e.g., ownership, group membership), leaving the usage to be inferred solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states the action without revealing read-only status, pagination, authentication needs, or other behavior. 'List' implies a read operation, but no explicit transparency is given.
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, concise sentence with no wasted words. It effectively communicates the core purpose in a well-structured manner.
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?
The tool is simple, but the description lacks crucial context about the 'login' parameter and any behavioral details. With no annotations or output schema, the description is insufficient for an agent to invoke the tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'login' with no description, and schema coverage is 0%. The description mentions 'a Yuque group' but does not explicitly state that 'login' refers to the group's login identifier, leaving the parameter's meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'users in a Yuque group,' clearly differentiating it from sibling tools like add/remove group users or list groups. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or reference to sibling tools, leaving the agent without context for selection.
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?
With no annotations provided, the description carries the full burden of disclosure. It does disclose the destructive nature ('Delete') and the requirement for confirmation, which are important behavioral traits. However, it omits details about what gets destroyed (e.g., associated docs), authentication prerequisites, or whether the action is reversible.
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 sentence with no wasted words and is easy to scan. It could be slightly more informative without becoming verbose, but it is appropriately concise for a simple delete operation.
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?
This is a destructive tool with no annotations, no output schema, and three required parameters. The description only mentions confirmation, leaving the agent to infer the exact confirmation mechanism and side effects. A more complete description would specify that `confirm_text` likely needs to match the repository name or some identifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for explaining the three parameters. It only hints that confirmation is involved via 'requires confirmation', but does not explain what `confirm_text` should contain, how `namespace` is formatted, or the relationship between `confirm` and `confirm_text`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('Yuque repository'), using a specific verb+resource structure. It distinguishes itself from sibling tools like yuque_delete_doc and yuque_delete_group by naming 'repository'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor exclusions or contexts where deletion is appropriate. The description only states that confirmation is required, offering no decision-making support.
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?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating 'client-side search' and the fields matched, but it does not explain return format, pagination, or whether remote calls are made. The read-only nature is somewhat implied, but more detail would help.
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?
A single front-loaded sentence with no filler. Every phrase adds meaning, and the structure is appropriately sized for a search 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?
The description omits critical context: what `namespace` refers to, what 'listed docs' means, and what the tool returns (full docs or metadata). With no annotations and no output schema, this leaves the agent uncertain about invocation and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that `query` matches title, slug, and description, but it leaves the required `namespace` parameter completely unexplained and does not elaborate on `limit` beyond schema defaults. This is a significant gap for correct invocation.
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 'search' and resource 'docs', and specifies the fields searched (title, slug, description). The qualifier 'client-side' provides some differentiation from the sibling `yuque_search_and_read`, but it does not explicitly name that alternative.
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 'over listed docs' implies a use case where docs are already fetched, giving some context. However, there is no explicit statement about when to use this tool versus alternatives like `yuque_search_and_read`, and no exclusions are 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 are provided, so the description must carry the full burden of behavioral disclosure. It only states the mutation action ('Create') without elaborating on side effects, prerequisites, error conditions, or expected response. The minimal wording adds little beyond the tool's name.
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, concise sentence that avoids redundancy. It is front-loaded and contains no wasted words, making it easy to parse quickly while conveying the core purpose.
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 7 parameters, no output schema, and no annotations, the description is too sparse to provide complete context. It fails to mention required parameters (name, slug), the meaning of 'type' or 'public', or what the tool returns upon success. The description covers only the ownership dimension, leaving significant gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate. It does clarify the 'user' and 'group' parameters via 'under user or group', which is useful, but it provides no insight into the meaning, format, or purpose of name, slug, type, public, or description. This leaves agents with insufficient semantic context for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' with the resource 'Yuque repository' and specifies the container as 'under user or group'. It distinguishes this tool from siblings like yuque_update_repo, yuque_delete_repo, and yuque_list_repos by focusing on creation.
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 by declaring the creation action, but it does not explicitly state when to use this tool versus alternatives (e.g., yuque_create_doc). The phrase 'under user or group' hints at a choice between user and group ownership, which is a light usage guideline, but no exclusions or comparisons 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic action without explaining authentication needs, pagination behavior, or effects of parameters like 'include_membered'.
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, front-loaded sentence that communicates the core functionality with no extraneous content. It is appropriately sized for the simplicity of the 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?
With three parameters and no output schema, the description is incomplete as it does not explain parameter semantics or behavioral details. The tool's convenience is clear, but the lack of guidance on filtering and pagination limits practical usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not elaborate on any of the three parameters. While the enum values and names are somewhat self-explanatory, 'offset' and 'include_membered' remain ambiguous without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' and clearly identifies the resources 'current user and repositories', distinguishing it from sibling tools like yuque_list_repos and yuque_get_current_user. The phrase 'in one call' highlights its combined nature, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving both user and repositories simultaneously, but it does not explicitly state when to use this tool over alternatives or mention exclusions. The context is clear but there are no direct guidelines for alternate scenarios.
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. It only restates the basic action and does not mention idempotency, error handling for nonexistent users, permission requirements, or whether the removal is destructive. For a mutation tool, this is insufficient.
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 concise sentence with no redundant information. Every word contributes to understanding the tool's purpose.
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 2-parameter mutation tool with no annotations and no output schema, the description provides the core action but misses important context like identifier formats and behavioral side effects. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the tool description does not explain what 'group' and 'user' refer to (e.g., ID, login, name). The parameter names are somewhat suggestive but leave ambiguity about expected value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove') and a clear resource ('a user from a Yuque group'). This distinguishes it from the sibling tool yuque_add_group_user and clearly conveys the operation's scope.
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 the tool is for removing a user from a group, but it does not explicitly mention when to prefer this over alternatives or any exclusions (e.g., not for removing group admins). The context is clear but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'requires confirmation', which is a safety-relevant behavioral trait not obvious from the schema alone. However, with no annotations provided and this being a destructive operation, it does not disclose whether deletion is permanent, irreversible, or has side effects, leaving a significant transparency gap.
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, concise sentence that front-loads the action and identifies key parameters. Every word contributes value, with no filler or redundancy.
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 tool with no annotations, no output schema, and a 0% parameter description coverage, this minimal description is insufficient. It does not explain the confirmation flow, the role of confirm_text, or what happens after deletion. Compared to similarly scoped tools, it leaves too much unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'namespace' and 'slug/doc_id' as identifiers, and 'requires confirmation' hints at the confirm parameters, but it does not clarify the meaning of 'confirm_text' or explain which of slug/doc_id is required. The description adds partial semantics but fails to cover all five parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and clearly identifies the resource ('Yuque doc') plus the key identifiers ('by namespace and slug/doc_id'). This distinguishes it from sibling delete tools like yuque_delete_repo and yuque_delete_group, making the purpose unmistakable.
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 clearly implies usage when the agent needs to delete a Yuque doc, but provides no explicit guidance on when not to use it or mention of alternatives (e.g., using update for reversible changes). The context is sufficient to know it is the right tool for deletion, but it lacks exclusions 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 of behavioral disclosure. It only mentions pagination, but does not state what the returned list contains (e.g., metadata vs. full content), whether docs are flat or hierarchical, or any error/authorization behavior. The schema already exposes limit/offset, so the description adds minimal 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?
The description is a single, front-loaded sentence that instantly communicates the core function and a key feature (pagination). Every word adds value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the agent is left without details on the response format, what fields are returned, or how the namespace should be constructed. The description is too terse to be fully self-sufficient for an agent deciding whether and how to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It identifies 'namespace' as a repo namespace and 'pagination' as limit/offset, but does not explain the required format of the namespace or how limit/offset interact (e.g., default, maximum, or offset meaning). This leaves the agent with only the parameter names and schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List docs'), the resource ('docs'), and the scope ('under a repo namespace'), which distinguishes it from sibling tools like yuque_get_doc (single doc) or yuque_search_docs (search). The mention of pagination adds a specific distinguishing feature.
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?
The description implies a clear context for when to use this tool: when you need to list docs within a particular repo/namespace. However, it does not explicitly mention alternatives or when *not* to use it, such as for searching or retrieving a single 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the basic action of getting a doc, without mentioning that the 'raw' parameter controls output format, potential response structure, or any edge cases. This is minimal beyond the function name.
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 short sentence that is immediately understandable. Every word contributes, and the structure is front-loaded with the verb and resource, then the identification method.
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 and no annotations, the description should explain what the tool returns and any parameter nuances. It only covers how to identify the doc, leaving the return format, raw behavior, and error conditions unexplained. This is simply too sparse for the tool's complexity.
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 0%, so the description needs to compensate. It explains that namespace is required and that either slug or doc_id is used as the identifier, which adds meaning beyond the schema. However, it does not explain the 'raw' parameter, which is a significant gap for a parameter with a default and behavioral impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('single doc'), and clearly distinguishes from sibling tools like list or search by specifying the identifier scheme (namespace + slug or doc_id). This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for retrieving exactly one doc when you know its namespace and either slug or doc_id. This implies a use case distinct from list/search tools, but it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches and optionally reads the first hit, which implies a read-only operation, but it does not disclose what the return value looks like (e.g., whether read_first=true returns the full document content or just a summary), how results are ordered, or behavior when no hits are found. It adds some context but lacks richer behavioral detail.
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 sentence of 12 words, front-loading the core action ('Search docs') and adding the optional behavior ('read the first hit in one call'). Every word earns its place; there is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the basic purpose but is incomplete. There is no output schema and no annotations, so the description should clarify the return format (e.g., whether it returns a list of hits or the full document when read_first is true). It also does not mention pagination, sorting, or error behavior. While the tool is not highly complex, the lack of these details makes the description only minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the missing parameter docs. The description mentions 'search docs' and 'read the first hit,' which loosely maps to 'query' and 'read_first,' but it does not explain 'namespace' or 'limit.' The parameter names are partially self-explanatory, but the description adds minimal value beyond the schema, leaving meaning of 'namespace' ambiguous and not clarifying the role of 'limit' in the combined operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Search docs' and clearly states the optional action 'read the first hit in one call.' This distinguishes it from sibling tools like yuque_search_docs (search only) and yuque_get_doc (read a specific doc), making the combined functionality immediately clear.
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 the tool combines searching and reading, but it does not explicitly state when to use this tool versus alternatives, nor does it mention conditions like 'use this when you need both search and read in one call' or 'if you only need search results, use yuque_search_docs.' It provides context but no exclusions 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 full responsibility for behavioral disclosure. It only states 'Get current Yuque user profile,' which implies a read operation, but it does not disclose authentication requirements, potential errors, rate limits, or any side effects. For a tool with zero annotation coverage, this is minimal 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?
The description is one concise sentence that directly conveys the tool's purpose with no redundant or extraneous text. It is appropriately sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's very low complexity (no params, no output schema, simple read operation), the description is adequate. It communicates the essential purpose, though it could mention what fields the profile includes. However, the simplicity of the tool makes the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% schema description coverage). Per the rubric, a no-parameter tool receives a baseline of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('current Yuque user profile'). It unambiguously identifies the tool's function and distinguishes it from all sibling tools, which focus on repos, docs, groups, etc.
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 usage context is implied: the agent can infer this tool is for retrieving the authenticated user's profile. However, no explicit when-to-use guidance or alternatives are mentioned. Since there is no direct sibling for this operation, the ambiguity is low, but the description still lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It makes the read-only nature and combined output clear, but does not disclose return format, potential errors, or any authentication requirements. The 'one call' efficiency hint adds some behavioral context beyond the tool name.
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 sentence of eight words, front-loaded with the action and outcome. Every word earns its place, and there is no repetition of the tool name.
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 one-parameter, no-output-schema endpoint, the description is minimally adequate: it states the tool gets repository details and TOC. However, 'details' is vague, and the lack of output schema and parameter guidance leaves room for ambiguity about the exact return payload and namespace format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the 'namespace' parameter or how to construct it. The tool name hints at repository context, but the description adds no meaning beyond the raw schema field name. Since the schema is minimal, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Get' and resource 'repository details and TOC in one call'. This clearly distinguishes it from siblings like yuque_get_repo and yuque_get_repo_toc, which fetch the same data separately.
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?
'In one call' implies this tool is the combined alternative to calling yuque_get_repo and yuque_get_repo_toc separately. It gives clear context for when to use it, though it doesn't explicitly name the alternatives or state when not to use 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?
No annotations are provided, and the description only states the purpose without disclosing details such as return format, pagination, authentication requirements, or error behavior. It implies a read-only list operation but does not add behavioral context beyond the basic action.
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 concise sentence that is front-loaded and contains no unnecessary words, earning its place fully.
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?
The description covers the core purpose and parameter but is minimal for a tool with no annotations or output schema. It could mention that the result is a list of groups and that providing a login may require appropriate permissions, so there are clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one undocumented parameter 'login', and the description clarifies its meaning by stating 'or a provided login', indicating that the login parameter specifies which user's groups to list. It also implicitly conveys that omitting login uses the current user, matching the optional requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'groups', and clarifies scope ('current user or a provided login'), distinguishing it from sibling tools like yuque_get_group (single group) and yuque_list_group_users (users in a group).
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?
The description clearly indicates this tool is for listing groups, either for the authenticated user or a specified login. It provides clear context but does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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