en es ja ko zh

MCP-APIKit

Name: MCP-APIKit
Author: scarqin

by scarqin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

MCP-APIKit

MCP-APIKit은 Windsurf IDE 통합을 위해 특별히 설계된 마이크로서비스 컨트롤 플레인(MCP) 서버입니다. Eolink OpenAPI에서 API 정보를 가져와 IDE의 MCP 클라이언트에 제공하여 개발 환경 내에서 원활한 API 통합 및 관리를 지원합니다.

특징

API 사양을 검색하기 위해 Eolink OpenAPI에 연결합니다.
API 정보를 MCP 리소스로 노출합니다.
API 검색 및 탐색을 위한 도구를 제공합니다.
Windsurf IDE 내에서 API 테스트 및 통합을 지원합니다.
표준화된 통신을 위한 모델 컨텍스트 프로토콜(MCP)을 구현합니다.

Related MCP server: MCP-FEISHU

설치

지엑스피1

구성

다음 변수를 사용하여 루트 디렉토리에 .env 파일을 만듭니다.

EOLINK_API_KEY=your_eolink_api_key
EOLINK_BASE_URL=https://api.eolink.com
SPACE_ID=your_space_id
PROJECT_ID=your_project_id

용법

서버 시작

pnpm start

서버는 .env 파일에 지정된 포트에서 시작됩니다(기본값: 3000).

디버그

npx @modelcontextprotocol/inspector node dist/index.js

Windsurf IDE에서 연결

pnpm build

Windsurf IDE 설정에서 다음 구성으로 새 MCP 서버를 추가합니다.

    "mcpServers": {
      "apikit": {
        "command": "node",
        "args": [
          "/Users/{userName}/Documents/mcp-apikit/dist/index.js"
        ],
        "env": {}
      }
    }

API 리소스

MCP-APIKit 서버는 다음 리소스를 제공합니다.

api://projects - 모든 API 프로젝트 나열
api://projects/{projectId} - 특정 프로젝트에 대한 세부 정보를 가져옵니다.
api://projects/{projectId}/apis - 프로젝트의 모든 API 나열
api://projects/{projectId}/apis/{apiId} - 특정 API에 대한 세부 정보를 가져옵니다.

도구

서버는 다음과 같은 도구를 제공합니다.

search-apis - 모든 프로젝트에서 API 검색
test-api - 사용자 정의 매개변수로 API 엔드포인트 테스트
import-api - Eolink에서 프로젝트로 API 사양을 가져옵니다.

개발

# Run in development mode with hot reloading
npm run dev

특허

MIT

Available Tools

6 tools

get_apiD

Name	Required	Description	Default
`projectId`	Yes	Project ID
`apiId`	Yes	API ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_projectD

Name	Required	Description	Default
`projectId`	Yes	Project ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_apisD

Name	Required	Description	Default
`projectId`	No	Project ID
`spaceId`	No	Space ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_projectsD

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_apisD

Name	Required	Description	Default
`query`	Yes	Search query

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

test_apiD

Name	Required	Description
`projectId`	Yes	Project ID
`apiId`	Yes	API ID
`headers`	No	Request headers
`queryParams`	No	Query parameters
`pathParams`	No	Path parameters
`body`	No	Request body

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

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

6 tool updatesAug 15, 2025
- First observedget_api
- First observedget_project
- First observedlist_apis
- First observedlist_projects
- First observedsearch_apis
- First observedtest_api

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

C2/5.0

Scored 2026-04-18 11:10 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_api retrieves a single API, list_apis lists multiple APIs, search_apis searches APIs, get_project retrieves a single project, list_projects lists multiple projects, and test_api tests an API. The resource-action pairs are unambiguous and well-defined.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: get_api, get_project, list_apis, list_projects, search_apis, test_api. The naming is perfectly predictable and uniform throughout the set.

Tool Count4/5

With 6 tools, the count is reasonable for managing APIs and projects, but it feels slightly thin as it lacks update or delete operations. However, it covers core retrieval and listing functions adequately for a basic API management scope.

Completeness3/5

The tool set covers retrieval and listing for APIs and projects, plus searching and testing for APIs, but there are notable gaps: no create, update, or delete operations for either resource. This limits full lifecycle management and may cause agent failures for modification tasks.

Resources

Related MCP Connectors

Swagger MCP
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144
https://swagger.mcp.smartbear.com/mcp
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
https://api.microservices.sh/mcp
secureflows-mcpA
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
https://www.secure-flows.com/mcp
Station Zero
services.stationzero
One MCP server for the services your AI needs: memory, files, Microsoft 365, kanban and more.
Knowledge & Memory File Systems Workplace & Productivity
1
https://stationzero.services/mcp

Related MCP Servers

mcp-any-openapi
Developer Tools API Testing
matthewhand
A
license
Not graded
quality
B
maintenance
A Python-based MCP server that integrates OpenAPI-described REST APIs into MCP workflows, enabling dynamic exposure of API endpoints as MCP tools.
Updated a day ago (2026-11-07 00:19 UTC)
158
MIT
MCP-FEISHU
API Testing Developer Tools App Automation
NINGyv179
A
license
D
quality
D
maintenance
A microservice control plane server that fetches API information from Feishu OpenAPI and provides it to Windsurf IDE, enabling seamless API integration and management within your development environment.
Updated 2 years ago (2025-03-21 03:31 UTC)
2
MIT
Edgee MCP Server
ampcome-mcps
A
license
Not graded
quality
D
maintenance
MCP Server for the Edgee API, enabling organization management, project operations, component management, and user administration through the Model Context Protocol.
Updated a year ago (2025-07-15 07:35 UTC)
12 npm
Apache 2.0
anyapi-mcp-server
API Testing Developer Tools RAG Systems
quiloos39
F
license
Not graded
quality
D
maintenance
A universal MCP server that connects any REST API to AI assistants via OpenAPI or Postman specifications. It enables dynamic tool creation with GraphQL-style field selection and automatic schema inference for efficient data retrieval.
Updated 7 months ago (2026-04-13 18:26 UTC)
22 npm
6
-

Appeared in Searches

Connecting Feishu (Lark)