en es ja ko zh

MCP-APIKit

Name: MCP-APIKit
Author: scarqin

by scarqin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

MCP-APIキット

MCP-APIKitは、Windsurf IDEとの統合に特化して設計されたマイクロサービスコントロールプレーン（MCP）サーバーです。Eolink OpenAPIからAPI情報を取得し、IDEのMCPクライアントに提供することで、開発環境内でシームレスなAPI統合と管理を実現します。

特徴

Eolink OpenAPIに接続してAPI仕様を取得します
API情報をMCPリソースとして公開する
APIの検出と探索のためのツールを提供する
Windsurf IDE内でのAPIテストと統合をサポート
標準化された通信のためのモデルコンテキストプロトコル（MCP）を実装します

Related MCP server: MCP-FEISHU

インストール

# Clone the repository
git clone https://github.com/yourusername/mcp-apikit.git
cd mcp-apikit

# Install dependencies
pnpm install

# Build the project
pnpm run build

構成

次の変数を含む.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

ライセンス

マサチューセッツ工科大学

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.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.
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 an hour 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)