Skip to main content
Glama

Apifox MCP 服务器

让 AI 助手自动管理你的 Apifox API 文档!

这是一个 Model Context Protocol (MCP) 服务器,允许 Claude Desktop、Claude Code、Cursor 等 MCP 客户端通过 Apifox Open API 自动导入 OpenAPI/Swagger 规范到你的 Apifox 项目。

✨ 主要功能

  • API 导入:批量导入 OpenAPI/Swagger 规范到 Apifox(稳定可靠)

  • API 导出:支持 Summary(目录结构)和 Full(完整规范)两种模式

  • 智能废弃标记:自动检测并标记已删除的接口为废弃状态(v1.2.1)

  • 部分模块导入:支持只导入部分模块,不影响其他模块(智能范围检测)

  • 多格式支持:支持 OpenAPI 3.0/3.1 和 Swagger 2.0

  • 详细统计:完整的导入/导出统计信息和错误报告

Related MCP server: Theneo MCP Server

🚀 快速开始

1. 安装

方式 1: 使用 npx(推荐)

无需安装,直接使用最新版本:

npx -y apifox-openapi-mcp@latest --token "YOUR_TOKEN" --project-id "YOUR_PROJECT_ID"

方式 2: 本地安装

# 克隆仓库
git clone https://github.com/yourusername/apifox-mcp.git
cd apifox-mcp

# 安装依赖
npm install

# 构建
npm run build

# 本地链接(可选,用于全局使用)
npm link

2. 获取 API Token 和项目 ID

步骤:

  1. 获取 Token:登录 Apifox → 头像 → 账号设置 → API 访问令牌 → 新建令牌

  2. 获取 Project ID:打开项目 → 项目设置 → 基本设置 → 复制项目 ID

3. 配置 MCP 客户端

3.1 Claude Desktop

编辑 Claude Desktop 配置文件:

  • Linux/Mac: ~/.config/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

方式 1: 使用 npx(推荐,总是使用最新版本)

{
  "mcpServers": {
    "apifox": {
      "command": "npx",
      "args": [
        "-y",
        "apifox-openapi-mcp@latest",
        "--token",
        "你的-APIFOX-TOKEN",
        "--project-id",
        "你的-项目-ID"
      ]
    }
  }
}

方式 2: 本地安装(使用绝对路径)

{
  "mcpServers": {
    "apifox": {
      "command": "node",
      "args": [
        "/绝对路径/apifox-mcp/dist/index.js",
        "--token",
        "你的-APIFOX-TOKEN",
        "--project-id",
        "你的-项目-ID"
      ]
    }
  }
}
{
  "mcpServers": {
    "apifox": {
      "command": "apifox-mcp",
      "args": [
        "--token",
        "你的-APIFOX-TOKEN",
        "--project-id",
        "你的-项目-ID"
      ]
    }
  }
}

3.2 Claude Code

方式 1: 使用 CLI 命令(推荐)

# 添加 MCP 服务器
claude mcp add apifox

# 按提示输入配置
# Command: npx
# Args: -y apifox-openapi-mcp@latest --token "你的-TOKEN" --project-id "你的-项目-ID"

# 验证配置
claude mcp list

方式 2: 直接编辑配置文件

编辑 ~/.config/Claude/claude_desktop_config.json(与 Claude Desktop 共享配置文件):

{
  "mcpServers": {
    "apifox": {
      "command": "npx",
      "args": [
        "-y",
        "apifox-openapi-mcp@latest",
        "--token",
        "你的-APIFOX-TOKEN",
        "--project-id",
        "你的-项目-ID"
      ]
    }
  }
}

重启 Claude Code 后生效。

3.3 Cursor

步骤:

  1. 打开 Cursor 设置:Cursor Settings > Features > MCP

  2. 点击 + Add New MCP Server 按钮

  3. 填写配置信息:

    • Name: apifox

    • Command: npx

    • Args:

      -y
      apifox-openapi-mcp@latest
      --token
      你的-APIFOX-TOKEN
      --project-id
      你的-项目-ID
    • Transport: stdio

  4. 保存配置

使用提示

  • Cursor 的 Composer Agent 会自动使用 MCP 工具

  • 最多支持 40 个 MCP 工具

  • 给出明确指令时效果最佳,例如:"请使用 Apifox 工具导入这个 API"

4. 重启客户端

完全退出并重新打开对应的 MCP 客户端(Claude Desktop / Claude Code / Cursor),MCP 服务器会自动加载。

📌 版本管理说明

为什么使用 @latest

  • 总是使用最新版本 - 自动获取最新功能和修复

  • 无需手动更新 - npx 会自动下载最新版本

  • 避免缓存问题 - 配合 -y 参数跳过确认

查看当前版本:

# 查看 npx 使用的版本
npx -y apifox-openapi-mcp@latest --version

# 查看 npm 上的最新版本
npm view apifox-openapi-mcp version

# 查看全局安装的版本
npm list -g apifox-openapi-mcp

其他版本管理方式:

  1. 指定具体版本(适合生产环境):

    "args": ["-y", "apifox-openapi-mcp@1.3.1", ...]
  2. 全局安装(更快的启动速度):

    npm install -g apifox-openapi-mcp

    然后在配置中使用 "command": "apifox-mcp"

📖 使用方法

在 MCP 客户端中使用

与 AI 助手(Claude Desktop / Claude Code / Cursor)对话,它会自动调用 MCP 工具:

你: 帮我创建一个用户管理 API 并导入到 Apifox

Claude: 好的,我为你创建一个用户管理 API...
[自动生成 OpenAPI 规范]
[自动调用 import_openapi 工具]

✅ OpenAPI 规范导入完成!

📋 接口导入统计:
  - 创建: 4
  - 更新: 0
  - 失败: 0
  - 忽略: 0

🎉 成功导入 4 个项!

🔧 可用工具

1. import_openapi - API 导入(推荐)

使用 Apifox Open API 批量导入 OpenAPI/Swagger 规范。稳定可靠,推荐使用。

参数

  • spec (必需): OpenAPI/Swagger 规范对象(必须包含 openapi/swaggerinfopaths 字段)

  • options (可选): 导入选项

    • endpointOverwriteBehavior: 接口覆盖行为

      • OVERWRITE_EXISTING (默认): 覆盖现有接口

      • AUTO_MERGE: 自动合并

      • KEEP_EXISTING: 保留现有

      • CREATE_NEW: 创建新接口

    • schemaOverwriteBehavior: 数据模型覆盖行为(同上)

    • markDeprecatedEndpoints: 自动标记废弃接口(v1.2.1 新增

      • true: 启用智能废弃标记(强烈推荐

      • false: 不标记(默认)

      • 工作原理

        1. 导出现有接口

        2. 智能检测导入范围(如只导入 /api/marketing 模块)

        3. 只对比该范围内的接口

        4. 标记已删除的接口为 deprecated

      • 支持部分模块导入,不会误标记其他模块

    • updateFolderOfChangedEndpoint: 是否更新修改接口的目录(默认:false

    • prependBasePath: 是否添加 basePath 前缀到路径(默认:false

    • targetBranchId: 目标分支 ID(可选,用于多分支项目)

示例 1:基础导入

{
  "spec": {
    "openapi": "3.0.0",
    "info": {
      "title": "用户管理 API",
      "version": "1.0.0"
    },
    "paths": {
      "/users": {
        "get": {
          "summary": "获取用户列表",
          "tags": ["用户管理"],
          "responses": {
            "200": {
              "description": "成功"
            }
          }
        }
      }
    }
  },
  "options": {
    "endpointOverwriteBehavior": "OVERWRITE_EXISTING"
  }
}

示例 2:启用智能废弃标记(推荐)

{
  "spec": {
    "openapi": "3.0.0",
    "info": {
      "title": "营销模块 API",
      "version": "2.0.0"
    },
    "paths": {
      "/api/marketing/campaigns": {
        "get": {
          "summary": "获取营销活动列表",
          "tags": ["营销活动"],
          "responses": {
            "200": {
              "description": "成功"
            }
          }
        }
      }
    }
  },
  "options": {
    "endpointOverwriteBehavior": "OVERWRITE_EXISTING",
    "markDeprecatedEndpoints": true
  }
}

说明

  • 导入时会自动检测范围为 /api/marketing

  • 只标记该范围内已删除的接口为废弃

  • 不会影响 /api/users/api/products 等其他模块

返回结果

✅ OpenAPI 规范导入完成!

📋 接口导入统计:
  - 创建: 4
  - 更新: 0
  - 失败: 0
  - 忽略: 0

📦 数据模型导入统计:
  - 创建: 2
  - 更新: 0
  - 失败: 0
  - 忽略: 0

🎉 成功导入 6 个项!

2. export_openapi - API 导出

从 Apifox 项目导出 OpenAPI/Swagger 规范。AI 可以使用此工具查看现有接口,避免重复创建或参考现有风格。

参数

  • mode (可选): 导出模式

    • summary: 仅导出目录结构和接口列表(推荐,节省上下文

    • full: 导出完整的 OpenAPI 规范(默认)

  • oasVersion (可选): OpenAPI/Swagger 版本(仅 full 模式有效)

    • 2.0: Swagger 2.0

    • 3.0: OpenAPI 3.0(默认)

    • 3.1: OpenAPI 3.1

  • exportFormat (可选): 导出格式(仅 full 模式有效)

    • JSON: JSON 格式(默认)

    • YAML: YAML 格式

  • pathFilter (可选): 路径过滤器,只导出匹配的接口路径(支持前缀匹配)

    • 示例:"/api/user" 只导出用户相关接口

示例 1:Summary 模式(推荐)

{
  "mode": "summary"
}

返回结果

✅ 接口文档概览(Summary 模式)

📊 统计信息:
  - 项目标题: 我的 API 项目
  - 总接口数: 26

📁 目录结构和接口列表:

📂 用户管理
  └─ [GET] /api/users
     获取用户列表
  └─ [POST] /api/users
     创建用户

📂 商品管理
  └─ [GET] /api/products
     获取商品列表

💡 提示:
  - 导入新接口时,请参考上述目录结构
  - 将相关接口放入对应的目录(使用 tags 字段)

示例 2:Full 模式 + 路径过滤

{
  "mode": "full",
  "oasVersion": "3.0",
  "exportFormat": "JSON",
  "pathFilter": "/api/user"
}

返回结果

✅ OpenAPI 规范导出成功(Full 模式)

📊 导出统计:
  - OpenAPI 版本: 3.0.1
  - 项目标题: 我的 API 项目
  - 接口数量: 2(已按 pathFilter 过滤)
  - 数据模型数量: 1

📋 接口列表:
  - /api/user [GET, POST]
  - /api/user/{id} [GET, PUT, DELETE]

📄 完整 OpenAPI 规范:
{
  "openapi": "3.0.1",
  "info": {
    "title": "我的 API 项目",
    "version": "1.0.0"
  },
  "paths": {
    "/api/user": {...},
    "/api/user/{id}": {...}
  },
  "components": {
    "schemas": {
      "User": {...}
    }
  }
}

💡 使用场景

场景 1:首次创建 API 文档

你: 帮我创建一个用户管理 API,包括 CRUD 操作

AI: [生成 OpenAPI 规范]
    [调用 import_openapi]

✅ 成功创建 4 个接口

场景 2:更新部分模块 + 自动标记废弃接口

你: 更新营销模块 API,移除优惠券接口,改用积分系统

AI: [先调用 export_openapi mode=summary 查看现有结构]
    [生成新的营销模块规范]
    [调用 import_openapi 并启用 markDeprecatedEndpoints]

🔍 检测到导入范围: /api/marketing
🔖 标记了 1 个废弃接口路径(优惠券相关)
✅ 其他模块(用户、商品)保持不变

场景 3:查看现有接口避免重复

你: 帮我添加商品搜索功能

AI: [先调用 export_openapi mode=summary]
    发现项目中已有 /api/products/search 接口
    我可以参考现有的接口风格来设计新功能...

📊 API 响应格式

导入成功后会返回详细的统计信息:

{
  "data": {
    "counters": {
      "endpointCreated": 4,       // 创建的接口数
      "endpointUpdated": 0,       // 更新的接口数
      "endpointFailed": 0,        // 失败的接口数
      "endpointIgnored": 0,       // 忽略的接口数
      "schemaCreated": 2,         // 创建的数据模型数
      "schemaUpdated": 0,         // 更新的数据模型数
      "schemaFailed": 0,          // 失败的数据模型数
      "schemaIgnored": 0          // 忽略的数据模型数
      // ... 其他计数
    },
    "errors": []  // 错误信息(如果有)
  }
}

⚙️ 命令行使用

你也可以直接从命令行运行 MCP 服务器:

# 方式 1: 使用命令行参数
node dist/index.js --token "YOUR_TOKEN" --project-id "YOUR_PROJECT_ID"

# 方式 2: 使用环境变量
export APIFOX_TOKEN="YOUR_TOKEN"
export APIFOX_PROJECT_ID="YOUR_PROJECT_ID"
node dist/index.js

# 可选参数
node dist/index.js \
  --token "YOUR_TOKEN" \
  --project-id "YOUR_PROJECT_ID" \
  --base-url "https://api.apifox.com"

🛠 技术栈

  • TypeScript - 类型安全的开发

  • MCP SDK - Model Context Protocol 实现

  • Apifox Open API - 官方 API 接口

  • Axios - HTTP 客户端

🔗 关于 Apifox Open API

本项目使用 Apifox Open API 官方接口,经过充分测试,以下功能稳定可用:

功能

API 端点

状态

说明

导入 OpenAPI

POST /v1/projects/{projectId}/import-openapi

✅ 稳定

支持批量导入、覆盖策略、废弃标记

导出 OpenAPI

POST /v1/projects/{projectId}/export-openapi

✅ 稳定

支持多版本、过滤、格式选择

版本支持

  • OpenAPI 3.0.x ✅

  • OpenAPI 3.1.x ✅

  • Swagger 2.0 ✅

📝 开发

# 安装依赖
npm install

# 开发模式(自动重新编译)
npm run watch

# 构建
npm run build

# 清理构建产物
npm run clean

🐛 故障排除

问题:Claude Desktop 看不到工具

解决方案

  1. 检查配置文件路径和格式是否正确

  2. 确保使用绝对路径

  3. 完全退出并重启 Claude Desktop(不是最小化)

问题:导入失败

可能原因

  1. Token 或项目 ID 不正确

  2. OpenAPI 规范格式不完整

  3. 网络连接问题

解决方案

  • 检查 Token 和项目 ID 是否正确

  • 验证 OpenAPI 规范是否包含必需字段(openapi/swagger, info, paths)

  • 查看错误信息了解具体原因

问题:导入后没有创建任何内容

可能原因

  • 项目中已存在相同的 API(被设置为忽略)

解决方案

  • 修改 API 的路径或名称

  • 使用 endpointOverwriteBehavior: "OVERWRITE_EXISTING" 选项覆盖现有接口

  • 在 Apifox Web 界面检查导入结果

问题:导出失败或返回空数据

可能原因

  • 项目中没有接口

  • Token 权限不足

解决方案

  • 检查项目中是否有接口

  • 确认 Token 有读取权限

📚 相关文档

📄 许可证

MIT License

🤝 贡献

欢迎提交 Issue 和 Pull Request!

如果你发现了更多可用的 Apifox Open API 端点,欢迎分享。


Made with ❤️ for the Apifox community

Available Tools

2 tools
export_openapiA

查看 Apifox 接口文档:从 Apifox 项目导出接口信息。重要:在导入新接口前,务必先使用 summary 模式查看现有目录结构和接口列表,以便将新接口放入合适的目录中,保持项目结构一致性。

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNo导出模式:summary=仅导出目录结构和接口列表(推荐,节省上下文),full=导出完整的 OpenAPI 规范。默认为 summary
oasVersionNoOpenAPI 规范版本,默认为 3.0(仅 full 模式有效)
exportFormatNo导出格式,默认为 JSON(仅 full 模式有效)
pathFilterNo路径过滤器,只导出匹配的接口路径(支持前缀匹配),如 "/api/user" 只导出用户相关接口

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the important constraint about using summary mode before imports and hints at context-saving benefits, but doesn't describe authentication requirements, rate limits, error conditions, or what the exported data looks like. For a tool with no annotations, this leaves significant behavioral aspects undocumented.

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 appropriately concise with two sentences. The first states the purpose, the second provides important usage guidance. Both sentences earn their place by adding value. However, the structure could be slightly improved by front-loading the purpose more explicitly.

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 annotations, no output schema, and 4 parameters, the description provides adequate purpose and usage guidance but lacks details about authentication, error handling, rate limits, and output format. For a tool that exports potentially complex data, more context about what gets returned would be helpful, though the schema coverage is excellent.

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?

With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'summary 模式' (summary mode) which aligns with the 'mode' parameter, but provides no additional semantic context about parameters beyond what the schema already states.

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: '从 Apifox 项目导出接口信息' (export interface information from an Apifox project). It specifies the resource (Apifox project interfaces) and verb (export), but doesn't explicitly differentiate from its sibling 'import_openapi' beyond the obvious export/import distinction.

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 usage guidance: '在导入新接口前,务必先使用 summary 模式查看现有目录结构和接口列表,以便将新接口放入合适的目录中' (before importing new interfaces, use summary mode to view existing directory structure and interface list). This gives a specific when-to-use scenario and recommends summary mode for context-saving. However, it doesn't explicitly state when NOT to use this tool or alternatives beyond the sibling import tool.

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

import_openapiA

维护 Apifox 接口文档:将 OpenAPI/Swagger 规范导入到 Apifox 项目。支持 OpenAPI 3.0/3.1 和 Swagger 2.0 格式。

⭐ 最佳实践(强烈推荐):

  1. 【分批导入】按模块分批导入(如先导入 /api/users,再导入 /api/products),而非一次性导入所有接口

  2. 【智能范围检测】每次只导入一个功能模块的完整规范,系统会自动识别范围

  3. 【启用废弃标记】设置 markDeprecatedEndpoints: true,自动保留并标记已删除的接口

分批导入的好处:更安全、更可控、支持模块独立维护、避免大规模误操作。

ParametersJSON Schema
NameRequiredDescriptionDefault
specYesOpenAPI/Swagger 规范的 JSON 对象。必须包含 openapi 或 swagger 字段、info 字段、paths 字段
optionsNo导入选项(可选)

TDQS

A4.4/5.0
Behavior4/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 effectively describes key behavioral traits: the tool performs a write operation (importing), mentions safety mechanisms like batch importing to avoid large-scale errors, and details how 'markDeprecatedEndpoints' and 'confirmHighDeprecation' options work as safeguards. It doesn't cover all potential behavioral aspects like error handling or performance limits, but provides substantial context beyond basic functionality.

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 appropriately front-loaded with the core purpose, but the best practices section is quite detailed (multiple bullet points with explanations). While all content is relevant, it could be more concise; some explanations (like the benefits of batch importing) are somewhat verbose. The structure is logical but not maximally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (import operation with multiple behavioral options), no annotations, and no output schema, the description does a good job of providing context. It covers the core purpose, usage guidelines, key behavioral traits, and parameter semantics. However, it lacks details on error cases, response format, or authentication requirements, leaving some gaps for a tool of this nature.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful context about parameters: it explains the purpose of 'markDeprecatedEndpoints' in practice (recommending its use and detailing what it does), and implicitly relates to 'spec' by discussing batch importing strategies. While it doesn't detail every parameter, it enhances understanding of key options beyond the schema's technical 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's purpose: '将 OpenAPI/Swagger 规范导入到 Apifox 项目' (import OpenAPI/Swagger specifications into Apifox projects). It specifies supported formats (OpenAPI 3.0/3.1, Swagger 2.0) and distinguishes from its sibling 'export_openapi' by being the import counterpart. The verb '导入' (import) with resource 'Apifox 接口文档' (Apifox API documentation) is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines with a '最佳实践' (best practices) section that details when and how to use the tool effectively. It recommends batch importing by module, explains the benefits of this approach, and mentions specific configuration options like 'markDeprecatedEndpoints: true'. While it doesn't explicitly mention alternatives, the guidelines are comprehensive for proper usage.

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. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedexport_openapi
    • First observedimport_openapi

TDQS

A3.8/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: export_openapi retrieves existing interface information for viewing and planning, while import_openapi adds new OpenAPI/Swagger specifications into the project. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (export_openapi and import_openapi), using the same base noun 'openapi' with descriptive action verbs. This naming scheme is predictable and enhances readability across the tool set.

Tool Count3/5

With only 2 tools, the server feels thin for managing Apifox interface documentation, a domain that typically involves more operations like updating, deleting, or searching interfaces. While export and import cover core workflows, the limited count may restrict agent capabilities in handling full lifecycle tasks.

Completeness2/5

The tool set is severely incomplete for interface documentation management. It lacks essential CRUD operations such as updating or deleting interfaces, and there are no tools for searching or summarizing beyond the export's summary mode. This creates significant gaps that could lead to agent failures in maintaining a comprehensive project structure.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to fetch and understand API endpoint definitions from Apifox projects in real-time. Supports retrieving complete API specifications including request methods, parameters, headers, and response schemas to improve development efficiency and code generation quality.
    1
    21
    4
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to automatically create, update, and publish API documentation through Theneo's platform. Supports OpenAPI specs, Postman collections, AI-powered description generation, and natural language interactions for seamless documentation workflows.
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to import OpenAPI 3 and Swagger 2 formatted JSON data directly into Apifox projects. It provides a tool for automating API documentation management and synchronization through Model Context Protocol clients.
    -

Latest Blog Posts

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/Warren-W/apifox-mcp'

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