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 MCP server lets AI assistants query Eolink Apikit API documentation in a read-only way via the provided schema.
List all projects in the Eolink workspace.
List interface groups within a project.
Search APIs by keyword, group, or status.
Find an API by exact or prefix path.
Get full details for a single API.
Export a project or selected groups as OpenAPI/Swagger JSON.
Note: The README mentions write tools, but the provided server schema exposes only read-only tools.
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 |
|
| 否 | 禁用代理解析（默认自动读 |
|
| 否 | 启动时联网校验凭据有效性（见下） |
| — | 否 | 打印用法 |
--key=value 与 --key value 两种写法都支持；值本身以 - 开头时必须用 = 形式
（如 --token=-abc123），否则会被当成另一个参数。开关类参数（--no-proxy、--verify-on-start）
不接受值，关闭请直接去掉该参数。--help 与配置错误信息走 stderr（stdio 下 stdout 被 MCP 协议占用）。
# 全走命令行参数
eolink-mcp --base-url https://your-eolink.example.com --token <token> --space-id <id>
# 也可混用：token 走参数，其余走环境变量
eolink-mcp --token <token>在 MCP 客户端里通过 args 传参：
{
"mcpServers": {
"eolink": {
"command": "eolink-mcp",
"args": ["--base-url", "https://your-eolink.example.com",
"--token", "your-token", "--space-id", "your-space-id"]
}
}
}安全提示：参数写在
args里会明文出现在客户端配置文件中；更重要的是， 命令行参数在进程存活期间可通过ps或/proc/<pid>/cmdline被同机其他用户读到， 而环境变量/proc/<pid>/environ仅属主可读。因此多用户 / 共享主机上建议用env而非args传令牌；args更适合单用户桌面或调试场景。 无论哪种方式，都注意不要提交到版本库。
启动时的配置校验
分两层，边界是「能否在本地判定」：
本地校验（始终生效）：三个配置项缺失、或 base url 不是合法 http(s):// 地址时，
启动即打印明确错误并 exit(1)（base url 与 token 的错误会标明生效来源）；token 短于 16 字符时打告警但不退出。
参数层面的问题一律告警但不退出（避免客户端往 args 塞入自身参数时误伤），包括：
无法识别的参数、空值参数（如 --token ""，会回落到环境变量）、
以及给开关类参数传值（如 --no-proxy=false——开关不接受值，关闭请直接去掉该参数）。
联网校验（默认关闭）：token 格式合法但实际无效（如填错、已过期）时，
本地无从判断，默认要等到调用工具才报错。加 --verify-on-start（或设
EOLINK_VERIFY_ON_START=1）可改为启动时用一次 project/search 探测
（5 秒超时、不重试），凭据无效则立即 exit(1)。
默认关闭是因为启动时联网探测会拖慢启动，且内网不通/代理未就绪/Eolink 抖动时会把 「临时不可达」误判成「配置错误」而拒绝启动。需要「配置错了就当场失败」时再开启。
无论是否开启，任何时候都可用 eolink_health_check 按需体检。
Claude Code
方式一：全局 bin（推荐，多实例安全）
npm install -g @huberyhe/eolink-mcp@1.2.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 为工作空间标识；
base url 为实例 Open API 根地址。三者都可用 --base-url / --token / --space-id 参数
或对应的 EOLINK_* 环境变量传入。
代理
访问 Eolink 实例（尤其私有化内网部署）常需经代理。本 server 自动读取 HTTP(S)_PROXY 环境变量；
用 --no-proxy 或设 EOLINK_NO_PROXY=1 可禁用。
排障
遇到任何 eolink_* 工具报错，先调用 eolink_health_check —— 它会逐项报告配置项、各自的来源（命令行参数 / 环境变量）、连通性与鉴权状态，并明确指出该改哪一项。令牌只显示遮蔽后的形态（如 8SnX…75d7），不会回显明文。
常见故障与对策：
现象 | 原因 | 对策 |
| token 无效或未传；或复制时带了空格/换行 | 到后台「空间设置 / 开放 API」重新生成；本 server 已自动 trim 首尾空白。注意参数会覆盖环境变量，若两处都配了以参数为准 |
|
| 先用 |
启动即失败、 | 缺少必需配置项，或 base url 不是合法地址 | fail-fast 设计；用 |
| base url 写错、内网不通或代理未生效 | 核对 base url（ |
| base url 指到了网页根地址而非 Open API 根地址 | 填实例根地址即可（如 |
| 导出/搜索的响应体超过保护上限（实测单项目全量导出可达 12MB） | 缩小范围： |
配置层面已内置的容错：base url 自动去尾随斜杠，token / space id 自动 trim 首尾空白；
空的命令行参数值（如 --token ""）不会覆盖已有的环境变量。
本地开发
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（配置可用 -e 传环境变量，或直接在 -- 后追加命令行参数）：
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.js
# 或走命令行参数
npx @modelcontextprotocol/inspector --cli --transport stdio \
--method tools/list -- node dist/index.js \
--base-url xxx --token xxx --space-id xxx查看可用参数：
node dist/index.js --helpLicense
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
ActivityMaintained
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.
Discover, compare, route, and execute machine-accessible capabilities for AI agents.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
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.122 npm5MIT
- 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.1,260 npm1ISC
- AlicenseAqualityDmaintenanceExposes Swagger/OpenAPI API documentation to AI models, enabling exploration, search, and interaction with endpoints, schemas, and execution of API calls.142 npm2MIT