YAPI MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear distinctions for core operations like add, get, list, and save, but there is significant overlap between yapi_interface_add and yapi_interface_save (which handles both add and update), and between yapi_interface_list and yapi_interface_list_menu (both list interfaces with slight variations). This overlap could cause confusion for agents when selecting the appropriate tool.
Naming Consistency4/5
Most tools follow a consistent yapi_verb_noun pattern (e.g., yapi_interface_add, yapi_interface_get), with clear prefixes and snake_case throughout. However, there are minor deviations like yapi_interface_up instead of yapi_interface_update, and yapi_run_auto_test uses 'run' while others use verbs like 'add' or 'get', slightly breaking the pattern.
Tool Count5/5
With 11 tools, this server is well-scoped for managing YAPI interfaces and projects. The count aligns with the domain's needs, covering operations for projects, interfaces, categories, and testing without being overwhelming or too sparse.
Completeness4/5
The toolset provides strong coverage for YAPI management, including CRUD operations for interfaces and categories, project listing, and automated testing. A minor gap is the lack of explicit tools for deleting interfaces or categories, which might require workarounds, but core workflows are well-supported.
Average 2.7/5 across 11 of 11 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '新增接口' implies a creation/mutation operation, but it doesn't describe any behavioral traits such as permissions required, whether it's idempotent, what happens on success/failure, rate limits, or what the output looks like. For a tool with 16 parameters that likely modifies a system, this lack of transparency is critical.
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 phrase '新增接口', which is overly concise to the point of under-specification. While it's brief, it fails to provide necessary context and doesn't front-load critical information. In this case, conciseness is detrimental as it omits essential details that would help an AI agent understand and use the tool effectively.
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 (16 parameters, mutation operation), lack of annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the name, when to use it, behavioral aspects, or what to expect in return. For a tool that likely creates API interfaces in a system like YAPI, this minimal description fails to provide the necessary context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed descriptions for all 16 parameters in the input schema. The description '新增接口' adds no additional meaning about parameters beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '新增接口' (Add interface) is a tautology that restates the tool name 'yapi_interface_add' without providing meaningful context. It doesn't specify what kind of interface is being added (e.g., API interface in YAPI), what system it operates in, or how it differs from sibling tools like 'yapi_interface_save' or 'yapi_interface_up'. The purpose is minimally stated but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for managing interfaces (e.g., 'yapi_interface_get', 'yapi_interface_list', 'yapi_interface_save'), but the description doesn't indicate that this is for creating new interfaces versus updating existing ones or when to choose this over other options. No context or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose any behavioral traits. It doesn't indicate if this is a mutation operation, what permissions are required, whether changes are destructive, or any error handling, leaving the agent with no behavioral context beyond the vague 'update' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only two characters, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient and poorly structured for tool selection.
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 complex mutation tool with 17 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'update' entails, success/failure conditions, or how it differs from similar tools, leaving critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 17 parameters. The description adds no additional meaning beyond what's in the schema, such as explaining parameter relationships or usage examples. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新接口' (Update interface) is a tautology that merely restates the tool name 'yapi_interface_up' without adding specificity. It doesn't clarify what 'interface' refers to (e.g., API endpoint in YAPI) or distinguish it from sibling tools like 'yapi_interface_save' or 'yapi_interface_add', leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or differentiate from siblings like 'yapi_interface_save' or 'yapi_interface_add', making it impossible to determine appropriate usage 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, the description carries full burden but lacks behavioral details. It doesn't disclose if this is a mutating operation (likely yes), permission requirements, rate limits, or side effects (e.g., overwriting existing data). The merge parameter hints at conflict behavior, but the description doesn't elaborate.
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 in Chinese, front-loading the core action. However, it could be more structured by briefly mentioning key parameters or use cases without adding bulk.
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 5-parameter mutating tool with no annotations or output schema, the description is incomplete. It doesn't cover behavioral traits (e.g., idempotency, errors), output expectations, or how it differs from sibling tools, leaving gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters well. The description adds no parameter semantics beyond the tool name implying 'import' relates to 'json' and 'type' parameters. Baseline 3 is appropriate as the schema handles most details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '导入接口数据到 YAPI' (Import interface data to YAPI) states the action and target but is vague about scope and specifics. It doesn't differentiate from siblings like yapi_interface_add (which likely adds single interfaces) or clarify what 'interface data' entails (e.g., bulk imports from external formats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like yapi_interface_add (for single interfaces) or yapi_interface_save/up (for updates). It mentions importing data but doesn't specify scenarios (e.g., initial setup, migration) or prerequisites (e.g., project existence).
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. '新增' (add) implies a write/mutation operation, but the description doesn't disclose critical traits: whether this requires authentication, what permissions are needed, if it's idempotent, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps for the agent.
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 phrase '新增接口分类' (Add interface category), which is extremely concise and front-loaded with the core action. There's zero waste or redundancy. However, it's arguably too brief for a mutation tool with no annotations, potentially under-specifying critical context, but within the conciseness dimension, it's efficient.
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 complexity (a mutation tool for adding categories in YAPI), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or system-specific behaviors (e.g., how categories relate to interfaces or projects). The schema covers parameters well, but for a write operation without annotations, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters documented in the input schema (e.g., 'url' for parsing project/interface IDs, 'project' for optional project ID, 'name' for required category name, 'desc' for optional description). The description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '新增接口分类' (Add interface category) states a clear verb ('新增' - add) and resource ('接口分类' - interface category), providing basic purpose. However, it's vague about what 'interface category' means in the YAPI context and doesn't distinguish from siblings like 'yapi_interface_get_cat_menu' or 'yapi_interface_list_menu' that might involve categories. The description is functional but lacks specificity about the system context.
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 doesn't mention prerequisites (e.g., needing a project ID), exclusions, or relationships with sibling tools like 'yapi_interface_add' (for adding interfaces) or 'yapi_interface_get_cat_menu' (for getting category menus). Usage is implied only through the name and parameters, with no explicit context or alternatives stated.
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 burden for behavioral disclosure. While '保存接口（新增或更新）' implies a write/mutation operation, it doesn't specify authentication requirements, whether the operation is idempotent, what happens on conflicts, error conditions, or response format. For a complex mutation tool with 17 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just four Chinese characters plus parentheses. It's front-loaded with the core action. While perhaps too brief for such a complex tool, every word earns its place by conveying the dual create/update capability efficiently.
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 complex mutation tool with 17 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like permissions, side effects, or response format. While the schema documents parameters well, the description fails to provide the contextual completeness needed for safe and effective use of this significant operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond the basic 'save interface' concept. It doesn't explain how parameters like 'url' interact with others, or clarify the conditional logic for 'id' (required for updates). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '保存接口（新增或更新）' translates to 'Save interface (add or update)', which provides a basic verb+resource combination. It indicates the tool can either create new interfaces or update existing ones. However, it doesn't distinguish this tool from sibling tools like 'yapi_interface_add' (which presumably only adds) or 'yapi_interface_up' (which presumably only updates), leaving the purpose somewhat vague.
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. With sibling tools like 'yapi_interface_add' and 'yapi_interface_up' available, there's no indication whether this tool should be preferred for certain scenarios, whether it handles both operations conditionally, or what prerequisites might exist. The agent receives no usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('run automated tests') but lacks critical details: it doesn't specify what happens during execution (e.g., test results, logs, errors), whether it's a read-only or mutating operation, authentication requirements, rate limits, or side effects. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence ('运行 YAPI 自动化测试') that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, but it could be slightly more informative (e.g., adding context about test types). Overall, it's concise and well-structured, with 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 complexity of running automated tests (a potentially mutating or resource-intensive operation), no annotations, no output schema, and three parameters, the description is incomplete. It doesn't explain what the tool returns (e.g., test results, status codes), behavioral traits, or usage context. For a tool with these characteristics, the description should provide more comprehensive information to aid the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (url, project, env_name). The description adds no additional parameter information beyond what the schema provides. According to the rules, when coverage is high (>80%), the baseline score is 3 even with no param info in the description, as the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '运行 YAPI 自动化测试' (Run YAPI automated tests) states the verb ('run') and resource ('YAPI automated tests'), providing a basic purpose. However, it's vague about what 'YAPI automated tests' specifically entail (e.g., unit tests, integration tests, API tests) and doesn't differentiate from siblings like 'yapi_interface_list' or 'yapi_import_data', which handle different operations. It avoids tautology but lacks specificity.
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. It doesn't mention prerequisites (e.g., needing a YAPI project setup), exclusions (e.g., not for manual testing), or comparisons to sibling tools (e.g., 'yapi_interface_list' for listing interfaces instead of running tests). Usage is implied only by the tool name, with no explicit context or alternatives stated.
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 burden for behavioral disclosure. It only states the action ('获取接口列表') without describing what the list contains (e.g., interface names, IDs, metadata), whether it's paginated (implied by page/limit params but not explicit), authentication requirements, rate limits, or error conditions. For a tool with 5 parameters and no annotation coverage, this is a significant gap in 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 extremely concise with a single phrase ('获取接口列表'), which is front-loaded and wastes no words. For a simple list operation, this brevity is appropriate, though it may sacrifice clarity. Every word earns its place by conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values (e.g., list format, fields), pagination behavior (implied by parameters but not stated), or how parameters interact (e.g., url overriding project). With no output schema and minimal description, an agent would struggle to use this effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters (url, project, catid, page, limit) with descriptions. The tool description adds no additional parameter semantics beyond what's in the schema. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取接口列表' (Get interface list) states the basic action and resource but is vague about scope and context. It doesn't specify what kind of interfaces (YAPI API interfaces), what project context, or how it differs from sibling tools like 'yapi_interface_get' (single interface) or 'yapi_interface_list_menu' (menu listing). The purpose is understandable but lacks specificity and sibling 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'yapi_interface_get' (for single interface details) or 'yapi_interface_list_menu' (for menu structure), nor does it specify prerequisites like authentication or project context. Usage is implied only by the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but fails to describe how it behaves—e.g., whether it's a read-only operation, what the output format looks like, if there are rate limits, or any error conditions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, making it easy to understand at a glance, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, and usage context, making it insufficient for an AI agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents both parameters ('url' and 'project') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or default behaviors, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and resource '所有接口分类' (all interface categories), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'yapi_interface_list_menu', which appears to serve a similar listing function, preventing a perfect score.
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 like 'yapi_interface_list_menu' or other sibling tools. It lacks any context about prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving usage ambiguous.
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. It states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or response format. For a tool with no annotation coverage, this is a significant gap in 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, efficient sentence in Chinese that directly states the purpose without redundancy. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, with 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 no annotations, no output schema, and a read operation with two optional parameters, the description is incomplete. It doesn't explain what the returned menu structure looks like, how to handle the optional parameters in practice, or any dependencies. For a tool in a set with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('url' and 'project') well-documented in the schema. The description adds no additional meaning beyond implying it fetches a menu, which the schema already covers through parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
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 (接口菜单/interface menu), specifying it includes categories and interface lists. It distinguishes from siblings like 'yapi_interface_get' (gets a single interface) and 'yapi_interface_list' (likely lists interfaces without categories). However, it doesn't explicitly contrast with 'yapi_interface_get_cat_menu', which might be similar, preventing a perfect score.
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. It doesn't mention prerequisites, context (e.g., for navigation or overview), or exclusions. With siblings like 'yapi_interface_get_cat_menu' that might overlap, this lack of differentiation leaves the agent guessing about appropriate use cases.
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. The description only states what the tool does ('列出所有已配置的 YAPI 项目') but doesn't disclose any behavioral traits such as whether this is a read-only operation, what permissions might be required, how results are formatted, if there's pagination, or any rate limits. For a tool with zero annotation coverage, this 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, clear sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, with every part of the sentence contributing essential information. There's zero waste or redundancy.
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 complexity (simple list operation with 0 parameters), the description is complete enough for its basic purpose. However, there's no output schema, and the description doesn't explain return values or behavioral aspects. With no annotations and no output schema, the description should ideally provide more context about what the output looks like or any constraints, but it's minimally adequate for a straightforward list tool.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics since there are no parameters. According to the rules, 0 parameters gives a baseline score of 4, as there's nothing to compensate for.
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 ('列出所有' - list all) and the resource ('已配置的 YAPI 项目' - configured YAPI projects). It uses a specific verb and identifies the target resource. However, it doesn't explicitly differentiate from sibling tools like 'yapi_interface_list' or 'yapi_interface_list_menu', which might also list things but different resources.
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. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'yapi_interface_list' (which likely lists interfaces rather than projects). There's no explicit when/when-not or alternative tool references.
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 carries the full burden. It discloses that the tool retrieves details and can parse URLs automatically, which is useful behavioral context. However, it lacks information on permissions needed, rate limits, error handling, or what the return format looks like (e.g., JSON structure). For a read operation with no annotations, this leaves gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('获取接口详情') and immediately follows with the key usage note about URL parsing. There is zero wasted text, and every word earns its place by clarifying functionality or usage.
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 moderate complexity (a read operation with 3 optional parameters), no annotations, and no output schema, the description is partially complete. It covers the what and how-to-use basics but lacks details on behavioral aspects like authentication, response format, or error cases. For a tool without annotations or output schema, more context would be needed to fully guide an agent, but it's minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (url, project, id) with their types and descriptions. The description adds marginal value by reinforcing the URL parsing capability and implying parameter relationships (e.g., id can be omitted if url is provided), but doesn't provide additional syntax, examples, or constraints beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取接口详情' (get interface details), which is a specific verb+resource combination. It distinguishes itself from siblings like yapi_interface_list (which lists interfaces) and yapi_interface_add (which creates interfaces). However, it doesn't explicitly contrast with yapi_interface_up (update) or yapi_interface_save (save), leaving some ambiguity about its exact scope versus update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: to retrieve interface details, with the option to pass a YAPI interface page URL for automatic parameter parsing. It implies usage by stating '可直接传入 YAPI 接口页面 URL 自动解析参数' (can directly pass YAPI interface page URL to automatically parse parameters). However, it doesn't explicitly state when NOT to use it (e.g., vs. yapi_interface_list for listing or yapi_interface_up for updates) or name alternatives, which prevents a perfect score.
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:

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

Score Badge

Copy to your README.md:

[![yapi-mcp MCP server](https://glama.ai/mcp/servers/zhhbinn/yapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhhbinn/yapi-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/zhhbinn/yapi-mcp'

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