Which integrations are available for this server?

Allows interacting with the GitHub API, enabling operations such as managing repositories, creating issues, and user management via automatically generated tools from GitHub's Swagger specification.

How do I use mcp-api-gateway?

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-api-gateway list all pets from the Petstore API" 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.

mcp-api-gateway

by rflpazini

Overview Schema Related Servers Score Discussions

JavaScript

Remote

api-gateway

Build Docker MCP Toolkit

A universal MCP (Model Context Protocol) server to integrate any API with Claude Desktop using only Docker configurations. Point it at any Swagger/OpenAPI spec and it automatically generates tools that Claude can use.

Available on the Docker MCP Toolkit.

Quick Installation

Using Docker MCP Toolkit (Recommended)

The easiest way to get started is through the Docker MCP Toolkit, which provides one-click setup with Docker Desktop.

Using Docker Hub

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "my-api": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i", "--pull", "always",
        "-e", "API_1_NAME=my-api",
        "-e", "API_1_SWAGGER_URL=https://api.example.com/swagger.json",
        "-e", "API_1_BASE_URL=https://api.example.com/v1",
        "-e", "API_1_HEADER_AUTHORIZATION=Bearer YOUR_TOKEN",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Using npx

API_1_NAME=my-api \
API_1_SWAGGER_URL=https://api.example.com/swagger.json \
API_1_BASE_URL=https://api.example.com/v1 \
npx mcp-api-gateway

Local Build

git clone https://github.com/rflpazini/mcp-api-gateway
cd mcp-api-gateway
docker build -t mcp-api-gateway .

docker run --rm -it \
  -e API_1_NAME=test \
  -e API_1_SWAGGER_URL=https://petstore.swagger.io/v2/swagger.json \
  -e API_1_BASE_URL=https://petstore.swagger.io/v2 \
  mcp-api-gateway

Related MCP server: OpenAPI MCP Server

Configuration

Core Variables

Variable	Description	Required	Default
`API_N_NAME`	Unique API name	Yes	—
`API_N_SWAGGER_URL`	Swagger/OpenAPI spec URL	Yes	—
`API_N_BASE_URL`	API base URL (overrides spec)	No	From spec
`API_N_HEADER_*`	Custom headers (e.g., `API_1_HEADER_AUTHORIZATION`)	No	—
`API_N_HEADERS`	JSON object with multiple headers	No	—

Performance Tuning

For large APIs with hundreds of endpoints, these variables reduce the tool list payload sent to Claude:

Variable	Description	Default
`API_N_TOOL_MODE`	`individual` (one tool per endpoint) or `grouped` (group by resource/tag)	`individual`
`API_N_SCHEMA_MODE`	`full` (complete schemas) or `compact` (strips large enums, moves optional params to descriptions)	`full`
`API_N_PATH_PREFIX`	Comma-separated path prefixes to include (e.g., `/api/v3/users,/api/v3/orders`)	All paths
`API_N_TAGS`	Comma-separated OpenAPI tags to include (e.g., `Users,Orders`)	All tags
`API_N_EXCLUDE_PARAMS`	Comma-separated parameter names to strip from schemas (e.g., `_clientRegion,_platform`)	None

Reliability

Variable	Description	Default
`API_N_TIMEOUT`	Request timeout in milliseconds	`30000`
`API_N_MAX_RETRIES`	Max retry attempts for 429/5xx errors (exponential backoff)	`3`
`MAX_RESPONSE_SIZE`	Max response size in bytes before truncation	`102400`

Performance Results

Tested with a 925-endpoint enterprise API:

Configuration	Tools	Payload	Reduction
No optimization	1093	2,269 KB	—
`SCHEMA_MODE=compact`	1093	633 KB	72%
`TOOL_MODE=grouped`	53	184 KB	92%
`PATH_PREFIX` + `compact`	94	50 KB	98%

Recommendation: Use API_N_TOOL_MODE=grouped for any API with more than 50 endpoints.

Examples

Simple API with Authentication

{
  "mcpServers": {
    "github-api": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "API_1_NAME=github",
        "-e", "API_1_SWAGGER_URL=https://api.github.com/swagger.json",
        "-e", "API_1_HEADER_AUTHORIZATION=token ghp_xxxxxxxxxxxx",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Large API with Grouped Tools

{
  "mcpServers": {
    "enterprise-api": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "API_1_NAME=myapi",
        "-e", "API_1_SWAGGER_URL=https://api.company.com/v3/api-docs",
        "-e", "API_1_BASE_URL=https://api.company.com",
        "-e", "API_1_TOOL_MODE=grouped",
        "-e", "API_1_SCHEMA_MODE=compact",
        "-e", "API_1_HEADER_AUTHORIZATION=Bearer your_token",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Multiple APIs

Configure multiple APIs by incrementing the index (API_1_*, API_2_*, API_3_*):

{
  "mcpServers": {
    "company-apis": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "API_1_NAME=users",
        "-e", "API_1_SWAGGER_URL=https://api.company.com/users/swagger.json",
        "-e", "API_1_HEADER_X_API_KEY=users_key_123",
        "-e", "API_2_NAME=products",
        "-e", "API_2_SWAGGER_URL=https://api.company.com/products/openapi.yaml",
        "-e", "API_2_HEADER_AUTHORIZATION=Bearer products_token",
        "-e", "API_3_NAME=orders",
        "-e", "API_3_SWAGGER_URL=https://api.company.com/orders/spec.json",
        "-e", "API_3_HEADERS={\"Authorization\":\"Bearer token\",\"X-Tenant\":\"company123\"}",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Filtered Endpoints

Only load specific parts of a large API:

{
  "mcpServers": {
    "filtered-api": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "API_1_NAME=myapi",
        "-e", "API_1_SWAGGER_URL=https://api.company.com/swagger.json",
        "-e", "API_1_PATH_PREFIX=/api/v3/users,/api/v3/orders",
        "-e", "API_1_SCHEMA_MODE=compact",
        "-e", "API_1_EXCLUDE_PARAMS=_clientRegion,_platform",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Local Swagger File

Mount a local Swagger file into the container:

{
  "mcpServers": {
    "local-api": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "/path/to/swagger.yaml:/swagger.yaml",
        "-e", "API_1_NAME=local-api",
        "-e", "API_1_SWAGGER_URL=file:///swagger.yaml",
        "-e", "API_1_BASE_URL=http://host.docker.internal:3000",
        "rflpazini/mcp-api-gateway:latest"
      ]
    }
  }
}

Features

The server automatically persists cookies across requests. When an API returns Set-Cookie headers (e.g., after a login call), those cookies are stored and replayed on subsequent requests to the same API. No configuration needed.

Grouped Tools

When API_N_TOOL_MODE=grouped is set, endpoints are automatically grouped into resource tools:

Tagged APIs: Groups by OpenAPI tag (e.g., all /users endpoints become one myapi_Users tool)
Untagged APIs: Infers groups from path structure (e.g., /pets, /store)
Each grouped tool lists available operations in its description, and the LLM selects which one to call via an operation parameter

Health Check

A built-in check_api_health tool lets Claude verify API connectivity. It pings each configured API's base URL and reports reachability, HTTP status, and response time.

Retry with Backoff

Failed requests (429, 500, 502, 503, 504) are automatically retried with exponential backoff. The server honors Retry-After headers from rate-limited APIs.

Using in Claude

Available Commands

View available APIs: "What APIs are configured?"
Explore endpoints: "How do I create a user?" / "What parameters do I need?"
Execute operations: "Create a user named John with email john@email.com"
Check health: "Is the API reachable?"

Security

Best Practices

Never commit tokens: Use environment variables or secrets
Use limited scope tokens: Only necessary permissions
Rotate tokens regularly: Update your tokens periodically
Always use HTTPS: Ensure your APIs use HTTPS

Docker Image Security

The production image uses Google Distroless as the runtime base:

No shell, no package manager, no OS utilities
Runs as non-root user
0 known vulnerabilities
Node.js 24 LTS (supported until April 2028)

Troubleshooting

API not showing up

Check if the Swagger URL is accessible from the container
Confirm environment variables are correct (especially API_N_SWAGGER_URL)
Check logs: docker logs <container_id>

Authentication error

Verify token is correct
Confirm header format (Bearer, Basic, etc)
For cookie-based auth: ensure the login endpoint is called first

Too many tools / slow startup

Use API_N_TOOL_MODE=grouped to reduce tool count
Use API_N_PATH_PREFIX or API_N_TAGS to filter endpoints
Use API_N_SCHEMA_MODE=compact to reduce schema size

Request timeouts

Increase timeout: API_N_TIMEOUT=60000
Check API latency directly

Contributing

PRs are welcome! Some ideas:

OAuth authentication support
Smart response caching
WebSocket support
Web configuration interface
Metrics and observability

License

MIT License - see LICENSE file for details.

Available Tools

3 tools

check_api_healthB

Check connectivity and health of configured APIs

ParametersJSON Schema

Name	Required	Description	Default
`api_name`	No	Name of the API to check (optional, checks all if not provided)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral transparency. It states the tool 'checks connectivity and health,' which implies a read operation, but it does not clarify whether this makes network calls (which could be slow or fail), whether it modifies state, or what happens if an API is unreachable. Given the absence of safety hints, more transparency is needed.

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 that directly states the tool's purpose. It is concise and front-loaded, with no unnecessary words. However, it could benefit from additional clarity on what 'health' entails or usage context. Still, it earns a 4 for efficiency.

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?

The tool has minimal complexity (1 optional parameter, no output schema, no nested objects). The description covers its primary use case. However, it does not specify what the tool returns (e.g., a boolean, status codes, or detailed health info) or any error conditions. For a tool with no output schema, slightly more context about expected output would improve completeness.

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 already provides a clear description for the sole parameter (api_name), indicating it is optional and checks all APIs if omitted. The tool description does not add additional meaning beyond the schema, so parameter semantics are adequately covered by the schema. Score of 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 uses a specific verb ('check') and clearly identifies the resource ('connectivity and health of configured APIs'). It distinguishes from siblings: get_api_info likely retrieves configuration details, and execute_api runs operations, while this tool assesses health.

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?

The description provides no guidance on when to use this tool over its siblings. It does not specify prerequisites, exclusions, or context. For example, it doesn't mention that this tool is for connectivity checks only, while get_api_info might provide more detailed API metadata. This lack of context reduces clarity.

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

execute_apiC

Execute any API endpoint with custom parameters

ParametersJSON Schema

Name	Required	Description
`data`	No	Request body data
`path`	Yes	API endpoint path
`method`	Yes
`params`	No	Query parameters
`headers`	No	Additional headers
`api_name`	Yes	Name of the API

TDQS

C2.7/5.0

Behavior2/5

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

Without annotations, the description carries full burden. It only says 'execute any API endpoint' without disclosing authentication, rate limits, error handling, side effects, or response format. Not enough for a generic execution tool.

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

Conciseness2/5

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

The one-sentence description is too brief for a tool with 6 parameters and no annotations. It lacks structure, missing key information like usage context and return behavior.

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 no output schema, no annotations, and 6 parameters (3 required), the description is insufficient. It fails to explain overall behavior, authentication, error handling, or response, leaving agents underinformed.

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 description coverage is 83%, so most parameters are documented. The description adds 'custom parameters' but no details beyond what's in the schema. Adequate but not enhanced.

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

Purpose4/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 endpoints with custom parameters. The verb 'execute' and resource 'API endpoint' are specific, but no differentiation from sibling tools like get_api_info or check_api_health is provided.

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. The description does not mention prerequisites, scenarios, or distinguish from get_api_info or check_api_health.

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

get_api_infoA

Get information about available APIs and their endpoints

ParametersJSON Schema

Name	Required	Description	Default
`api_name`	No	Name of the API (optional, shows all if not provided)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations present; description implies a read operation but does not disclose potential limitations or side effects. Adequate but minimal.

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?

Single sentence, highly concise, and front-loaded with the core purpose.

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?

Given the tool's simplicity, the description is sufficient. However, no output schema or extra context about response format is provided.

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% with a clear parameter description. The tool description does not add further semantic detail 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 retrieves information about APIs and endpoints. It distinguishes from sibling tools that perform health checks or execute APIs.

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?

No explicit guidance on when to use versus alternatives, but the optional api_name parameter implies usage for querying specific or all APIs. Sibling names provide context.

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: get_api_info retrieves metadata, check_api_health tests connectivity, and execute_api performs API calls. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_api_info, check_api_health, execute_api) using snake_case. The naming is uniform and predictable.

Tool Count5/5

Three tools is an appropriate scope for an API gateway server, covering information retrieval, health checking, and execution without being excessive or insufficient.

Completeness4/5

The tools cover the core functions of an API gateway: discovery, health, and execution. Minor gaps like authentication management or rate limiting are missing but not critical for basic use.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
Swagger MCP
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

Fastn Serverofficial
Developer Tools App Automation Code Execution
fastn-ai
A
license
Not graded
quality
D
maintenance
An MCP server that enables dynamic tool registration and execution based on API definitions, providing seamless integration with services like Claude.ai and Cursor.ai.
Updated 3 months ago (2026-06-07 10:13 UTC)
23
MIT
OpenAPI MCP Server
API Testing Developer Tools
luciVuc
A
license
Not graded
quality
C
maintenance
A generic MCP server that dynamically converts OpenAPI-defined REST APIs into tools for LLMs like Claude. It supports multiple authentication methods and transport protocols, enabling seamless interaction with any OpenAPI-compliant API.
Updated a month ago (2026-07-21 01:58 UTC)
21
MIT
OpenAPI to MCP Server
Developer Tools Documentation Access
Afstkla
A
license
Not graded
quality
D
maintenance
Converts any OpenAPI/Swagger spec into an MCP server, exposing REST API endpoints as tools for Claude.
Updated 5 months ago (2026-04-16 01:07 UTC)
MIT
FastMCP Gateway
Developer Tools AI & Machine Learning
4human-ai
F
license
Not graded
quality
D
maintenance
Automatically converts OpenAPI specifications into MCP servers, allowing tools like Claude Desktop to interact with your REST APIs through a standard protocol.
Updated 10 months ago (2025-11-04 21:24 UTC)

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/rflpazini/mcp-api-gateway'

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

api-gateway

Quick Installation

Using Docker MCP Toolkit (Recommended)

Using Docker Hub

Using npx

Local Build

Configuration

Core Variables

Performance Tuning

Reliability

Performance Results

Examples

Simple API with Authentication

Large API with Grouped Tools

Multiple APIs

Filtered Endpoints

Local Swagger File

Features

Cookie-Based Authentication

Grouped Tools

Health Check

Retry with Backoff

Using in Claude

Available Commands

Security

Best Practices

Docker Image Security

Troubleshooting

API not showing up

Authentication error

Too many tools / slow startup

Request timeouts

Contributing

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Fastn Serverofficial

OpenAPI MCP Server

OpenAPI to MCP Server

FastMCP Gateway

Latest Blog Posts

MCP directory API