A
licenseA
qualityNot graded
maintenanceEnables AI assistants to access and search RAP2 API documentation, allowing users to query interface details, search APIs by keywords, and retrieve repository interfaces through natural language.
7
7 npm
-
eolink-mcp
by huberyhe
This server enables AI assistants to query and manage API documentation from an Eolink Apikit instance (SaaS or private deployment) via the Eolink Open API.
Read (Query) Tools:
List Projects (
eolink_list_projects): Retrieve all projects in the workspace — typically the required first step.List Groups (
eolink_list_groups): View the interface group/folder tree for a project, including nested subgroups.Search APIs (
eolink_search_apis): Fuzzy search for APIs by keyword (name, URL, or tag), group, or status.Find API by Path (
eolink_find_api_by_path): Precisely locate an API by URL path using exact or prefix matching.Get API Detail (
eolink_get_api_detail): Fetch the full definition of an API including request headers, query/path/body params, and response structure.Export OpenAPI (
eolink_export_openapi): Bulk-export an entire project or specific groups as an OpenAPI JSON document.
Write (Modify) Tools:
Create API (
eolink_create_api): Add a new HTTP API definition to a project.Update API (
eolink_update_api): Modify an existing API definition by its ID.Create Group (
eolink_create_group): Add a new interface group/folder within a project.
⚠️ Deletion of APIs is not supported via the Eolink Open API and must be done manually in the Eolink backend.
Click on "Deploy 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., "@eolink-mcpLook up the API endpoint /api/v1/login and give me its full definition"
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.
eolink-mcp
An MCP server that lets AI assistants (Claude Code, etc.) query API documentation from any Eolink Apikit instance — SaaS or private deployment — via the Eolink Open API.
安装
npm install -g @huberyhe/eolink-mcp # 推荐：全局安装，多实例无竞态
# 或
npx @huberyhe/eolink-mcp # 免安装直接运行（首次需下载）多个 Claude Code 实例同时冷启动时，npx 共用缓存可能偶现竞态导致
not found。全局安装可完全避免。
Related MCP server: Apifox MCP Server
提供的工具
查询（只读）
工具 | 用途 | project_id |
| 列出空间所有项目（第一步） | 不需要 |
| 列出指定项目的接口分组树 | 必填 |
| 按关键字/分组/状态模糊搜索接口（匹配名称/URL/Tag） | 必填 |
| 按 api_path 精确/前缀查找接口 | 必填 |
| 按 api_id 获取单个接口的完整定义（请求/响应参数） | 必填 |
| 导出整个项目为 OpenAPI JSON（兜底全量） | 必填 |
写入（会改动 Eolink 文档）
工具 | 用途 | project_id |
| 新增 HTTP 接口（不传 api_id） | 必填 |
| 修改已有接口（传 api_id） | 必填 |
| 新增接口分组 | 必填 |
⚠️ 写工具默认启用，AI 可直接增改接口文档。修改建议先
get_api_detail确认当前内容。Eolink Open API 不开放删除接口，删除请到 Eolink 后台手动操作。写操作经/index.php/入口，add_group使用 form-urlencoded 格式——这些差异已内置处理，使用者无需关心。参数类型param_type用数字（0=string 3=int 2=json 8=boolean 等）。
典型流程：list_projects → search_apis 或 find_api_by_path（带 project_id）→ get_api_detail。
按名称找用
search_apis；按 URL 找用find_api_by_path（exact等值 /prefix前缀），比模糊搜索更精准。
配置
变量 | 必填 | 说明 |
| 是 | Eolink 实例 Open API 地址，如 |
| 是 | Open API 令牌（对应请求头 |
| 是 | 工作空间 ID |
| 否 | 设 |
Claude Code
方式一：全局 bin（推荐，多实例安全）
npm install -g @huberyhe/eolink-mcp@1.1.0然后在 ~/.claude.json 的 mcpServers 中添加：
{
"mcpServers": {
"eolink": {
"command": "eolink-mcp",
"args": [],
"env": {
"EOLINK_BASE_URL": "https://your-eolink.example.com",
"EOLINK_TOKEN": "your-open-api-secret-key",
"EOLINK_SPACE_ID": "your-space-id"
}
}
}
}方式二：npx（免安装）
{
"mcpServers": {
"eolink": {
"command": "npx",
"args": ["-y", "@huberyhe/eolink-mcp"],
"env": { ... }
}
}
}npx 首次需下载，多实例冷启动偶现缓存竞态。长期使用推荐全局安装。
本地调试：可在配置中保留两条入口，正式用全局 bin，改代码后用 dist 直连：
"eolink": { "command": "eolink-mcp" }, // 日常
"eolink_test": { "command": "node", "args": ["dist/index.js"] } // 调试用 claude mcp list 查看连接状态。
其它 MCP 客户端
任何支持 stdio MCP server 的客户端都适用：command 为 eolink-mcp（全局安装）或 npx -y @huberyhe/eolink-mcp（免安装），env 同上。
获取凭证
在 Eolink 后台「空间设置 / 开放 API」处生成 Open API 令牌（即 Eo-Secret-Key）；space_id 为工作空间标识；EOLINK_BASE_URL 为实例 Open API 根地址。
代理
访问 Eolink 实例（尤其私有化内网部署）常需经代理。本 server 自动读取 HTTP(S)_PROXY 环境变量；设 EOLINK_NO_PROXY=1 可禁用。
本地开发
git clone https://github.com/huberyhe/eolink-mcp.git && cd eolink-mcp
npm install && npm run build # 产物在 dist/index.js改代码后 npm run build，重启 MCP 即生效。可在 ~/.claude.json 中保留两条入口：
"eolink": { "command": "eolink-mcp" }, // 正式，走 npm
"eolink_test": { "command": "node", "args": ["dist/index.js"] } // 调试，改代码即生效测试用 MCP Inspector：
npx @modelcontextprotocol/inspector --cli --transport stdio \
-e EOLINK_BASE_URL=xxx -e EOLINK_TOKEN=xxx -e EOLINK_SPACE_ID=xxx \
--method tools/list -- node dist/index.jsLicense
MIT
Available Tools
6 toolseolink_export_openapi导出 Eolink 接口文档ARead-onlyIdempotent
导出指定项目（或指定分组）的接口文档为 OpenAPI/Swagger JSON，适合一次性全量获取。
参数：
project_id：项目 ID（必填）
group_ids：可选，只导出指定分组
注意：全量导出可能很大，会自动按字符上限截断。日常查询单个接口建议用 eolink_search_apis + eolink_get_api_detail。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| group_ids | No | 只导出指定分组；留空导出整个项目 | |
| project_id | Yes | 项目 ID（先用 eolink_list_projects 获取） |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds critical behavioral context: '全量导出可能很大，会自动按字符上限截断' (automatic truncation by character limit), which is not conveyed by annotations. No contradiction.
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 concise with a clear structure: purpose, parameters, behavioral note, and usage guidance. Every sentence adds value, no fluff.
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 no output schema, the description mentions the output format (OpenAPI/Swagger JSON) and truncation behavior. It references sibling tools for prerequisites. Could add explicit mention of project ID source, but that's in schema parameter description.
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?
Schema coverage is 100% with both parameters described. The description adds value by stating project_id is required and hinting to obtain it via eolink_list_projects, and clarifying group_ids is optional for filtering groups. This provides context beyond the schema alone.
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 '导出' (export) and the resource '接口文档为 OpenAPI/Swagger JSON'. It specifies the required project_id and optional group_ids, and distinguishes itself from sibling tools by noting it's suitable for full export, not single API queries.
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 explicitly advises when to use ('一次性全量获取') and when not to ('日常查询单个接口' recommends alternatives). It names specific sibling tools (eolink_search_apis + eolink_get_api_detail) as better for daily use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eolink_find_api_by_path按 URL 精确查找 Eolink 接口ARead-onlyIdempotent
按接口路径（api_path）精确查找接口，规避 eolink_search_apis 的模糊分词噪声。
内部拉取项目下全部接口后在 server 端按 api_path 匹配，只返回真正匹配的接口。
参数：
project_id：项目 ID（必填）
api_path：接口路径，如 user/user/list（可带前导 /）
match_mode：exact=完全相等（默认），prefix=以给定值开头
返回匹配接口的 api_id、api_name、api_path、method 等。拿到 api_id 后用 eolink_get_api_detail 看完整定义。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_path | Yes | 接口路径，如 user/user/list。可带前导斜杠，会自动归一化。匹配依据见 match_mode | |
| match_mode | No | exact：api_path 完全相等；prefix：api_path 以给定值开头（用于按前缀批量找同模块接口） | exact |
| project_id | Yes | 项目 ID（先用 eolink_list_projects 获取） |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it pulls all project APIs server-side and matches, which is useful context. No contradictions, and no missing critical behavior.
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 well-structured with purpose first, then behavior, then parameters. It is concise but includes necessary examples. Slightly verbose in parameter list but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (2 required) and no output schema, the description explains return fields (api_id, api_name, etc.) and suggests next steps. Complete for its complexity and context signals.
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% (all three parameters described in input schema). The description also provides examples and extra context (e.g., 'user/user/list' with optional leading slash). Baseline score is appropriate as schema already does the heavy lifting.
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: find APIs by exact path (api_path). It distinguishes itself from eolink_search_apis, which has fuzzy search noise, providing a specific verb+resource combination.
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?
Explicitly says when to use this tool: for exact path matching to avoid fuzzy noise. It also mentions an alternative: use eolink_get_api_detail for full definitions after obtaining api_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eolink_get_api_detail获取 Eolink 接口详情ARead-onlyIdempotent
获取单个 HTTP 接口的完整定义：基础信息、请求头、query 参数、restful 参数、请求体参数、响应结构（含 mock 示例）。
参数：
project_id：项目 ID（必填）
api_id：接口 ID（先用 eolink_search_apis 搜索得到）
返回 Markdown 格式的接口文档，包含每个参数的名称、类型、是否必填、说明、示例值。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | 接口 ID，可从 eolink_search_apis 的结果获取 | |
| project_id | Yes | 项目 ID（先用 eolink_list_projects 获取） |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by disclosing the return format (Markdown documentation) and the comprehensive set of returned details, which is beyond what annotations provide.
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 yet comprehensive. It uses a bullet-like structure to list return components and clearly separates parameter instructions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains the return value (Markdown with parameter details). It covers prerequisites, required parameters, and output format, making the tool fully understandable.
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?
Schema coverage is 100%, but the description adds meaningful guidance: it specifies that api_id comes from eolink_search_apis and project_id from eolink_list_projects, enhancing understanding of parameter dependencies.
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 specifies the exact resource ('单个 HTTP 接口的完整定义') and lists all included components (基础信息、请求头、query 参数等), clearly distinguishing it from sibling tools like eolink_search_apis which only return a list.
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 explains that project_id and api_id are required, and tells how to obtain them (via eolink_list_projects and eolink_search_apis). It could be improved by explicitly stating when not to use this tool, but the prerequisites are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eolink_list_groups列出 Eolink 接口分组ARead-onlyIdempotent
列出指定项目下的所有接口分组（含子分组），用于了解接口按业务模块的组织结构。
参数：
project_id：项目 ID（先用 eolink_list_projects 获取）
返回分组树，每个分组含 group_id、group_name、parent_group_id，子分组在 group_child_list 里。
典型用法：本工具拿到 group_id 后，用 eolink_search_apis 的 group_ids 过滤某模块下的接口。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | 项目 ID（先用 eolink_list_projects 获取） |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds return structure details (group_id, group_name, parent_group_id, group_child_list) and hierarchical nature, which annotations don't cover.
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?
Concise and well-structured: purpose statement, parameter description, return structure, and typical usage pattern. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, read-only, and no output schema, the description fully covers purpose, parameter, return format, and usage workflow.
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?
Only one parameter project_id with 100% schema coverage. Description adds context on how to obtain it via eolink_list_projects, which is not in 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?
Description clearly states the tool lists all interface groups (including sub-groups) under a project for understanding organizational structure. It distinguishes itself from siblings like eolink_search_apis by specifying its use case.
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?
Provides clear context: used after getting project_id via eolink_list_projects, and typical usage to feed group_id into eolink_search_apis. No explicit when-not-to-use, but the read-only nature makes it broadly applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eolink_list_projects列出 Eolink 项目ARead-onlyIdempotent
列出当前 Eolink 工作空间下的所有项目（调用 /v2/api_studio/management/project/search）。
不需要参数。返回每个项目的 project_id 和 project_name（以及创建人、是否归档）。
这是使用其它工具前的第一步：拿到目标项目的 project_id，再在 list_groups / search_apis / get_api_detail / export_openapi 调用时显式传入。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns project_id, project_name, creator, and archive status, which is useful but not critical for safety. No contradictions.
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?
Two concise sentences: first states purpose and endpoint, second provides usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers purpose, return fields, and usage context as a first step. Sibling tools listed. Fully adequate for the tool's simplicity.
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?
No parameters exist, and description confirms '不需要参数' (no parameters needed). With 0 parameters and 100% schema coverage, baseline is 4. No additional parameter info needed.
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 lists all projects in the current workspace, specifying the verb (列出), resource (项目), and scope (当前工作空间). It includes the API endpoint, distinguishing it from siblings like list_groups or search_apis.
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?
Explicitly states this is the first step before using other tools, mentioning that the obtained project_id should be passed to list_groups, search_apis, get_api_detail, and export_openapi. Provides clear when-to-use and why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eolink_search_apis搜索 Eolink 接口ARead-onlyIdempotent
按关键字、分组或状态搜索指定项目里的接口，返回接口列表（api_id、名称、URL、方法、分组等）。
这是查接口最常用的入口。拿到 api_id 后，用 eolink_get_api_detail 获取完整定义。
参数：
project_id：项目 ID（必填，先用 eolink_list_projects 获取）
keyword：搜索关键字（匹配名称/URL/Tag），可选
group_ids：分组 ID 数组，可选（先用 eolink_list_groups 拿）
api_status：状态过滤，可选
limit：返回数量上限（默认 30）
返回每个接口的 api_id（后续取详情要用）、api_name、api_path、method、group_name 等。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最多返回的接口数量（默认 30） | |
| keyword | No | 搜索关键字，匹配 API 名称、URL 或 Tag。留空则返回所有接口 | |
| group_ids | No | 按分组 ID 过滤，可先用 eolink_list_groups 获取。如 [311986] | |
| api_status | No | 接口状态过滤：enable=已启用，disable=已禁用 | |
| project_id | Yes | 项目 ID（先用 eolink_list_projects 获取） |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, openWorld, idempotent, non-destructive. Description adds return fields, pagination with default limit, and filtering options, providing valuable behavioral context beyond annotations.
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?
Concise, well-structured with bullet points for parameters. Front-loaded with purpose and usage. No unnecessary information.
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?
No output schema, but description lists return fields (api_id, name, URL, method, group_name), which is sufficient for a search tool. Mentions limit and filtering, covering key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are described in both schema and description. Description adds value by explaining how to obtain values (e.g., project_id from list_projects, group_ids from list_groups) and clarifying keyword matching scope.
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?
Description clearly states it searches APIs by keyword, group, or status, returning a list. It distinguishes from sibling tools like eolink_get_api_detail and eolink_list_groups.
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 states it's the main entry for searching APIs and mentions using eolink_get_api_detail after retrieval. Provides parameter guidance but lacks explicit when-not-to-use or alternatives.
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 updates
v1.0.0- First observed
eolink_export_openapi - First observed
eolink_find_api_by_path - First observed
eolink_get_api_detail - First observed
eolink_list_groups - First observed
eolink_list_projects - First observed
eolink_search_apis
TDQS
A4.7/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a distinct operation: listing projects, listing groups, searching APIs, finding by exact path, retrieving detail, and exporting. No two tools overlap in purpose; even the two search-like tools (search_apis and find_api_by_path) use different matching strategies (fuzzy vs exact).
Naming Consistency5/5
All tool names follow a consistent 'eolink_verb_noun' pattern (e.g., eolink_list_projects, eolink_search_apis). No mixing of camelCase, snake_case, or inconsistent verb styles.
Tool Count5/5
With 6 tools covering project discovery, group navigation, API search and details, and export, the set is well-scoped for an API documentation server. Each tool serves a clear purpose without unnecessary weight.
Completeness5/5
The tool surface covers the full read lifecycle: discover projects, browse groups, find APIs (by search or exact path), inspect full detail, and export the entire project. No obvious gaps for a consumer of API documentation.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Related MCP Connectors
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables 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.121 npm4MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI tools to search and explore API documentation from Apidog projects or OpenAPI/Swagger specifications, providing endpoint details, schemas, and project statistics through natural language queries.735 npm1ISC
- AlicenseAqualityDmaintenanceExposes Swagger/OpenAPI API documentation to AI models, enabling exploration, search, and interaction with endpoints, schemas, and execution of API calls.141 npm2MIT