A tool&lib that can automatically convert OpenAPI documents into Higress remote MCP server configurations.
A tool to convert OpenAPI specifications to MCP (Model Context Protocol) server configurations.
go install github.com/higress-group/openapi-to-mcpserver/cmd/openapi-to-mcp@latest
openapi-to-mcp --input path/to/openapi.json --output path/to/mcp-server.yaml
--input
: Path to the OpenAPI specification file (JSON or YAML) (required)--output
: Path to the output MCP configuration file (YAML) (required)--server-name
: Name of the MCP server (default: "openapi-server")--tool-prefix
: Prefix for tool names (default: "")--format
: Output format (yaml or json) (default: "yaml")--validate
: Validate the OpenAPI specification (default: false)--template
: Path to a template file to patch the output (default: "")openapi-to-mcp --input petstore.json --output petstore-mcp.yaml --server-name petstore
This tool can be used to convert an OpenAPI specification to a Higress REST-to-MCP configuration. Here's a complete example:
{
"openapi": "3.0.0",
"info": {
"version": "1.0.0",
"title": "Swagger Petstore",
"description": "A sample API that uses a petstore as an example to demonstrate features in the OpenAPI 3.0 specification"
},
"servers": [
{
"url": "http://petstore.swagger.io/v1"
}
],
"paths": {
"/pets": {
"get": {
"summary": "List all pets",
"operationId": "listPets",
"parameters": [
{
"name": "limit",
"in": "query",
"description": "How many items to return at one time (max 100)",
"required": false,
"schema": {
"type": "integer",
"format": "int32"
}
}
],
"responses": {
"200": {
"description": "A paged array of pets",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"pets": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"description": "Unique identifier for the pet"
},
"name": {
"type": "string",
"description": "Name of the pet"
},
"tag": {
"type": "string",
"description": "Tag of the pet"
}
}
}
},
"nextPage": {
"type": "string",
"description": "URL to get the next page of pets"
}
}
}
}
}
}
}
},
"post": {
"summary": "Create a pet",
"operationId": "createPets",
"requestBody": {
"description": "Pet to add to the store",
"required": true,
"content": {
"application/json": {
"schema": {
"type": "object",
"required": ["name"],
"properties": {
"name": {
"type": "string",
"description": "Name of the pet"
},
"tag": {
"type": "string",
"description": "Tag of the pet"
}
}
}
}
}
},
"responses": {
"201": {
"description": "Null response"
}
}
}
},
"/pets/{petId}": {
"get": {
"summary": "Info for a specific pet",
"operationId": "showPetById",
"parameters": [
{
"name": "petId",
"in": "path",
"required": true,
"description": "The id of the pet to retrieve",
"schema": {
"type": "string"
}
}
],
"responses": {
"200": {
"description": "Expected response to a valid request",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"id": {
"type": "integer",
"description": "Unique identifier for the pet"
},
"name": {
"type": "string",
"description": "Name of the pet"
},
"tag": {
"type": "string",
"description": "Tag of the pet"
}
}
}
}
}
}
}
}
}
}
}
openapi-to-mcp --input petstore.json --output petstore-mcp.yaml --server-name petstore
server:
name: petstore
tools:
- name: showPetById
description: Info for a specific pet
args:
- name: petId
description: The id of the pet to retrieve
type: string
required: true
position: path
requestTemplate:
url: /pets/{petId}
method: GET
responseTemplate:
prependBody: |
# API Response Information
Below is the response from an API call. To help you understand the data, I've provided:
1. A detailed description of all fields in the response structure
2. The complete API response
## Response Structure
> Content-Type: application/json
- **id**: Unique identifier for the pet (Type: integer)
- **name**: Name of the pet (Type: string)
- **tag**: Tag of the pet (Type: string)
## Original Response
- name: createPets
description: Create a pet
args:
- name: name
description: Name of the pet
type: string
required: true
position: body
- name: tag
description: Tag of the pet
type: string
position: body
requestTemplate:
url: /pets
method: POST
headers:
- key: Content-Type
value: application/json
responseTemplate: {}
- name: listPets
description: List all pets
args:
- name: limit
description: How many items to return at one time (max 100)
type: integer
position: query
requestTemplate:
url: /pets
method: GET
responseTemplate:
prependBody: |
# API Response Information
Below is the response from an API call. To help you understand the data, I've provided:
1. A detailed description of all fields in the response structure
2. The complete API response
## Response Structure
> Content-Type: application/json
- **pets**: (Type: array)
- **pets[].id**: Unique identifier for the pet (Type: integer)
- **pets[].name**: Name of the pet (Type: string)
- **pets[].tag**: Tag of the pet (Type: string)
- **nextPage**: URL to get the next page of pets (Type: string)
## Original Response
Note how the tool automatically sets the position
field for each parameter based on its location in the OpenAPI specification:
petId
parameter is set to position: path
because it's defined as in: path
in the OpenAPI speclimit
parameter is set to position: query
because it's defined as in: query
in the OpenAPI specname
and tag
) are set to position: body
The MCP server will automatically handle these parameters in the correct location when making API requests.
For more information about using this configuration with Higress REST-to-MCP, please refer to the Higress REST-to-MCP documentation.
You can use the --template
flag to provide a YAML file that will be used to patch the generated configuration. This is useful for adding common headers, authentication, or other customizations to all tools in the configuration.
Example template file:
server:
config:
apiKey: ""
tools:
requestTemplate:
headers:
- key: Authorization
value: "APPCODE {{.config.apiKey}}"
- key: X-Ca-Nonce
value: "{{uuidv4}}"
When applied, this template will:
apiKey
field to the server configUsage:
openapi-to-mcp --input api-spec.json --output mcp-server.yaml --server-name my-server --template template.yaml
The template values like {{.config.apiKey}}
or "{{uuidv4}}"
are not processed by the tool but are preserved in the output for use by the MCP server at runtime.
The tool now supports the conversion of security schemes defined in your OpenAPI specification.
Security schemes defined in the components.securitySchemes
section of your OpenAPI document are converted into a list under server.securitySchemes
in the generated MCP configuration.
Example OpenAPI Snippet (components.securitySchemes
):
{
"components": {
"securitySchemes": {
"BasicAuth": {
"type": "http",
"scheme": "basic"
},
"ApiKeyAuth": {
"type": "apiKey",
"in": "header",
"name": "X-API-KEY"
}
}
}
}
Corresponding MCP YAML Output (server.securitySchemes
):
server:
name: your-server-name
securitySchemes:
- id: ApiKeyAuth # Note: Schemes are sorted by ID in the output
type: apiKey
in: header
name: X-API-KEY
- id: BasicAuth
type: http
scheme: basic
# ... other server config ...
The defaultCredential
field within a security scheme is an MCP-specific extension and is not derived from the OpenAPI specification. You can set it using the --template
feature if needed.
Security requirements defined at the operation level in your OpenAPI document (using the security
keyword) are converted into a list under requestTemplate.security
for the corresponding tool. Each entry in this list will reference the id
of a security scheme defined in server.securitySchemes
.
Example OpenAPI Snippet (Operation with security):
{
"paths": {
"/protected_resource": {
"get": {
"summary": "Access a protected resource",
"operationId": "getProtectedResource",
"security": [
{
"ApiKeyAuth": []
}
],
"responses": {
"200": { "description": "Success" }
}
}
}
}
}
Corresponding MCP YAML Output (Tool's requestTemplate.security
):
tools:
- name: getProtectedResource
description: Access a protected resource
# ... args ...
requestTemplate:
url: /protected_resource # Actual URL depends on your server config in OpenAPI
method: GET
security:
- id: ApiKeyAuth
# ... responseTemplate ...
If an operation specifies multiple security schemes (e.g., BearerAuth OR ApiKeyAuth), all will be listed under requestTemplate.security
. The MCP server runtime would then handle the logic of which scheme to use.
You can use the --template
option to:
server.securitySchemes
.defaultCredential
).security
requirements for all tools via the tools.requestTemplate.security
path in your template file.
If the template defines server.securitySchemes
or tools.requestTemplate.security
, these will replace any schemes/requirements derived from the OpenAPI specification.{ "mcpServers": { "openapi-to-mcpserver": { "command": "openapi-to-mcp", "args": [ "--input", "path/to/openapi.json", "--output", "path/to/mcp-server.yaml" ] } } }
Related projects feature coming soon
Will recommend related projects based on sub-categories