Skip to main content
Glama
gurvinder-dhillon

Unbundle OpenAPI Specs MCP

Desvincular el servidor MCP de OpenAPI

insignia de herrería

Este proyecto proporciona un servidor de Protocolo de Contexto de Modelo (MCP) con herramientas para dividir los archivos de especificación de OpenAPI en varios archivos o extraer puntos finales específicos en un nuevo archivo. Permite a un cliente MCP (como un asistente de IA) manipular las especificaciones de OpenAPI mediante programación.

Prerrequisitos

  • Node.js (versión LTS recomendada, por ejemplo, v18 o v20)

  • npm (viene con Node.js)

Related MCP server: openapi-mcp-proxy

Uso

Instalación mediante herrería

Para instalar Unbundle OpenAPI MCP Server para Claude Desktop automáticamente a través de Smithery :

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

La forma más sencilla de utilizar este servidor es a través de npx , lo que garantiza que siempre esté utilizando la última versión sin necesidad de una instalación global.

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

Alternativamente, puedes instalarlo globalmente (generalmente no se recomienda):

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

El servidor se iniciará y escuchará las solicitudes MCP en la entrada/salida estándar (stdio).

Configuración del cliente

Para usar este servidor con clientes MCP como VS Code, Cline, Cursor o Claude Desktop, agregue su configuración al archivo de configuración correspondiente. El método recomendado es npx .

VS Code / Cline / Cursor

Agregue lo siguiente a su User settings.json (accesible a través de Ctrl+Shift+P > Preferences: Open User Settings (JSON) ) o a un archivo .vscode/mcp.json en la raíz de su espacio de trabajo.

// 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
}

Escritorio de Claude

Agregue lo siguiente a su archivo claude_desktop_config.json .

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

Después de agregar la configuración, reinicie su aplicación cliente para que los cambios surtan efecto.

Herramientas MCP proporcionadas

split_openapi

Descripción: Ejecuta el comando redocly split para descomponer un archivo de definición de OpenAPI en varios archivos más pequeños según su estructura.

Argumentos:

  • apiPath (cadena, obligatoria): la ruta absoluta al archivo de definición de OpenAPI de entrada (por ejemplo, openapi.yaml ).

  • outputDir (cadena, obligatoria): La ruta absoluta al directorio donde se guardarán los archivos de salida divididos. Este directorio se creará si no existe.

Devoluciones:

  • En caso de éxito: un mensaje de texto que contiene la salida estándar del comando redocly split (generalmente un mensaje de confirmación).

  • En caso de error: un mensaje de error que contiene los detalles del error estándar o de la excepción de la ejecución del comando, marcado con isError: true .

Ejemplo de uso (solicitud MCP conceptual):

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

extract_openapi_endpoints

Descripción: Extrae puntos de conexión específicos de un archivo de definición OpenAPI grande y crea un nuevo archivo OpenAPI más pequeño que contiene únicamente esos puntos de conexión y sus componentes referenciados. Esto se logra dividiendo el archivo original, modificando la estructura para conservar únicamente las rutas especificadas y, a continuación, empaquetando el resultado.

Argumentos:

  • inputApiPath (cadena, obligatoria): la ruta absoluta al archivo de definición de OpenAPI de entrada grande.

  • endpointsToKeep (matriz de cadenas, obligatorio): Una lista de las rutas exactas de los endpoints (cadenas) que se incluirán en la salida final (p. ej., ["/api", "/api/projects/{id}{.format}"] ). Se ignorarán las rutas que no se encuentren en la especificación original.

  • outputApiPath (cadena, obligatoria): La ruta absoluta donde se guardará el archivo OpenAPI final, más pequeño y empaquetado. El directorio se creará si no existe.

Devoluciones:

  • En caso de éxito: un mensaje de texto que indica la ruta del archivo creado y la salida estándar del comando redocly bundle .

  • En caso de error: un mensaje de error que contiene detalles sobre el paso que falló (dividir, modificar, agrupar), marcado con isError: true .

Ejemplo de uso (solicitud MCP conceptual):

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

Nota: Este servidor utiliza internamente npx @redocly/cli@latest para ejecutar los comandos subyacentes split y bundle . Es posible que se requiera una conexión a internet para que npx obtenga @redocly/cli si no está almacenado en caché. Los archivos temporales se crean durante el proceso extract_openapi_endpoints y se limpian automáticamente.

Desarrollo

Si desea contribuir o ejecutar el servidor desde la fuente:

  1. Clonar: Clonar este repositorio.

  2. Navegar: cd unbundle_openapi_mcp

  3. Instalar dependencias: npm install

  4. Compilación: npm run build (compila TypeScript en dist/ )

  5. Ejecutar: npm start (inicia el servidor usando el código compilado en 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