Skip to main content
Glama
gurvinder-dhillon

Unbundle OpenAPI Specs MCP

Unbundle OpenAPI MCP Server

This project provides a Model Context Protocol (MCP) server with tools to split OpenAPI specification files into multiple files or extract specific endpoints into a new file. It allows an MCP client (like an AI assistant) to manipulate OpenAPI specifications programmatically.

Prerequisites

  • Node.js (LTS version recommended, e.g., v18 or v20)

  • npm (comes with Node.js)

Related MCP server: openapi-mcp-proxy

Usage

Installing via Smithery

To install Unbundle OpenAPI MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @auto-browse/unbundle_openapi_mcp --client claude

The easiest way to use this server is via npx, which ensures you are always using the latest version without needing a global installation.

npx @auto-browse/unbundle-openapi-mcp@latest

Alternatively, you can install it globally (not generally recommended):

npm install -g @auto-browse/unbundle-openapi-mcp
# Then run using: unbundle-openapi-mcp

The server will start and listen for MCP requests on standard input/output (stdio).

Client Configuration

To use this server with MCP clients like VS Code, Cline, Cursor, or Claude Desktop, add its configuration to the respective settings file. The recommended approach uses npx.

VS Code / Cline / Cursor

Add the following to your User settings.json (accessible via Ctrl+Shift+P > Preferences: Open User Settings (JSON)) or to a .vscode/mcp.json file in your workspace root.

// In settings.json:
"mcp.servers": {
  "unbundle_openapi": { // You can choose any key name
    "command": "npx",
    "args": [
      "@auto-browse/unbundle-openapi-mcp@latest"
    ]
  }
  // ... other servers can be added here
},

// Or in .vscode/mcp.json (omit the top-level "mcp.servers"):
{
  "unbundle_openapi": { // You can choose any key name
    "command": "npx",
    "args": [
      "@auto-browse/unbundle-openapi-mcp@latest"
    ]
  }
  // ... other servers can be added here
}

Claude Desktop

Add the following to your claude_desktop_config.json file.

{
	"mcpServers": {
		"unbundle_openapi": {
			// You can choose any key name
			"command": "npx",
			"args": ["@auto-browse/unbundle-openapi-mcp@latest"]
		}
		// ... other servers can be added here
	}
}

After adding the configuration, restart your client application for the changes to take effect.

MCP Tools Provided

split_openapi

Description: Executes the redocly split command to unbundle an OpenAPI definition file into multiple smaller files based on its structure.

Arguments:

  • apiPath (string, required): The absolute path to the input OpenAPI definition file (e.g., openapi.yaml).

  • outputDir (string, required): The absolute path to the directory where the split output files should be saved. This directory will be created if it doesn't exist.

Returns:

  • On success: A text message containing the standard output from the redocly split command (usually a confirmation message).

  • On failure: An error message containing the standard error or exception details from the command execution, marked with isError: true.

Example Usage (Conceptual MCP Request):

{
	"tool_name": "split_openapi",
	"arguments": {
		"apiPath": "/path/to/your/openapi.yaml",
		"outputDir": "/path/to/output/directory"
	}
}

extract_openapi_endpoints

Description: Extracts specific endpoints from a large OpenAPI definition file and creates a new, smaller OpenAPI file containing only those endpoints and their referenced components. It achieves this by splitting the original file, modifying the structure to keep only specified paths, and then bundling the result.

Arguments:

  • inputApiPath (string, required): The absolute path to the large input OpenAPI definition file.

  • endpointsToKeep (array of strings, required): A list of the exact endpoint paths (strings) to include in the final output (e.g., ["/api", "/api/projects/{id}{.format}"]). Paths not found in the original spec will be ignored.

  • outputApiPath (string, required): The absolute path where the final, smaller bundled OpenAPI file should be saved. The directory will be created if it doesn't exist.

Returns:

  • On success: A text message indicating the path of the created file and the standard output from the redocly bundle command.

  • On failure: An error message containing details about the step that failed (split, modify, bundle), marked with isError: true.

Example Usage (Conceptual MCP Request):

{
	"tool_name": "extract_openapi_endpoints",
	"arguments": {
		"inputApiPath": "/path/to/large-openapi.yaml",
		"endpointsToKeep": ["/users", "/users/{userId}/profile"],
		"outputApiPath": "/path/to/extracted-openapi.yaml"
	}
}

Note: This server uses npx @redocly/cli@latest internally to execute the underlying split and bundle commands. An internet connection might be required for npx to fetch @redocly/cli if it's not cached. Temporary files are created during the extract_openapi_endpoints process and automatically cleaned up.

Development

If you want to contribute or run the server from source :

  1. Clone: Clone this repository.

  2. Navigate: cd unbundle_openapi_mcp

  3. Install Dependencies: npm install

  4. Build: npm run build (compiles TypeScript to dist/)

  5. Run: npm start (starts the server using the compiled code in dist/)

Available Tools

2 tools
extract_openapi_endpointsD
ParametersJSON Schema
NameRequiredDescriptionDefault
endpointsToKeepYesList of exact endpoint paths to keep (e.g., ['/users', '/users/{id}']).
inputApiPathYesAbsolute path to the large input OpenAPI definition file.
outputApiPathYesAbsolute path where the final, smaller bundled OpenAPI file should be saved.

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.

split_openapiD
ParametersJSON Schema
NameRequiredDescriptionDefault
apiPathYesAbsolute path to the input OpenAPI definition file.
outputDirYesAbsolute path to the directory for split output files.

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.

  1. 2 tool updatesv1.0.0
    • First observedextract_openapi_endpoints
    • First observedsplit_openapi

TDQS

D1.7/5.0
Disambiguation4/5

The two tools have clearly distinct purposes: 'extract_openapi_endpoints' likely retrieves endpoints from an OpenAPI spec, while 'split_openapi' probably divides a spec into parts. There is no overlap in functionality, though the lack of descriptions leaves some room for minor uncertainty about exact differences.

Naming Consistency5/5

Both tools follow a consistent snake_case naming pattern with a verb_noun structure ('extract_endpoints', 'split_openapi'). The naming is predictable and aligned, making it easy to understand the action and target for each tool.

Tool Count2/5

With only two tools, the server feels thin for its purpose of unbundling OpenAPI specs. This limited set may not cover essential operations like validation, merging, or transformation, leaving obvious gaps in functionality for a domain that typically requires more comprehensive handling.

Completeness2/5

The tool surface is severely incomplete for unbundling OpenAPI specs. Missing are tools for tasks such as validating specs, merging split parts, converting formats, or handling errors. Agents will likely encounter dead ends when trying to perform common workflows in this domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server providing token-efficient access to OpenAPI/Swagger specs via MCP Resources for client-side exploration.
    234
    76
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Parses Swagger 2.0 and OpenAPI 3.x specifications, exposing API endpoints, schemas, and authentication through MCP tools with local caching to reduce token usage.
    11
    27
    1
    MIT

Latest Blog Posts

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/gurvinder-dhillon/unbundle_openapi_mcp'

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