Skip to main content
Glama
deenesjakoruzh
Vizioz

Swagger MCP

by Vizioz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

スワガーMCP

Swagger 仕様に接続し、AI がそのサービス用の MCP サーバーを生成するために必要なすべてのモデルを構築できるように支援する MCP サーバー。

特徴

  • Swagger 仕様をダウンロードし、ローカルに保存して、より速く参照できるようにします。

  • すべてのエンドポイントとそのHTTPメソッドと説明のリストを返します。

  • すべてのモデルのリストを返します

  • モデルを返す

  • エンドポイントに接続するためのサービスを返します

  • MCP関数定義を返します

  • 完全なスキーマ情報を含む完全なMCPツール定義を生成します

  • ツールの説明にAI固有の指示が含まれています

Related MCP server: Mcp-Swagger-Server

前提条件

  • Node.js (v14以上)

  • npmまたはyarn

インストール

  1. リポジトリをクローンします。

git clone https://github.com/readingdancer/swagger-mcp.git
cd swagger-mcp

  1. 依存関係をインストールします:

npm install

  1. .env.exampleファイルに基づいて.envファイルを作成します。

cp .env.example .env

  1. .envファイルを更新します。

構成

アプリケーションを構成するには、 .envファイルを編集します。

  • PORT : サーバーが実行されるポート (デフォルト: 3000)

  • NODE_ENV : 環境（開発、本番、テスト）

  • LOG_LEVEL : ログレベル（情報、エラー、デバッグ）

使用法

アプリケーションの構築

アプリケーションをビルドします。

npm run build

これにより、TypeScriptコードがコンパイルされ、MCPサーバーとして使用できるようになります。

MCP サーバーとして実行

Cursor や他のアプリケーションとの統合のために MCP サーバーとして実行するには:

node build/index.js

MCPインスペクターの使用

デバッグのために MCP インスペクタを実行するには:

npm run inspector

カーソルに追加

この MCP サーバーをカーソルに追加するには:

  1. カーソル設定 > 機能 > MCP を開く

  2. 「+新しいMCPサーバーを追加」をクリックします

  3. サーバーの名前を入力します（例：「Swagger MCP」）

  4. トランスポートタイプとして「stdio」を選択します

  5. サーバーを実行するコマンドを入力します: node path/to/swagger-mcp/build/index.js必要に応じて、上記のようにコマンドライン引数を追加します。

  6. 「追加」をクリック

Swagger MCP ツールが Composer の Cursor Agent で使用できるようになります。

利用可能なSwagger MCPツール

MCP サーバーを通じて次のツールを利用できます。

  • getSwaggerDefinition : URLからSwagger定義をダウンロードする

  • listEndpoints : Swagger定義からすべてのエンドポイントを一覧表示します

  • listEndpointModels : 特定のエンドポイントで使用されるすべてのモデルを一覧表示します

  • generateModelCode : モデルのTypeScriptコードを生成する

  • generateEndpointToolCode : MCP ツール定義の TypeScript コードを生成します。

利用可能なSwagger MCPプロンプト

サーバーは、一般的なワークフローを通じて AI アシスタントをガイドする MCP プロンプトも提供します。

  • add-endpoint : Swagger MCP ツールを使用して新しいエンドポイントを追加するためのステップバイステップガイド

プロンプトを使用するには、クライアントはプロンプト名とオプションの引数を指定してprompts/getリクエストを送信します。

{
  "method": "prompts/get",
  "params": {
    "name": "add-endpoint",
    "arguments": {
      "swaggerUrl": "https://petstore.swagger.io/v2/swagger.json",
      "endpointPath": "/pets/{id}",
      "httpMethod": "GET"
    }
  }
}

プロンプトは、新しいエンドポイントを追加するために必要な正確なプロセスを AI アシスタントに案内する一連のメッセージを返します。

新しいプロジェクトの設定

まず、エージェントに Swagger ファイルを取得するように依頼します。その際、Swagger ファイルの URL を指定するか、少なくとも Swagger ファイルを見つける方法を伝えてください。これにより、ファイルがダウンロードされ、ハッシュされたファイル名でローカルに保存されます。このファイル名は、現在のソリューションのルートにある.swagger-mcp設定ファイルに自動的に追加されます。

自動生成された .swagger-mcp 構成ファイル

SWAGGER_FILENAME = TheFilenameOfTheLocallyStoredSwaggerFile

このシンプルな構成ファイルは、現在のプロジェクトを特定の Swagger API に関連付けます。将来的には、このファイルを使用して詳細を保存する可能性があります。

構成が完了すると、MCP は Swagger 定義を見つけて現在のソリューションに関連付けることができるようになり、作業中のソリューションに関連するプロジェクトとタスクを取得するために必要な API 呼び出しの数が削減されます。

改良されたMCPツールコードジェネレータ

MCP ツール コード ジェネレーターが強化され、より完全で使いやすいツール定義が提供されるようになりました。

主な改善点

  1. 完全なスキーマ情報: ジェネレーターには、ネストされたオブジェクトを含むすべてのモデルの完全なスキーマ情報が inputSchema に直接含まれるようになりました。

  2. パラメータ名の命名の改善: パラメータ名がより意味的になり、ドットなどの問題のある文字が避けられるようになりました (例: taskRequestではなくtask.Request )。

  3. セマンティック ツール名: ツール名はより説明的になり、HTTP メソッドとリソース パスに基づく一貫した命名規則に従うようになりました。

  4. YAML Swagger ファイルのサポート: ジェネレーターは、JSON と YAML Swagger 定義ファイルの両方をサポートするようになりました。

  5. 改善されたドキュメント: 生成されたツール定義には、すべてのパラメーターとプロパティの包括的な説明が含まれます。

  6. 外部依存関係なし: 生成されたコードは外部モデル ファイルをインポートする必要がないため、より自己完結的で使いやすくなります。

  7. AI 固有の指示: ツールの説明に AI エージェント向けの特別な指示が含まれるようになり、ツールを効果的に使用する方法を理解できるようになりました。

使用例

エンドポイントの MCP ツール定義を生成するには:

import generateEndpointToolCode from './services/generateEndpointToolCode.js';

const toolCode = await generateEndpointToolCode({
  path: '/pets',
  method: 'POST',
  swaggerFilePath: './petstore.json',
  singularizeResourceNames: true
});

console.log(toolCode);

これにより、POST /pets エンドポイントの完全なスキーマ情報を含む完全な MCP ツール定義が生成されます。

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

AIアシスタント向けMCPプロンプト

AIアシスタントがSwagger MCPツールを効果的に使用できるよう、一般的なタスクをガイドするプロンプト集を作成しました。これらのプロンプトは、新しいエンドポイントの追加、生成されたモデルの使用など、プロセスをステップバイステップで説明します。

プロンプトの完全なコレクションについては、 PROMPTS.mdファイルを参照してください。

使用例: AI アシスタントにプロジェクトに新しいエンドポイントを追加するように依頼する場合、「新しいエンドポイントの追加」プロンプトを参照して、アシスタントが正しい順序で正しいプロセスを実行していることを確認できます。

Available Tools

5 tools
execute_api_requestC

Execute an API request to a specific endpoint

ParametersJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP method (GET, POST, PUT, DELETE, etc.)
pathYesThe endpoint path (e.g., '/users/123')
paramsNoQuery parameters as key-value pairs
bodyNoRequest body as a JSON object (for POST/PUT/PATCH)
headersNoCustom headers as key-value pairs

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool executes an API request but fails to describe critical traits such as authentication requirements, error handling, rate limits, side effects (e.g., whether it modifies data), or response format. This leaves significant gaps for a tool that could perform destructive operations like DELETE.

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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a general-purpose tool, though it could be more front-loaded with key details if it were more comprehensive.

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 the complexity of executing arbitrary API requests (with potential for mutations, auth needs, etc.), no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, return values, or usage context, making it inadequate for safe and effective tool selection by an AI agent.

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 100%, so the input schema already documents all 5 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't clarify parameter interactions or provide examples), resulting in a baseline score of 3 where the schema does the heavy lifting.

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

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('execute') and resource ('API request to a specific endpoint'), which provides a basic purpose. However, it lacks specificity about what kind of API or system this targets, and it doesn't clearly differentiate from sibling tools like 'fetch_swagger_info' or 'validate_api_response', which might involve similar API interactions but for different purposes.

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 versus alternatives. It doesn't mention prerequisites, context (e.g., for testing or production calls), or exclusions, leaving the agent to infer usage based on the generic name and parameters alone, which is insufficient given the presence of sibling tools like 'get_endpoint_details' or 'list_endpoints'.

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

fetch_swagger_infoC

Fetch Swagger/OpenAPI documentation to discover available API endpoints

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoURL to the swagger.json or swagger.yaml file. If not provided, will try to use the base URL with common Swagger paths.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—such as whether it makes network requests, handles errors, returns structured data, or has any side effects. This leaves significant gaps for an agent to understand the tool's operation.

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?

The description is a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex API documentation. It doesn't explain what the output looks like (e.g., JSON/YAML structure), potential errors, or how it interacts with sibling tools, leaving the agent with insufficient context for effective use.

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 has 100% description coverage, so the schema already documents the single parameter ('url') adequately. The description adds no additional meaning or context about the parameter beyond what's in the schema, such as examples or constraints, but this is acceptable given the high schema coverage.

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's purpose with a specific verb ('fetch') and resource ('Swagger/OpenAPI documentation'), and indicates what it's used for ('to discover available API endpoints'). However, it doesn't explicitly differentiate this from sibling tools like 'list_endpoints' or 'get_endpoint_details', which might have overlapping functionality.

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 versus alternatives like 'list_endpoints' or 'get_endpoint_details'. It mentions the purpose but doesn't specify scenarios, prerequisites, or exclusions that would help an agent choose between these related tools.

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

get_endpoint_detailsB

Get detailed information about a specific API endpoint

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe endpoint path to get details for (e.g., '/users/{id}')
methodYesThe HTTP method (GET, POST, PUT, DELETE, etc.)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify aspects like authentication requirements, rate limits, error handling, or the format of the returned details. This is a significant gap for a tool with no annotation coverage.

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?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by directly stating the tool's function, making it highly concise and well-structured.

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?

Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It clarifies the purpose but lacks behavioral details and usage guidelines. Without an output schema, it doesn't explain return values, which could be a gap, but the description focuses on the input aspect, making it borderline complete for a basic read operation.

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 schema description coverage is 100%, with clear descriptions for both parameters ('path' and 'method'), so the schema does the heavy lifting. The description adds no additional parameter semantics beyond implying that these inputs identify a 'specific API endpoint', which is already inferred from the schema. Baseline 3 is appropriate as the schema provides adequate documentation.

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 verb ('Get') and resource ('detailed information about a specific API endpoint'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'fetch_swagger_info' or 'list_endpoints', which likely provide similar API information but with different scopes or formats.

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 is provided on when to use this tool versus alternatives. With siblings like 'fetch_swagger_info' (which might retrieve broader API documentation) and 'list_endpoints' (which might list endpoints without details), the description lacks context for selection, leaving the agent to infer usage based on tool names alone.

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

list_endpointsB

List all available API endpoints after fetching Swagger documentation

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that endpoints are listed 'after fetching Swagger documentation', hinting at a dependency or sequence, but it doesn't describe what 'list' entails (e.g., format, pagination, or if it's a read-only operation). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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?

The description is a single, efficient sentence that front-loads the core action ('List all available API endpoints') and adds necessary context ('after fetching Swagger documentation'). There is no wasted verbiage, and every part of the sentence contributes to understanding the tool's purpose and sequence.

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?

Given the tool's complexity is low (0 parameters, no output schema), the description is adequate but has gaps. It covers the purpose and hints at a sequence, but without annotations or output schema, it lacks details on behavior (e.g., what 'list' returns, any side effects). For a simple listing tool, it's minimally viable but could be more complete by clarifying the output or dependencies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any. Baseline is 4 for 0 parameters, as the description doesn't introduce confusion or redundancy.

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 action ('List all available API endpoints') and the resource ('API endpoints'), making the purpose immediately understandable. It distinguishes itself from siblings like 'fetch_swagger_info' by specifying it operates 'after fetching Swagger documentation', though it doesn't explicitly contrast with all siblings like 'get_endpoint_details'.

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?

The description implies usage by mentioning 'after fetching Swagger documentation', suggesting a prerequisite or sequence, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_endpoint_details' or 'execute_api_request'. No exclusions or clear alternatives are stated, leaving usage context somewhat vague.

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

validate_api_responseB

Validate an API response against the schema from Swagger documentation

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe endpoint path
methodYesThe HTTP method
statusCodeYesThe HTTP status code
responseBodyYesThe response body to validate

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates responses but doesn't explain how validation works (e.g., returns validation errors, success/failure status), what happens on failure, or any side effects. For a validation tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.

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?

Given the tool's moderate complexity (4 parameters, validation logic) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but fails to provide critical context like validation outcomes, error handling, or integration with sibling tools, leaving gaps for an AI agent.

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 has 100% description coverage, clearly documenting all four parameters (path, method, statusCode, responseBody). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Validate an API response against the schema from Swagger documentation'. It specifies the verb 'validate' and the resource 'API response', making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'execute_api_request' or 'fetch_swagger_info', which might handle related but distinct operations.

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 versus alternatives. It doesn't mention prerequisites (e.g., needing Swagger documentation loaded), context (e.g., after an API call), or exclusions. With siblings like 'execute_api_request' and 'fetch_swagger_info', this lack of differentiation leaves usage ambiguous.

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.

  1. 5 tool updates
    • First observedexecute_api_request
    • First observedfetch_swagger_info
    • First observedget_endpoint_details
    • First observedlist_endpoints
    • First observedvalidate_api_response
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: fetching documentation, listing endpoints, getting endpoint details, executing requests, and validating responses. The descriptions make it easy to tell them apart, as they target different stages of the API workflow.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., fetch_swagger_info, list_endpoints, execute_api_request). The naming is predictable and readable throughout, with no deviations in style or convention.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of interacting with Swagger/OpenAPI documentation and APIs. Each tool earns its place by covering distinct aspects of the workflow, from discovery to execution and validation.

Completeness5/5

The tool set provides complete coverage for the domain: it supports fetching documentation, listing and detailing endpoints, executing requests, and validating responses. There are no obvious gaps, and agents can handle the full API lifecycle without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches