en es ja ko zh

MCP-APIKit

Name: MCP-APIKit
Author: scarqin

by scarqin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Kit de API MCP

MCP-APIKit es un servidor de plano de control de microservicios (MCP) diseñado específicamente para la integración con Windsurf IDE. Obtiene información de la API de Eolink OpenAPI y la proporciona al cliente MCP del IDE, lo que permite una integración y gestión fluidas de la API en su entorno de desarrollo.

Características

Se conecta a Eolink OpenAPI para recuperar especificaciones de API
Expone información de API como recursos MCP
Proporciona herramientas para el descubrimiento y exploración de API.
Admite pruebas de API e integración dentro de Windsurf IDE
Implementa el Protocolo de Contexto de Modelo (MCP) para la comunicación estandarizada

Related MCP server: MCP-FEISHU

Instalación

# 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

Configuración

Cree un archivo .env en el directorio raíz con las siguientes variables:

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

Uso

Iniciando el servidor

pnpm start

El servidor se iniciará en el puerto especificado en su archivo .env (predeterminado: 3000).

Depurar

npx @modelcontextprotocol/inspector node dist/index.js

Conexión desde Windsurf IDE

pnpm build

En la configuración de Windsurf IDE, agregue un nuevo servidor MCP con la siguiente configuración:

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

Recursos de API

El servidor MCP-APIKit expone los siguientes recursos:

api://projects - Lista todos los proyectos de API
api://projects/{projectId} - Obtener detalles de un proyecto específico
api://projects/{projectId}/apis - Enumera todas las API de un proyecto
api://projects/{projectId}/apis/{apiId} - Obtener detalles de una API específica

Herramientas

El servidor proporciona las siguientes herramientas:

search-apis : busca API en todos los proyectos
test-api : prueba un punto final de API con parámetros personalizados
import-api : importa una especificación de API de Eolink a tu proyecto

Desarrollo

# Run in development mode with hot reloading
npm run dev

Licencia

Instituto Tecnológico de Massachusetts (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

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

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-mcp A
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
jumpcloud-genai
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
https://mcp.jumpcloud.com/v1

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 4 days ago (2026-10-31 21:24 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)