Which integrations are available for this server?

Used for environment variable configuration of the MCP-APIKit server Used for repository hosting and cloning the MCP-APIKit project Used for package management in the MCP-APIKit project

How do I use MCP-APIKit?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-APIKit search for user authentication APIs" 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.

en es ja ko zh

MCP-APIKit

by scarqin

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

MCP-APIKit

MCP-APIKit is a microservice control plane (MCP) server designed specifically for Windsurf IDE integration. It fetches API information from Eolink OpenAPI and provides it to the IDE's MCP client, enabling seamless API integration and management within your development environment.

Features

Connects to Eolink OpenAPI to retrieve API specifications
Exposes API information as MCP resources
Provides tools for API discovery and exploration
Supports API testing and integration within Windsurf IDE
Implements the Model Context Protocol (MCP) for standardized communication

Related MCP server: MCP-FEISHU

Installation

# 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

Configuration

Create a .env file in the root directory with the following 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

Usage

Starting the Server

pnpm start

The server will start on the port specified in your .env file (default: 3000).

Debug

npx @modelcontextprotocol/inspector node dist/index.js

Connecting from Windsurf IDE

pnpm build

In your Windsurf IDE settings, add a new MCP server with the following configuration:

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

API Resources

The MCP-APIKit server exposes the following resources:

api://projects - List all API projects
api://projects/{projectId} - Get details for a specific project
api://projects/{projectId}/apis - List all APIs in a project
api://projects/{projectId}/apis/{apiId} - Get details for a specific API

Tools

The server provides the following tools:

search-apis - Search for APIs across all projects
test-api - Test an API endpoint with custom parameters
import-api - Import an API specification from Eolink to your project

Development

# Run in development mode with hot reloading
npm run dev

License

MIT

Available Tools

6 tools

get_apiD

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2/5.0

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

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
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
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

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 3 days ago (2026-09-06 00:05 UTC)
153
MIT
MCP-FEISHU
API Testing Developer Tools App Automation
NINGyv179
F
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 a year ago (2025-03-21 03:31 UTC)
2
-
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)
11
Apache 2.0
anyapi-mcp-server
API Testing Developer Tools RAG Systems
quiloos39
A
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 5 months ago (2026-04-13 18:26 UTC)
31
6
-

Appeared in Searches

Connecting Feishu (Lark)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/scarqin/mcp-apikit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server