How do I use mcp-server-apidebug?

1. Click on "Deploy 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-server-apidebug Debug GET /api/users?page=1&limit=10" 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.

de en es ko ru zh

mcp-server-apidebug

by liliangshan

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

mcp-server-apidebug

English | 中文

English

MCP Server for API Debugging

A standalone MCP (Model Context Protocol) server for API debugging, login authentication, API configuration management, and indexed API execution.

Features

api_config: Manage API debugging configuration, Base URL, common Headers, and API list
api_debug: Execute API requests directly, supports GET/POST/PUT/DELETE/PATCH methods, query parameters, headers, body, automatic Content-Type detection
api_execute: Execute requests by index saved in api_config
api_login: Execute login requests based on environment variables
api_help: View API debugging tool documentation and examples

Installation

Global installation (Recommended):

npm install -g @liangshanli/mcp-server-apidebug

Local installation:

npm install @liangshanli/mcp-server-apidebug

Local Development

npm start

Or start the server directly:

node src/server.js

Quick Self-Test

npm test

This will output the MCP tools/list result.

Environment Variables

Variable	Default	Description
`PROJECT_PATH`	`.`	Project directory; uses current directory when not set
`TOOL_PREFIX`	`default`	Tool name prefix; default tools are `default_api_debug`, `default_api_config`, etc.
`CONFIG_DIR`	empty	Optional config directory override; generally not needed. When not set, uses `PROJECT_PATH/.setting/{TOOL_PREFIX}`
`API_DEBUG_BASE_URL`	empty	API base URL; when configured, no need to set `baseUrl` via `api_config`
`API_DEBUG_ALLOWED_METHODS`	`GET,POST,PUT,DELETE,PATCH`	Allowed HTTP methods, comma-separated
`API_DEBUG_LOGIN_URL`	`/api/login`	Login API URL
`API_DEBUG_LOGIN_METHOD`	`POST`	Login API method
`API_DEBUG_LOGIN_BODY`	`{"username":"","password":""}`	Login request body, supports JSON string or plain string
`API_DEBUG_LOGIN_DESCRIPTION`	empty	Login tool description
`API_DEBUG_LOGIN_USER_HEADER`	`new-api-user`	Header name for user ID (extracted from login response)

MCP Configuration Example

{
  "servers": {
    "apidebug": {
      "command": "npx",
      "args": [
        "@liangshanli/mcp-server-apidebug"
      ],
      "env": {
        "API_DEBUG_BASE_URL": "https://api.example.com",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE,PATCH",
        "API_DEBUG_LOGIN_URL": "/api/user/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"your_username\",\"password\":\"your_password\"}",
        "API_DEBUG_LOGIN_USER_HEADER": "new-api-user",
        "API_DEBUG_LOGIN_DESCRIPTION": "Execute login requests based on environment variables. Use api_config interface to handle login configuration after successful login."
      }
    }
  }
}

Configuration Storage

Default storage path:

{PROJECT_PATH}/.setting/{TOOL_PREFIX}/api.json

If PROJECT_PATH is not set, defaults to .; if TOOL_PREFIX is not set, defaults to default.

Usage Examples

Set Base URL:

{
  "action": "updateBaseUrl",
  "baseUrl": "https://api.example.com"
}

Debug an API:

{
  "url": "/api/users",
  "method": "GET",
  "query": {
    "page": 1,
    "limit": 10
  }
}

Add an API and execute by index:

{
  "action": "addApi",
  "api": {
    "url": "/api/login",
    "method": "POST",
    "body": {
      "username": "admin",
      "password": "123456"
    }
  }
}

{
  "index": 0
}

Related MCP server: Postmancer

中文

API 调试 MCP 服务器

独立运行的 MCP (Model Context Protocol) 服务器，用于 API 调试、登录认证、API 配置管理和按索引执行 API 请求。

工具列表

api_config：管理 API 调试配置、Base URL、公共 Headers 和接口列表
api_debug：直接执行 API 请求，支持 GET/POST/PUT/DELETE/PATCH 方法、query 参数、headers、body，自动检测 Content-Type
api_execute：按 api_config 中保存的接口索引执行请求
api_login：根据环境变量执行登录请求
api_help：查看 API 调试工具说明和示例

安装依赖

全局安装（推荐）：

npm install -g @liangshanli/mcp-server-apidebug

本地安装：

npm install @liangshanli/mcp-server-apidebug

本地运行

npm start

或直接启动 server：

node src/server.js

快速自检

npm test

会输出 MCP tools/list 结果。

环境变量

变量	默认值	说明
`PROJECT_PATH`	`.`	项目目录；不设置时使用当前目录
`TOOL_PREFIX`	`default`	工具名前缀；默认工具名为 `default_api_debug`、`default_api_config` 等
`CONFIG_DIR`	空	可选覆盖配置目录；一般不需要设置。未设置时使用 `PROJECT_PATH/.setting/{TOOL_PREFIX}`
`API_DEBUG_BASE_URL`	空	API 基础 URL；配置后无需再通过 `api_config` 设置 `baseUrl`
`API_DEBUG_ALLOWED_METHODS`	`GET,POST,PUT,DELETE,PATCH`	允许执行的 HTTP 方法，逗号分隔
`API_DEBUG_LOGIN_URL`	`/api/login`	登录接口 URL
`API_DEBUG_LOGIN_METHOD`	`POST`	登录接口方法
`API_DEBUG_LOGIN_BODY`	`{"username":"","password":""}`	登录请求体，支持 JSON 字符串或普通字符串
`API_DEBUG_LOGIN_DESCRIPTION`	空	登录工具说明
`API_DEBUG_LOGIN_USER_HEADER`	`new-api-user`	用户 ID 的 Header 名称（从登录响应中提取）

MCP 配置示例

{
  "servers": {
    "apidebug": {
      "command": "npx",
      "args": [
        "@liangshanli/mcp-server-apidebug"
      ],
      "env": {
        "API_DEBUG_BASE_URL": "https://api.example.com",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE,PATCH",
        "API_DEBUG_LOGIN_URL": "/api/user/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"your_username\",\"password\":\"your_password\"}",
        "API_DEBUG_LOGIN_USER_HEADER": "new-api-user",
        "API_DEBUG_LOGIN_DESCRIPTION": "根据环境变量执行登录请求。使用 api_config 接口处理登录成功后的配置。"
      }
    }
  }
}

配置保存路径

默认保存目录规则：

{PROJECT_PATH}/.setting/{TOOL_PREFIX}/api.json

如果 PROJECT_PATH 不设置，则默认 .；如果 TOOL_PREFIX 不设置，则默认 default。

使用示例

设置 Base URL：

{
  "action": "updateBaseUrl",
  "baseUrl": "https://api.example.com"
}

调试接口：

{
  "url": "/api/users",
  "method": "GET",
  "query": {
    "page": 1,
    "limit": 10
  }
}

添加接口后按索引执行：

{
  "action": "addApi",
  "api": {
    "url": "/api/login",
    "method": "POST",
    "body": {
      "username": "admin",
      "password": "123456"
    }
  }
}

{
  "index": 0
}

Available Tools

5 tools

default_api_configB

API configuration management tool for managing API settings, endpoints, and configurations. Examples: get config, set baseUrl to "https://api.example.com", updateHeaders with {"Authorization":"Bearer token"}, search APIs by keyword, list all configured APIs

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform: "get" to retrieve config, "set" to update config, "updateBaseUrl" to update base URL, "updateHeaders" to update headers, "deleteHeader" to delete header, "addApi" to add API endpoint, "search" to search APIs, "list" to list all APIs
`config`	No	API configuration (required for "set" action)
`baseUrl`	No	New base URL (required for "updateBaseUrl" action)
`headers`	No	New headers to add or update (required for "updateHeaders" action)
`headerName`	No	Name of header to delete (required for "deleteHeader" action)
`api`	No	API configuration (required for "addApi" action)
`keyword`	No	Search keyword (required for "search" action)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions actions like 'set' and 'updateHeaders' but does not explain side effects (e.g., whether updates merge or overwrite), persistence, permissions, or error handling. This is insufficient for a mutation tool.

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 a single sentence plus a list of examples, which is concise and front-loaded with purpose. However, the examples could be integrated more seamlessly, and there is minor redundancy (e.g., 'get config' repeats the action enum).

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

Completeness2/5

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

Given the tool's complexity (7 parameters, nested objects, 8 actions) and no output schema, the description lacks completeness. It does not explain return values, behavior per action, or error handling. The schema covers parameters but the description fails to provide overarching guidance.

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?

The input schema has 100% coverage with detailed descriptions for each parameter. The description adds examples but does not provide new semantic meaning beyond what is already in the schema. Baseline 3 is appropriate.

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 it is an 'API configuration management tool for managing API settings, endpoints, and configurations.' The examples list specific actions (get, set, updateBaseUrl, updateHeaders, search, list) which distinguish it from sibling tools like default_api_execute or default_api_debug.

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

Usage Guidelines3/5

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

The description implies usage through examples but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites, such as needing a configured API before using default_api_execute, is provided.

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

default_api_debugA

API debugging tool for directly executing API requests with automatic content-type detection and flexible body format support. Examples: GET /api/users with query params, POST /api/login with JSON body {"username":"admin","password":"123456"}, PUT /api/users/123 with form data "name=John&email=john@example.com"

ParametersJSON Schema

Name	Required	Description
`url`	No	API URL to execute (required)
`method`	No	HTTP method (optional, defaults to GET)
`headers`	No	Additional headers for the request (optional)
`query`	No	Query parameters (optional)
`body`	No	Request body (optional) - Supports multiple formats: JSON object, form data, XML, HTML or plain text
`contentType`	No	Content-Type for request body (optional, will auto-detect if not specified)

TDQS

A3.6/5.0

Behavior3/5

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

Discloses auto content-type detection and flexible body support, but lacks warnings about security, potential side effects (e.g., write operations), or return format. With no annotations, the description carries the burden and is adequate but not thorough.

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 with front-loaded purpose and illustrative examples. No redundant or vague language.

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

Completeness2/5

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

Lacks explanation of return value, error handling, or behavioral constraints (e.g., read-only vs mutating). Given no output schema and no annotations, the description leaves significant gaps for a debug tool.

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% so baseline is 3. The description adds value by showing how parameters combine in real-world examples (e.g., query with GET, body with POST), beyond the schema's individual descriptions.

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 executes API requests with auto-detection and flexible formats. It provides specific examples that illustrate usage with different methods and bodies, distinguishing it from siblings like config or execute.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., default_api_execute). No mention of when not to use or prerequisites.

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

default_api_executeA

Execute API requests by index from configured API list. Examples: execute API at index 0, execute with overrides {"method":"POST","body":{"key":"value"}}

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes	Index of the API to execute from the configured list (required)
`overrides`	No	Optional parameters to override the configured API settings

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose side effects, permissions, and error handling. It mentions overrides but does not explain behavior like authentication requirements, rate limits, or response handling. Minimal disclosure.

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 sentences: first states purpose, second shows concrete examples. No redundant words, front-loaded main action.

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?

Covers purpose, parameters, and usage via example. No output schema present, and description doesn't mention return value, but overall adequate for a simple execution tool with well-documented parameters.

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 clear descriptions for both parameters. The description adds value via an example showing override usage with method and body, which clarifies the nested structure beyond 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?

The description clearly states the tool executes API requests by index from a configured list, with examples showing typical usage. This distinguishes it from sibling tools like default_api_config (configuration) and default_api_debug (debugging).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., default_api_debug for testing, default_api_config for setup). The description simply says 'execute API requests' without specifying scenarios or prerequisites.

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

default_api_helpA

API help tool that provides detailed documentation and examples for all API debugging tools. Use this to understand how to use api_debug, api_login, api_config, and api_execute tools effectively

ParametersJSON Schema

Name	Required	Description	Default
`tool`	No	Specific tool name to get help for (optional: api_debug, api_login, api_config, api_execute)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It correctly indicates the tool is purely informational (providing documentation/examples) with no side effects. While it doesn't explicitly state 'read-only' or 'no mutations', the nature of a help tool is transparent.

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 sentences: the first states the purpose, the second gives usage guidance. No redundant words. Front-loaded and efficient.

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?

For a simple help tool with one optional parameter and no output schema, the description is complete: it explains the tool's role and how to use it. It could briefly mention the format of returned help, but the current description is sufficient for its simplicity.

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% and the schema already provides a clear description and examples for the 'tool' parameter. The tool description mentions the same tool names but does not add new semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

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 that the tool provides 'detailed documentation and examples' for specific sibling tools (api_debug, api_login, api_config, api_execute). It uses a specific verb ('provides') and resource, effectively distinguishing its purpose as a help resource.

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 explicitly tells when to use the tool ('Use this to understand how to use ... tools effectively'), providing clear context. It does not mention when not to use or provide alternative tools, but the context is clear enough for a help tool.

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

default_api_loginA

API login authentication tool that uses environment variables for login credentials. Automatically extracts token from response and updates Authorization headers. Example: Call with optional baseUrl parameter to override default base URL

ParametersJSON Schema

Name	Required	Description	Default
`baseUrl`	No	Base URL for login request (optional, will override config baseUrl)

TDQS

A3.7/5.0

Behavior3/5

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

Discloses automatic token extraction and header update, but no details on side effects or error handling; no annotations provided.

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 efficient sentences front-loading purpose and key behavior with an example.

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

Completeness3/5

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

Lacks specification of required environment variable names, error handling, and success/failure indicators.

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 covers the single parameter well, and description adds context about overriding config baseUrl.

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?

Clearly identifies as an API login authentication tool and distinguishes from sibling tools like default_api_config or default_api_execute.

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

Usage Guidelines2/5

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

Lacks guidance on when to use vs alternatives, no prerequisites or context about needing to call this before other operations.

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.

5 tool updatesv1.0.0Apr 28, 2026
- First observeddefault_api_config
- First observeddefault_api_debug
- First observeddefault_api_execute
- First observeddefault_api_help
- First observeddefault_api_login

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-04-28 05:15 across 5 tools

Disambiguation4/5

Tools have distinct purposes (config, debug, execute, help, login). However, 'debug' and 'execute' both involve executing API requests, differing only in input method, which could cause minor confusion. Descriptions help clarify the distinction.

Naming Consistency5/5

All tools follow the consistent 'default_api_<action>' prefix pattern. The action words (config, debug, execute, help, login) are all clear and follow a predictable structure, enabling easy tool selection.

Tool Count5/5

With 5 tools, the set is well-scoped for an API debugging server. Each tool addresses a core task (configuration, direct execution, index-based execution, authentication, and help). No tools are superfluous.

Completeness4/5

The tool set covers essential API debugging workflows: configuration, authentication, and execution (both direct and by index). Minor gaps exist, such as a tool for viewing execution history or batch operations, but core functionality is solid.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

SelineOAuth
io.github.getseline
MCP server for the Seline Analytics API
Product Management Data Visualization
12
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
javelin-guardrails-mcp-server
io.github.abhijitjavelin
An MCP server that provides Javelin Standalone Guardrails
Security Autonomous Agents Developer Tools
2
Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144

Related MCP Servers

Swagger MCP Server
API Testing Documentation Access
amrsa1
A
license
A
quality
C
maintenance
MCP server that provides tools for exploring and testing APIs through Swagger/OpenAPI documentation.
Updated a year ago (2025-06-30 10:37 UTC)
5
177 npm
12
MIT
Postmancer
API Testing Developer Tools
hijaz
A
license
Not graded
quality
D
maintenance
A standalone MCP server for API testing and management, allowing AI assistants to interact with RESTful APIs through natural language.
Updated a year ago (2025-08-19 00:45 UTC)
8 npm
28
MIT
ls-apis-mcp
Search Open Data
koalyptus
A
license
A
quality
A
maintenance
MCP server for searching and discovering 4,000+ public APIs
Updated 5 days ago (2026-09-11 02:01 UTC)
3
MIT
api-caller-mcp
Developer Tools API Testing
quangngthanh
F
license
Not graded
quality
D
maintenance
MCP server for making API calls with authentication support. Allows configuring multiple API endpoints and performing GET, POST, PUT, DELETE requests, including form data and file uploads.
Updated a year ago (2025-08-17 09:45 UTC)
-