The yapi-mcp server provides YApi API management capabilities, allowing you to browse, search, and manage API definitions stored in a YApi instance.
List Projects (yapi_list_projects): Retrieve the configured YApi project's ID, name, and description. No parameters required.
Get Categories (yapi_get_categories): Fetch all interface categories within a project, along with a summary of APIs grouped under each category.
Search APIs (yapi_search_apis): Search for APIs within a project by keyword (matched against title or path), with an optional filter by HTTP method (GET, POST, PUT, DELETE, PATCH).
Get API Details (yapi_get_api_details): Retrieve full details of a specific API by its ID, including request parameters, headers, request body type/structure, and response body.
Create or Update APIs (yapi_save_api): Create a new API or update an existing one. Providing an api_id triggers an update; omitting it creates a new API. Supports setting the path, title, description, method, category, query parameters, request headers, request body type/structure, and response body schema.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yapi-mcp list all my projects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 中文
A zero-dependency YApi MCP server that exposes YApi's API-management capabilities to Claude Code and any MCP client.
The npm package @yogeliu/yapi-mcp-server has two defects that make it completely unusable:
Broken inputSchema serialization — it returns the Zod schema object itself as inputSchema. After JSON.stringify it becomes {"_def":...}, an invalid structure. MCP clients reject it with tools fetch failed, so none of the tools ever load.
Wrong interface-list strategy — YApi's /api/interface/list ignores catid on most versions and returns only the first page by default. The original package's "iterate categories" approach causes massive duplication and misses most interfaces; it also reads the wrong id field (_id).
This project is rewritten from scratch with zero runtime dependencies (only Node ≥18 built-in fetch), hand-written valid JSON Schemas, and project-level pagination with dedup — fixing all of the above.
Related MCP server: YAPI MCP Server
Tool | Description |
| List the configured project (id / name / desc) |
| List project categories and the APIs under each |
| Search APIs by keyword (title / path), optional method filter |
| Full detail of one API (params / headers / body / response) |
| Create or update an API (with |
No install needed — use it directly in your MCP config:
{ "command": "npx", "args": ["-y", "@hizml/yapi-mcp"] }git clone https://github.com/hizml/yapi-mcp.gitPoint the config at the local file:
{ "command": "node", "args": ["/absolute/path/to/yapi-mcp/yapi-mcp.mjs"] }Two environment variables:
YAPI_BASE_URL — YApi host, e.g. http://yapi.example.com
YAPI_TOKEN — format projectId:tokenValue, from the YApi project "Settings → token"
~/.claude.json){
"mcpServers": {
"yapi": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@hizml/yapi-mcp"],
"env": {
"YAPI_BASE_URL": "http://your-yapi-host",
"YAPI_TOKEN": "227:your_token_here"
}
}
}
}Full example: examples/claude-code-config.json.
Zero dependencies — pure Node ESM, only Node ≥18 built-in fetch
Valid JSON Schema — every inputSchema is hand-written standard JSON Schema, so clients validate it fine
Full pagination — project-level pagination + dedup, no missing or duplicate APIs
Robust errors — param errors, timeouts, and YApi errcode all become isError messages; the process never crashes
Debuggable — set DEBUG=1 to emit logs to stderr
Currently single-token (single-project); for multiple projects, run multiple instances
YApi's /api/interface/list total field is unreliable, so this tool stops paginating when a page returns fewer than the page size
MIT
获取接口详细信息（请求参数、请求头、请求体类型与结构、响应体等）。
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | 接口 ID（可由 search_apis 或 get_categories 结果获得）。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists what data the tool returns (params, headers, body, response), which is useful behavioral context. However, with no annotations, it fails to disclose whether the operation is read-only, requires authentication, or has any side effects. A more explicit statement would improve clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively conveys the tool's purpose without unnecessary words. It is front-loaded with the key action and details, though it could benefit from slight restructuring (e.g., listing items) for even better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and no output schema, the description provides adequate context by listing the types of details returned. However, it uses '等' (etc.) implying incompleteness and does not specify the response format or any limitations, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description of the api_id parameter. The tool description does not add additional meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed API information including request parameters, headers, body structure, and response. It uses a specific verb ('获取...详细信息') and resource ('接口'), and distinguishes from sibling tools like search_apis (search) and get_categories (list categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter description for api_id explicitly mentions it can be obtained from search_apis or get_categories, providing a clear usage context. However, the main description does not include explicit when-to-use or when-not-to-use guidance, but the parameter hint suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定项目的接口分类列表（分类 ID、名称，以及每个分类下的接口概要）。
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | 项目 ID。省略时使用 token 中的 projectId。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the input schema: it states the project_id parameter can be omitted (using a default from token), but the schema marks it as required. This inconsistency undermines agent trust and reliability. No annotations are provided, so the description fails to disclose behavioral traits accurately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that efficiently conveys the purpose and contents. No unnecessary words; it is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is generally sufficient. However, the contradiction between description and input schema makes it incomplete and potentially confusing for the agent. Additionally, it does not explain the return format beyond a vague 'summary'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds misleading information about the parameter being optional when it is required per schema. This contradiction reduces the semantic value below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '接口分类列表' (interface category list) for a specified project, specifying what is returned (category ID, name, and interface summary). It distinguishes from sibling tools like yapi_get_api_details (gets API details) and yapi_list_projects (lists projects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving categories of a project, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It lacks guidance on 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.
列出当前 token 配置的 YApi 项目信息（项目 ID、名称、描述）。无参数。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions the token-based authentication and that no parameters are required, indicating a read-only list operation. However, it does not disclose potential pagination, rate limits, or error cases, which would make it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the action, scope, and field list. It is front-loaded with the key verb and resource, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient context: it lists the returned fields and the authentication context. It could be improved by mentioning the response format (e.g., array of objects), but it is largely complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, 100% schema coverage). The description explicitly confirms 'no parameters,' which aligns with the schema. For zero-parameter tools, the baseline is 4, and the description adds the confirmation value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists YApi project information for the current token, specifying the fields returned (ID, name, description). This action is distinct from sibling tools like yapi_get_api_details or yapi_save_api, which handle specific APIs or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a project list is needed but lacks explicit guidance on when to prefer this tool over alternatives. No exclusion criteria or recommended contexts are provided, relying on the user to infer from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建或更新 YApi 接口。带 api_id 走更新（/api/interface/up），不带走创建（/api/interface/add）。至少需提供 project_id 与 catid。
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | 接口描述。 | |
| path | No | 接口路径，例如 /api/foo/bar。 | |
| catid | Yes | 目标分类 ID。 | |
| title | No | 接口标题。 | |
| api_id | No | 要更新的接口 ID。提供时为更新；省略时为创建。 | |
| method | No | HTTP 方法。 | |
| res_body | No | 响应体结构，JSON Schema 字符串。 | |
| req_query | No | query 参数列表。 | |
| project_id | Yes | 目标项目 ID。 | |
| req_headers | No | 请求头列表。 | |
| req_body_type | No | 请求体类型。 | |
| req_body_other | No | 请求体结构，json 类型时为 JSON Schema 字符串。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses only the create/update behavior and required parameters, but lacks details on side effects, authentication, error handling, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise Chinese sentence that front-loads the main purpose and required parameters. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description lacks guidance on return values, error handling, and conditional parameter usage (e.g., path/method required for creation). It is insufficiently complete 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds key value by explaining the conditional create/update logic tied to api_id, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a YApi interface, with specific conditions based on api_id. It distinguishes itself from sibling tools like yapi_get_api_details or yapi_search_apis by being the only mutative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 create vs update based on api_id, and it identifies required parameters (project_id, catid). However, it does not explicitly exclude use cases or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在项目内按关键词搜索接口（匹配 title/path，可选按 method 过滤），返回接口列表。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词，按子串匹配接口 title 或 path（不区分大小写）。 | |
| method | No | 可选。按 HTTP 方法过滤。 | |
| project_id | No | 项目 ID。省略时使用 token 中的 projectId。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses case-insensitive substring matching on title/path and optional method filter. But lacks details like pagination, result limits, or response structure (no output schema). Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, minimal and efficient. Every word contributes to describing the tool's purpose and key options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description adequately explains input behavior. Lacks output details but the return of a 'list of APIs' is mentioned. Could be more complete with pagination info, but still serves its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context that search is 'within a project' (scope), but otherwise the parameter descriptions in schema already cover the search functionality. No significant additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches APIs by keyword within a project, matching title/path with optional method filter. Distinguishes from sibling tools (e.g., yapi_get_api_details for details, yapi_save_api for saving) by specifying its unique search function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context: when needing to find APIs by search criteria. However, does not explicitly state when not to use or mention alternatives, but the context is clear enough given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0yapi_get_api_detailsyapi_get_categoriesyapi_list_projectsyapi_save_apiyapi_search_apisEach tool targets a distinct operation: listing projects, retrieving categories, getting API details, saving APIs, and searching. There is no functional overlap; an agent can clearly distinguish them.
All tools follow a consistent 'yapi_verb_noun' pattern using snake_case, with clear and descriptive verbs (get, list, save, search). No mixing of conventions.
Five tools is well-scoped for a YApi integration, covering the core interactions: project listing, category browsing, API details, creation/updating, and searching. Not excessive or insufficient.
Core CRUD and search are present, but a delete API tool is missing, which could be a gap for lifecycle management. However, the main workflows (discover, read, create/update) are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
APIs.guru MCP — keyless directory of 2,500+ public APIs and their OpenAPI specs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hizml/yapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
