What can you do with this server?

This server provides a multi-purpose toolkit integrating MySQL database operations, Apifox API management, HTTP request execution, and FTP file operations. * Read-Only MySQL (execute_mysql_readonly): Execute read-only statements (SELECT, SHOW, DESCRIBE, etc.) using a DSN connection string — write operations are blocked. * Full MySQL Execution (execute_mysql_only): Execute any MySQL statement (INSERT, UPDATE, DELETE, DDL, etc.) using a DSN connection string, with automatic retry on failure. * Import OpenAPI to Apifox (import_openapi): Import OpenAPI specifications into Apifox from a JSON string, a single JSON file, or a directory of JSON files, using a project ID and API key. * Download APIs from Apifox (download_apis): Download all API definitions from an Apifox project (OpenAPI 3.1 format) to a specified local directory, requiring a project ID and API key. * Execute cURL Commands (run_curl): Parse and execute curl command strings, returning full HTTP response details (status code, headers, body). * FTP/FTPS/SFTP File Operations: Connect to remote servers and perform file management including listing, uploading, downloading, deleting, renaming, reading, writing, and managing directories and permissions. * Help (help): Get assistance on any topic or task.

Which integrations are available for this server?

Allows importing OpenAPI data to Apifox and downloading all APIs from an Apifox project. Allows parsing and executing curl commands, returning the HTTP response. Allows executing SQL statements on MySQL databases.

How do I use mcp-mysql-apifox?

1. Click on "Deploy 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., "@mcp-mysql-apifox Show me the first 10 users from the database." 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.

mcp-mysql-apifox

by 327100395

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

主要功能

不同项目连接不同
在 Mysql 数据库执行 SQL
添加接口文档到 Apifox
从 Apifox 下载所有API到本地文件
解析并执行 curl 命令
通过 FTP、FTPS 或 SFTP 操作项目关联的远程目录

FTP 实现参考并整合自 kemalabuteliyte/ftp-mcp，连接配置已改为本项目的 .env.mma 工作流。

Related MCP server: Apifox MCP

安装与使用

配置MCP服务

 {
   "mcpServers": {
     "mysql-apifox": {
       "command": "npx",
       "args": [
           "-y",
           "mcp-mysql-apifox"
       ]
     }
   }
 }

使用数据库、Apifox 或 FTP 前，必须在 projectRoot（项目根目录绝对路径）创建并填写 .env.mma。首次调用如果发现该文件不存在，会生成空模板并返回待填写项；填写完成后再重试。
```
# 数据库
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=user
DB_PASSWORD=password
DB_NAME=database

# Apifox
APIFOX_API_KEY=
APIFOX_PROJECT_ID=

# FTP / FTPS / SFTP
FTP_HOST=
FTP_PORT=
FTP_PROTOCOL=
FTP_USERNAME=
FTP_PASSWORD=
FTP_PRIVATE_KEY_PATH=
FTP_PASSPHRASE=
```
FTP_PROTOCOL 留空时默认为 ftp，FTP_PORT 留空时 FTP 使用端口 21；使用 ftps 或 sftp 时请分别填写对应协议和端口。
.env.mma 已加入 .gitignore，不要提交其中的凭据。

建议在项目规则中定义

   - 数据库、Apifox 和 FTP 操作均传入项目根目录绝对路径 `projectRoot`，凭据只从 `projectRoot/.env.mma` 读取。
   - 接口文档管理规范(注意必须在明确"创建/更新接口文档"时才操作)：
     - 使用 import_openapi 工具导入，项目信息：
      - 项目ID: <apiFox项目id>
      - API密钥: <apiFox密钥>
     - 保存接口根路径: `.apiDoc`目录
     - 接口文件规范：
      - 文件位置在保存接口根路径下
      - 目录结构：按 tags 属性数组顺序创建子目录
      - 文件命名：使用 summary 属性值，格式为 JSON
      - 每次仅允许导入单个接口文件。

可用命令

execute_mysql

执行 MySQL 语句，使用项目根目录中的数据库连接信息。

参数：

projectRoot: 项目根目录绝对路径
sql: 要执行的SQL语句
params: SQL查询参数（可选）

import_openapi

导入OpenAPI数据到Apifox。

参数：

input: JSON、YAML或X-YAML格式的OpenAPI数据字符串，或文件路径
projectRoot: 项目根目录绝对路径（读取 Apifox 配置）

download_apis

从Apifox下载所有API到本地文件。

参数：

projectRoot: 项目根目录绝对路径；文件下载到 .apiDoc

功能说明：

下载完整的OpenAPI 3.1规范文档

run_curl

解析并执行curl命令，返回HTTP请求结果。

参数：

curl: curl命令字符串

功能说明：

自动解析curl命令中的URL、HTTP方法、请求头、请求体等信息
返回完整的响应信息，包括状态码、响应头和响应数据
支持所有标准的curl参数和选项

FTP 命令

先调用 ftp_connect(projectRoot, connection?)。随后可使用 ftp_list、ftp_cd、ftp_upload、ftp_download、ftp_delete、ftp_rename、ftp_read、ftp_write、ftp_append、ftp_stat、ftp_exists、ftp_mkdir、ftp_rmdir 和 ftp_chmod。上传和下载支持绝对路径；相对本地路径以 projectRoot 解析。

Available Tools

6 tools

download_apisB

从Apifox下载所有API到指定目录,可传递目录绝对路径、Apifox项目ID和API密钥(读取规则或用户指定的)

ParametersJSON Schema

Name	Required	Description
`apiKey`	Yes	Apifox API密钥
`rootDir`	Yes	下载文件的根目录路径
`projectId`	Yes	Apifox项目ID

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description fails to disclose behavioral traits such as potential side effects (e.g., overwriting files), authentication requirements beyond an API key, rate limits, or the scope of 'all APIs' (e.g., all in project? all versions?). The description is too brief to ensure an agent understands behavioral implications.

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 directly communicates the tool's purpose and required inputs. No unnecessary words or redundancy, making it efficient for an agent to parse.

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 no output schema, the description omits return value details (e.g., success indication, file paths). It also does not mention error handling or prerequisites. For a simple download tool, it covers the basics but lacks completeness for robust agent 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?

Schema coverage is 100%, so the baseline is 3. The description adds minor semantic value by noting the apiKey can be 'read rule or user-specified', but this is a small addition. No further parameter context is provided beyond the schema.

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

Purpose4/5

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

The description clearly states the action (download all APIs from Apifox to a specified directory) and mentions the key parameters (rootDir, projectId, apiKey). However, it does not differentiate from sibling tools like 'import_openapi', leaving ambiguity about when to use this specific tool over others.

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 or any usage constraints. There is no mention of prerequisites, typical use cases, or 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.

execute_mysql_onlyA

仅执行execute_mysql_readonly不支持的mysql语句,使用前读取规则或用户指定的DSN链接

ParametersJSON Schema

Name	Required	Description	Default
`dsn`	Yes	MySQL数据库连接字符串，DSN格式：mysql://user:password@host:port/database
`sql`	Yes	要执行的SQL语句,执行失败重试2次

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided. The description implies mutation (since it's for write operations not supported by read-only), but does not explicitly state behavioral traits like data modification, error handling, or permissions. The retry behavior is mentioned only in the input schema, not the main description.

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?

Very concise, front-loaded with purpose. Single sentence with necessary context. Slightly cramped but effective.

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 two parameters, no output schema, and no annotations, the description provides the essential distinction but lacks details on outcomes, side effects, and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds the retry detail (in schema) but no additional meaning beyond schema. Baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states it executes MySQL statements not supported by the sibling tool execute_mysql_readonly, which distinguishes its purpose precisely.

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?

Explicitly says to use this tool only for statements the read-only sibling does not support, and advises reading rules or DSN before use. Minor omission of explicit when-not scenarios.

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

execute_mysql_readonlyA

执行只读mysql语句(仅支持SELECT、SHOW、DESCRIBE等查询操作),使用前读取规则或用户指定的DSN链接

ParametersJSON Schema

Name	Required	Description	Default
`dsn`	Yes	MySQL数据库连接字符串，DSN格式：mysql://user:password@host:port/database
`sql`	Yes	要执行的只读SQL语句(SELECT、SHOW、DESCRIBE等),如果不是读操作将终止运行

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It explicitly states that the tool is read-only and will terminate for non-read operations, which provides safety transparency. However, it lacks details on error handling, authentication, or other behavioral aspects.

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 concise, containing two clauses in one sentence. It is front-loaded with the core functionality. However, the phrase about reading rules is slightly vague and could be clearer.

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 simple structure (two required params, no output schema), the description covers the purpose and constraints but omits information about return values, potential errors, or result format. It is adequate but not fully 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 schema already describes both parameters with 100% coverage. The description adds value by reinforcing the read-only constraint on the SQL parameter and the need for a valid DSN, providing additional meaning beyond 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 executes read-only MySQL statements supporting SELECT, SHOW, DESCRIBE, etc. It distinguishes itself from the sibling 'execute_mysql_only' by emphasizing the read-only constraint.

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 mentions reading rules before use but does not provide explicit guidance on when to use this tool versus alternatives, or when not to use it. No exclusion criteria or alternative tool references are given.

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

helpC

需要获取协助时调用

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	需要协助的内容

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as what happens when called, whether it is read-only, or what response to expect. This leaves the agent completely uninformed about 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.

Conciseness3/5

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

The description is extremely concise (one phrase) but lacks structure. It is not verbose, but it is also not informative enough to be considered well-structured for its 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?

Given the lack of annotations and output schema, the description should provide more context about the tool's functionality and return value. It is too brief to be complete for an agent to use 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?

The input schema has 100% coverage with a clear description for the single parameter 'title'. The top-level description adds no additional semantic value beyond the schema, so it meets the baseline.

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 '需要获取协助时调用' restates the tool name 'help' without specifying what kind of assistance is provided. It does not differentiate from sibling tools like 'download_apis' or 'execute_mysql_only', which have clear purposes.

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 given on when to use this tool versus alternatives. The description implies general assistance but does not provide explicit context for when it should be invoked.

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

import_openapiA

导入OpenAPI数据到Apifox,在用户明确生成api文档时使用,使用前读取规则或用户指定的项目ID和API密钥,可导入json字符串/包含json文档的目录/json文件

ParametersJSON Schema

Name	Required	Description
`input`	Yes	JSON 格式 OpenAPI 数据字符串，或接口文档json文件绝对路径（示例"file#[路径]"），或包含json文件的目录绝对路径（示例"dir#[路径]"）。注意路径可能有盘符
`apiKey`	Yes	Apifox API密钥
`projectId`	Yes	Apifox项目ID

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether import is additive or destructive, rate limits, or required permissions. The description only states it imports data, leaving 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 description is a single sentence that front-loads the purpose but mixes conditions (prerequisite, input types) without clear structure. It is somewhat concise but could be better organized.

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?

There is no output schema, and the description does not explain return values or side effects. It covers input types adequately given the schema's richness, but lacks details on what happens after import (e.g., success indication, error handling).

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 covers 100% of parameters, and the description adds meaning by explaining the 'input' parameter's prefixes ('file#' and 'dir#') and noting that paths may include drive letters. This adds value beyond the schema's basic descriptions.

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 imports OpenAPI data into Apifox for generating API documentation. It specifies the input formats (JSON string, directory, file) and distinguishes from sibling tools that focus on downloading or executing queries.

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 mentions when to use it (when the user explicitly generates API docs) and prerequisites (project ID and API key). However, it does not explicitly exclude cases or compare with sibling tools like download_apis.

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

run_curlB

解析并执行curl命令，返回HTTP请求结果

ParametersJSON Schema

Name	Required	Description	Default
`curl`	Yes	curl命令字符串，例如：curl -X GET https://api.example.com/users

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It mentions parsing and execution but omits important traits like whether outgoing requests are allowed, potential side effects, or error handling. The tool executes arbitrary curl commands, which could be destructive.

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

Conciseness5/5

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

Single sentence that directly states the purpose. No superfluous content; front-loaded and efficient.

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 simple one-parameter tool without output schema, the description is adequate but lacks details on the return format (e.g., does it return status code, headers, body?). Context from sibling tools is not leveraged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a descriptive parameter description including an example. The tool description adds no extra meaning beyond 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 verb 'parse and execute curl command' and specific resource 'curl command', making it distinct from sibling tools like execute_mysql_only and download_apis.

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 run_curl vs alternatives such as download_apis or import_openapi. The description does not provide context or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.2.2Jul 13, 2026
- First observeddownload_apis
- First observedexecute_mysql_only
- First observedexecute_mysql_readonly
- First observedhelp
- First observedimport_openapi
- First observedrun_curl

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-07-13 12:00 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: two MySQL tools clearly separate read and write operations, two Apifox tools handle download and import, plus generic help and curl tools. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun pattern with underscores (e.g., download_apis, execute_mysql_readonly), but 'help' is a single word without a verb or object, causing slight inconsistency.

Tool Count4/5

Six tools cover the core functionalities of MySQL and Apifox integration. The count is slightly low but still reasonable for the defined scope, leaving room for additional operations.

Completeness3/5

Missing common operations like listing, updating, or deleting Apifox resources, and MySQL lacks schema exploration tools. The set covers basic read/write and import/export but has notable gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,908
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144

Related MCP Servers

mysqldb-mcp-server
Databases Developer Tools
burakdirin
A
license
C
quality
D
maintenance
An MCP server that enables MySQL database integration with Claude. You can execute SQL queries and manage database connections.
Updated a year ago (2025-03-18 00:01 UTC)
2
9
MIT
Apifox MCP
API Testing Documentation Access
sujianqingfeng
A
license
C
quality
C
maintenance
An MCP server that integrates Apifox API documentation with AI assistants, allowing AI to extract and understand API information from Apifox projects.
Updated 2 years ago (2025-03-14 03:39 UTC)
2
18 npm
ISC
mcp-database
Databases Developer Tools
justpoypoy
A
license
Not graded
quality
D
maintenance
MCP server for connecting to databases (PostgreSQL, MySQL, SQL Server, Redis) enabling SQL queries, table exploration, and Redis key-value operations.
Updated 9 months ago (2025-12-12 02:28 UTC)
1
MIT
@lstpsche/apidog-mcp
API Testing Documentation Access
lstpsche
A
license
A
quality
D
maintenance
MCP server that provides 22 tools to manage Apidog API documentation, including importing OpenAPI specs, exporting, diffing, analyzing, and bulk-editing endpoints.
Updated 6 months ago (2026-03-08 10:56 UTC)
22
10 npm
3
MIT