Skip to main content
Glama
gurvinder-dhillon

Unbundle OpenAPI Specs MCP

OpenAPI MCP サーバーのバンドル解除

鍛冶屋のバッジ

このプロジェクトは、Model Context Protocol(MCP)サーバーに、OpenAPI仕様ファイルを複数のファイルに分割したり、特定のエンドポイントを新しいファイルに抽出したりするためのツールを提供します。これにより、MCPクライアント(AIアシスタントなど)がOpenAPI仕様をプログラム的に操作できるようになります。

前提条件

  • Node.js (LTS バージョンを推奨、例: v18 または v20)

  • npm (Node.js に付属)

Related MCP server: openapi-mcp-proxy

使用法

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Unbundle OpenAPI MCP Server を自動的にインストールするには:

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

このサーバーを使用する最も簡単な方法はnpxを使用することです。これにより、グローバル インストールを必要とせずに常に最新バージョンを使用できます。

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

あるいは、グローバルにインストールすることもできます (通常は推奨されません)。

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

サーバーが起動し、標準入出力 (stdio) で MCP 要求をリッスンします。

クライアント構成

このサーバーをVS Code、Cline、Cursor、Claude DesktopなどのMCPクライアントで使用するには、それぞれの設定ファイルに構成を追加してください。推奨される方法はnpxを使用することです。

VS Code / クライン / カーソル

次のコードをユーザーsettings.json json ( Ctrl+Shift+P > Preferences: Open User Settings (JSON)アクセス可能) またはワークスペース ルートの.vscode/mcp.jsonファイルに追加します。

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

構成を追加した後、変更を有効にするためにクライアント アプリケーションを再起動します。

提供されるMCPツール

split_openapi

説明: redocly splitコマンドを実行し、OpenAPI 定義ファイルをその構造に基づいて複数の小さなファイルに分割します。

引数:

  • apiPath (文字列、必須): 入力 OpenAPI 定義ファイルへの絶対パス (例: openapi.yaml )。

  • outputDir (文字列、必須): 分割出力ファイルを保存するディレクトリへの絶対パス。このディレクトリが存在しない場合は作成されます。

戻り値:

  • 成功した場合: redocly splitコマンドからの標準出力を含むテキスト メッセージ (通常は確認メッセージ)。

  • 失敗した場合: コマンド実行からの標準エラーまたは例外の詳細を含むエラー メッセージ。isError isError: trueでマークされます。

使用例(概念的なMCPリクエスト):

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

extract_openapi_endpoints

**説明:**大規模なOpenAPI定義ファイルから特定のエンドポイントを抽出し、それらのエンドポイントと参照コンポーネントのみを含む、新しい小さなOpenAPIファイルを作成します。これは、元のファイルを分割し、指定されたパスのみを保持するように構造を変更し、結果をバンドルすることで実現されます。

引数:

  • inputApiPath (文字列、必須): 大規模な入力 OpenAPI 定義ファイルへの絶対パス。

  • endpointsToKeep (文字列の配列、必須):最終出力に含めるエンドポイントパス(文字列)のリスト(例: ["/api", "/api/projects/{id}{.format}"] )。元の仕様に見つからないパスは無視されます。

  • outputApiPath (文字列、必須): 最終的な、より小さなバンドルされたOpenAPIファイルを保存する絶対パス。ディレクトリが存在しない場合は作成されます。

戻り値:

  • 成功した場合: 作成されたファイルのパスとredocly bundleコマンドからの標準出力を示すテキスト メッセージ。

  • 失敗時: 失敗したステップ (分割、変更、バンドル) の詳細を含むエラー メッセージ。isError isError: trueでマークされます。

使用例(概念的なMCPリクエスト):

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

**注:**このサーバーは、内部的にnpx @redocly/cli@latestを使用して、基盤となるsplitbundleコマンドを実行します。キャッシュされていない場合、 npx @redocly/cli extract_openapi_endpoints取得するにはインターネット接続が必要になる場合があります。extract_openapi_endpoints プロセス中に一時ファイルが作成され、自動的にクリーンアップされます。

発達

ソースから貢献したりサーバーを実行したりしたい場合は、次の手順に従ってください。

  1. **クローン:**このリポジトリをクローンします。

  2. ナビゲート: cd unbundle_openapi_mcp

  3. 依存関係のインストール: npm install

  4. ビルド: npm run build (TypeScript をdist/にコンパイルします)

  5. 実行: npm start ( 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