How do I use yapi-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yapi-mcp-server generate TypeScript types for interface 109220" 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.

yapi-mcp-server

by tiandashu

Overview Schema Related Servers Score Discussions

JavaScript

Local

YApi MCP Server

这是一个 Model Context Protocol (MCP) 服务器，用于与 YApi 接口管理平台集成，支持自动生成 TypeScript 类型定义、Mock 数据和 API 请求代码。

✨ 功能特性

🔧 核心功能

配置文件读取: 自动读取项目中的 yapi.config.json 配置文件
YApi 数据获取: 通过配置的 remoteUrl 获取 YApi 项目的完整接口信息（支持缓存）
TypeScript 类型生成: 根据接口响应 Schema 自动生成 TypeScript interface 定义
Mock 数据生成: 智能生成符合接口结构的 Mock 测试数据
API 请求代码生成: 自动生成 Axios 或 Fetch 风格的 API 请求函数
智能缓存机制: 自动缓存 YApi 数据 30 分钟，减少网络请求

Related MCP server: Swagger MCP Server

特别说明（强烈推荐！！！）

推荐使用最新的yapi-cli, 相比当前项目支持了以下功能：

支持 cli
支持 mcp
支持 skill
支持多 yapi 项目和多 yapi 空间，配置更方便
改用 yapiopenapi 接口获取，减少上下文占用，更省 token了

✨ 快速开始

1. cursor 中安装 yapi-mcp-server

{
	"mcpServers": {
		"yapi-mcp": {
			"command": "npx",
			"args": ["-y", "@vtian/yapi-mcp-server", "--stdio"]
		}
	}
}

2. 获取 yapi 参数

yapi设置

3. 项目中配置 yapi.config.json

在您的前端项目根目录下创建 yapi.config.json 文件：

{
	"remoteUrl": "https://your-yapi-domain.com/api/open/plugin/export-full?type=json&pid=1437&status=all&token=your-token",
	"type": "yapi",
	"dataKey": "data",
	"mockPath": "src/mocks",
	"typePath": "src/types",
	"apiPath": "src/api"
}

必填字段

remoteUrl: YApi 项目导出接口 URL
type: 平台类型，固定为 "yapi"

可选字段

dataKey: 响应数据字段名，默认 "data"
mockPath: Mock 文件输出路径，默认 "src/mocks"
typePath: 类型文件输出路径，默认 "src/types"
apiPath: API 代码输出路径，默认 "src/api"

✨ 可用工具

本项目提供以下 5 个 MCP 工具，可以通过支持 MCP 协议的客户端（如 Claude Desktop、cursor）调用：

1️⃣ read_config - 读取配置文件

从项目中查找并读取 yapi.config.json 配置文件。

2️⃣ get_yapi_data - 获取 YApi 数据

从 YApi 服务器获取接口数据，支持缓存机制（30 分钟）。

3️⃣ generate_types - 生成 TypeScript 类型

根据接口 JSON Schema 生成 TypeScript 类型定义。

4️⃣ generate_mock_from_yapi - 生成 Mock 数据

根据接口 Schema 智能生成符合结构的 Mock 数据。

5️⃣ generate_api_code - 生成 API 请求代码

生成 Axios 或 Fetch 风格的 API 请求函数代码。

✨ prompt 使用

🔧 yapi 中有哪些接口？

🔧 帮我更新一下 yapi 接口数据

🔧 帮我生成 109220 的 mock 数据

可以是 yapi 上接口对应的 id，也可以直接是接口名称

🔧 帮我根据接口 109220 更新对应的 ts 类型

可以是 yapi 上接口对应的 id，也可以直接是接口名称

🔧 帮我根据接口 109220 生成 axios 代码

效果同上

✨ 生成的文件示例

TypeScript 类型定义

/** 用户信息接口 */
export interface UserInfoData {
	/** 用户ID */
	userId: number
	/** 用户名 */
	username: string
	/** 邮箱 */
	email: string
}

API 请求代码 (Axios)

/**
 * 用户信息接口
 */
export const getUserInfo = async (): Promise<UserInfoData> => {
	const response = await axios.get('/api/user/info')
	return response.data
}

Mock 数据

{
	"code": "200",
	"success": true,
	"message": "操作成功",
	"data": {
		"userId": 12345,
		"username": "测试用户",
		"email": "test@example.com"
	}
}

📄 许可证

MIT License

🤝 支持与反馈

如有问题或建议，请通过 Issues 或内部渠道联系开发团队。

Available Tools

5 tools

generate_api_codeD

ParametersJSON Schema

Name	Required	Description
`path`	Yes	接口路径
`title`	No	接口标题
`method`	No	请求方法，默认GET
`reqQuery`	No	查询参数数组
`reqParams`	No	路径参数数组
`requestLib`	No	请求库类型: axios \| fetch，默认axios
`interfaceName`	No	接口类型名称

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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?

Tool has no description.

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

generate_mock_from_yapiD

ParametersJSON Schema

Name	Required	Description
`path`	No	接口路径
`title`	No	接口标题
`method`	No	请求方法
`dataKey`	No	数据字段名，默认为data
`mockType`	No	Mock类型: full-完整响应, data-only-仅数据部分
`resBodySchema`	Yes	接口响应的JSON Schema字符串

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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?

Tool has no description.

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

generate_typesD

ParametersJSON Schema

Name	Required	Description
`path`	No	接口路径
`title`	No	接口标题
`method`	No	请求方法
`dataKey`	No	数据字段名，默认为data
`interfaceName`	No	接口名称
`resBodySchema`	Yes	接口响应的JSON Schema字符串

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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?

Tool has no description.

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

get_yapi_dataD

ParametersJSON Schema

Name	Required	Description
`method`	No	请求方法
`listAll`	No	是否列出所有接口
`remoteUrl`	Yes	YApi导出接口URL
`forceRefresh`	No	是否强制刷新缓存，默认false
`interfacePath`	No	指定接口路径

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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?

Tool has no description.

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

read_configD

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	项目路径，如果不提供则使用当前工作目录

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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?

Tool has no description.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2/5.0

Disambiguation3/5

The tool names suggest distinct purposes, but without descriptions, boundaries are unclear—especially between generate_types and generate_api_code, which could be seen as overlapping. read_config and get_yapi_data also share a similar 'retrieve data' feel.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (read_, get_, generate_). The verb is always first and nouns are clear, making the naming uniform and predictable.

Tool Count5/5

Five tools is within the ideal 3-15 range. Each tool appears to serve a distinct purpose in the YAPI workflow, so the count feels well-scoped without being sparse or bloated.

Completeness4/5

The set covers the core YAPI integration workflow: configuration, data retrieval, and generation of types, mocks, and API code. Minor gaps might exist (e.g., no explicit tool for updating or validating data), but the main lifecycle is represented.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

simceptor
io.github.ayda212
AI-native mock API server with MCP. Create REST/SOAP mocks from Claude, Cursor, or Windsurf.
API Testing Testing & QA Tools
2
asset-auto-generator
io.github.TranThienTrong
An MCP server that provides asset auto generator
Developer Tools App Automation
2
api-mock-server A
io.github.lazymac2x
Cloudflare Workers MCP server: api-mock-server
API Testing Developer Tools
62
Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2

Related MCP Servers

OpenAPI Client Generator MCP
Developer Tools Code Execution
orhanveli
-
license
A
quality
Not graded
maintenance
A TypeScript-based MCP server that generates API clients from OpenAPI specifications, allowing automated code generation through natural language.
Updated a year ago (2025-03-12 10:42 UTC)
1
44
1
Swagger MCP Server
API Testing Developer Tools
tuskermanshu
A
license
B
quality
D
maintenance
A server based on Model Context Protocol that parses Swagger/OpenAPI documents and generates TypeScript types and API client code for different frameworks (Axios, Fetch, React Query).
Updated a year ago (2025-03-20 06:35 UTC)
12
16
16
ISC
apifable
API Testing Developer Tools Documentation Access
ycs77
A
license
A
quality
A
maintenance
MCP server that helps AI agents explore OpenAPI specs, search endpoints, and generate TypeScript types.
Updated 18 days ago (2026-08-16 12:37 UTC)
7
47
10
MIT
yapi-mcp-server
Developer Tools API Testing Documentation Access
kevinLiJ
A
license
Not graded
quality
D
maintenance
An MCP server that enables fetching YApi interface details via a tool, allowing AI assistants to generate API code based on YApi documentation.
Updated a year ago (2025-05-26 09:34 UTC)
71
ISC

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/tiandashu/yapi-mcp-server'

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