What can you do with this server?

You can search and read internal Swagger platform API documentation through MCP tools. * List configured Swagger sources, their modules, interface counts, and cache status. * Search APIs by keyword across names, descriptions, paths, and modules, with optional HTTP method/service/deprecated filters and limits. * Retrieve full API details, including parameters, nested fields, response demos, response fields, and mock fields. * Force-refresh the documentation cache for a selected service or all services. * Use the server locally over stdio or remotely over stateless HTTP, with sources supplied per client/request.

Which integrations are available for this server?

Allows AI agents to query internal Swagger platform API documentation, including listing services, searching APIs by keyword, viewing full parameters and mock examples, and refreshing the cache.

How do I use internal-swagger-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@internal-swagger-mcp search for endpoints related to user authentication" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

internal-swagger-mcp

by zhangwanli09

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

internal-swagger-mcp

npm license

English | 简体中文

Let AI agents search and read your internal Swagger platform's API docs via MCP.

NOTE

This server talks to the internal Swagger management platform's private share endpoint (/flow/swagger/share?uid=...), not a public OpenAPI URL.

Implements MCP 2026-07-28 and still serves 2025-era clients, over both stdio and stateless HTTP (no sticky sessions needed). Requires Node.js ≥ 22.

Tools

Tool	Purpose
`swagger_list_sources`	List configured services and their cache status
`swagger_search_api`	Search APIs by keyword, optionally filtered by method / service
`swagger_get_api_detail`	Show an API's full parameters and mock example
`swagger_refresh_cache`	Force-refresh the doc cache (default TTL: 30 minutes)

Related MCP server: mcp-swagger

Sources

The server holds no configuration; each client supplies a list of Swagger share links (<SOURCE> below), which look like http://your-server/...#/swaggerManage?uid=xxx.

For local (stdio) mode, put them in swagger-sources.json at the project root and commit it:

["<SOURCE_1>", "<SOURCE_2>"]

The path resolves against the working directory (the project root under project-scoped configs), and the file is re-read on every tool call. Alternatively, drop --sources-file from the configs below and set the SWAGGER_SOURCES env var to the same JSON array.

For remote (HTTP) mode, sources go in the X-Swagger-Sources header of each request.

Connecting MCP clients

Use project scope so each repo pins its own sources. Once connected, swagger_list_sources should list your services.

For remote mode, start the server on a shared host first (see Security):

npx -y internal-swagger-mcp --http   # port 3000; override with --port or PORT

Claude Code

Docs — writes to .mcp.json.

# Local
claude mcp add swagger --scope project -- npx -y internal-swagger-mcp --sources-file ./swagger-sources.json

# Remote
claude mcp add --transport http swagger --scope project http://<internal-IP>:3000/mcp --header 'X-Swagger-Sources: ["<SOURCE>"]'

opencode

Docs — opencode.json. For remote, use "type": "remote" with url and headers.

{
  "mcp": {
    "swagger": {
      "type": "local",
      "command": ["npx", "-y", "internal-swagger-mcp", "--sources-file", "./swagger-sources.json"]
    }
  }
}

Cursor and other `mcpServers` clients

Docs — .cursor/mcp.json.

{
  "mcpServers": {
    "swagger": {
      "command": "npx",
      "args": ["-y", "internal-swagger-mcp", "--sources-file", "./swagger-sources.json"]
    }
  }
}

Remote: replace the entry with { "url": "http://<internal-IP>:3000/mcp", "headers": { "X-Swagger-Sources": "[\"<SOURCE>\"]" } }.

HTTP deployment security

The server binds to 0.0.0.0 by default and warns at startup if none of these is set:

Environment variable	Effect
`MCP_BIND_HOST`	Bind address, e.g. `127.0.0.1` for local-only
`MCP_BEARER_TOKEN`	Require `Authorization: Bearer <token>` (add it to the client's headers)
`MCP_ALLOWED_ORIGINS`	Comma-separated Origin allowlist; requests without `Origin` then need a valid bearer token

License

MIT

Available Tools

4 tools

swagger_get_api_detailGet Swagger API DetailA

Read-onlyIdempotent

Get full details of a single API interface, including all parameter definitions and response examples.

Parameters:

source (required): Service name, from the [service name] returned by swagger_list_sources or swagger_search_api.
method (required): HTTP method, e.g. "GET", "POST".
path (required): Full interface path, e.g. "/qmAuthorityCenter/systemFun/initPerformanceSolution".

Response includes:

Basic interface info (name, description, status, Content-Type).
Full definitions for Query / Path / Header / Form / Body parameters (name, type, required, description). Required column: "是" = required, "否" = optional, "?" = platform metadata is ambiguous (checkType=1 with no error message — cross-check with backend code or treat as optional).
Sub-fields of nested Object parameters.
Response results (Demo JSON + output field table).
Mock response field table.

Name	Required	Description
`path`	Yes	Full interface path, e.g. /qmAuthorityCenter/systemFun/initPerformanceSolution
`method`	Yes	HTTP method.
`source`	Yes	Service name, from swagger_list_sources or swagger_search_api results.

Output Schema

Name	Required	Description
`name`	Yes
`path`	Yes
`method`	Yes
`status`	Yes
`responses`	Yes
`mockFields`	Yes
`moduleName`	Yes
`parameters`	Yes
`sourceName`	Yes
`contentType`	No
`description`	Yes
`bodyRequestDemo`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context about the response contents, including parameter definitions, nested object sub-fields, response results, mock responses, and the special "?" required-column ambiguity, which helps the agent interpret output correctly.

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 well-structured with a front-loaded purpose, separate Parameters and Response sections, and concrete examples. It is somewhat long but appropriate for a detail-oriented tool, and the sections help the agent scan for relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and rich annotations, the description provides complete context: it explains the purpose, source provenance, parameter examples, response structure, nested object handling, and the ambiguous required-column indicator. Nothing critical for correct invocation or interpretation is missing.

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 parameters and examples. The description largely repeats the same parameter meanings without adding significant new syntax or constraints beyond what the schema provides, so baseline 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: retrieving full details of a single API interface, including parameter definitions and response examples. This clearly distinguishes it from sibling tools like swagger_list_sources and swagger_search_api, which are referenced for obtaining the source name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used after swagger_list_sources or swagger_search_api by specifying that the source parameter comes from those tools. It provides clear context for retrieving full details, but does not explicitly state when to use this tool versus search_api or list_sources beyond the implied workflow.

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

swagger_list_sourcesList Swagger SourcesA

Read-onlyIdempotent

List all configured Swagger documentation sources and their cache status.

For each service, returns:

name: Service name (from config, or auto-read from projectName).
fetchedAt: Last cache time (null means not yet loaded).
totalInterfaces: Total interface count (shown when loaded).
modules: Module list.

Use this before calling swagger_search_api to discover which services are available.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`sources`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description still adds genuine behavioral context — cache semantics, notably that fetchedAt null means not yet loaded and that totalInterfaces appears only when loaded — which is not derivable from the annotations. It stops short of pointing at swagger_refresh_cache when a cache is stale, which would complete the picture.

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?

Front-loaded with the core action, then a clean field list, then the routing sentence — no filler. The field bullets somewhat duplicate the output schema, which is mild redundancy, but the format is scannable and each line is short.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool with full annotation coverage and an output schema, an agent has everything it needs: what is returned, what the fields mean, and when to call it. Nothing material is missing.

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?

Zero parameters, so the baseline is 4. The description correctly requires no inputs and spends its space on return-value semantics instead, which is the right trade-off for a no-arg tool.

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

Purpose5/5

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

Specific verb+resource: 'List all configured Swagger documentation sources and their cache status.' It also enumerates the returned fields (name, fetchedAt, totalInterfaces, modules), so an agent knows exactly what it gets back and can differentiate it from swagger_search_api or swagger_get_api_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the sequencing rule: 'Use this before calling swagger_search_api to discover which services are available.' That names the alternative tool and the condition that selects it, leaving nothing to inference.

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

swagger_refresh_cacheRefresh Swagger CacheA

Idempotent

Force-refetch Swagger documentation data and update the cache.

Use this after the documentation has been updated (interfaces added or modified) to fetch the latest data.

Parameters:

source (optional): Service name. Omit to refresh all services.

Returns: Refresh results, including success/failure status and updated interface counts.

Name	Required	Description	Default
`source`	No	Service name. Omit to refresh the cache for all services.

Output Schema

Name	Required	Description
`failed`	No
`refreshed`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true; the description adds the mutation target (the cache) and the reason to invoke, which goes beyond the structured fields. It does not mention cost/latency of a full refetch or any auth/permission requirements, which would have made it a 5.

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?

Three short, front-loaded blocks that each serve a distinct purpose, with the action stated first. The 'Returns' line is largely redundant given an output schema exists, costing a little efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single optional-parameter cache-refresh tool with full schema coverage, annotations, and an output schema, the description covers what an agent needs to call it correctly. The main omission is any note about the scope/cost of refreshing all services when 'source' is omitted.

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 schema already documents 'source' including the omit-to-refresh-all behavior. The description's parameter section restates this without adding new syntax, format, or naming conventions, so the baseline 3 applies.

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?

States a specific verb and resource ('Force-refetch Swagger documentation data and update the cache'), so the agent knows exactly what operation happens. It does not explicitly contrast itself with the sibling tools (list_sources, search_api, get_api_detail), though the non-overlap is inferable from the name and description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this after the documentation has been updated (interfaces added or modified) to fetch the latest data' gives a clear triggering condition for invocation. No explicit when-not-to-use guidance or named alternatives are provided, but the context is unambiguous.

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

swagger_search_apiSearch Swagger APIA

Read-only

Search API interfaces in the internal Swagger documentation.

Searches by keyword across interface name, description, path, and module name. Optionally filter by HTTP method and service.

Parameters:

keyword (required): Search keyword, e.g. "登录", "user", "/api/order". Chinese is supported.
method (optional): HTTP method filter, e.g. "GET", "POST".
source (optional): Service name filter, taken from swagger_list_sources results.
include_deprecated (optional): Whether to include deprecated interfaces. Default false.
limit (optional): Maximum number of results. Default 20.

Response: Each matched interface includes: service name, module name, HTTP method, full path, interface name, description, status.

Examples:

Search login interfaces: keyword="登录"
Search POST interfaces: keyword="用户", method="POST"
Search within a specific service: keyword="order", source="订单服务"

Name	Required	Description
`limit`	No	Maximum number of results. Default 20, max 50.
`method`	No	Filter by HTTP method. Omit to search all methods.
`source`	No	Restrict the search to a specific service name (from swagger_list_sources). Omit to search all services.
`keyword`	Yes	Search keyword. Matches interface name / description / path / module name. Chinese is supported.
`include_deprecated`	No	Whether to include deprecated interfaces. Default false.

Output Schema

Name	Required	Description
`total`	Yes
`failed`	No
`keyword`	Yes
`results`	Yes
`truncated`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real context: the response field list, the default of 20 results, and that deprecated interfaces are excluded unless include_deprecated is set — a meaningful scoping behavior not in the annotations.

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?

Front-loaded purpose sentence followed by scoped bullets, response shape, and examples — well organized. There is mild redundancy between the parameter bullets and the schema descriptions, and the examples partially repeat the parameter text, keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter search tool with annotations, full schema coverage, and an output schema, everything needed to select and invoke it correctly is present: matching scope, filters, defaults, and result shape.

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?

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by giving illustrative keyword values (CJK text, path fragments like '/api/order') and tying source to swagger_list_sources output, which helps an agent construct valid calls.

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

Purpose5/5

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

States a specific verb (search) and resource (API interfaces in internal Swagger docs) plus the exact fields matched (name, description, path, module). This clearly distinguishes it from swagger_list_sources (enumerate) and swagger_get_api_detail (fetch one), which are named separately in the parameter docs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains how to filter by method and service, and explicitly ties the source filter to 'results from swagger_list_sources', establishing the intended call order. It gives three concrete query examples. It stops short of explicitly saying when to switch to swagger_get_api_detail for full detail, so not quite a 5.

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.

4 tool updatesv2.1.0Oct 27, 2026

Changedswagger_get_api_detail22 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / $defs

Added value: +{
+  "__schema0": {
+    "additionalProperties": false,
+    "properties": {
+      "children": {
+        "items": {
+          "$ref": "#/$defs/__schema0"
+        },
+        "type": "array"
+      },
+      "description": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "required": {
+        "enum": [
+          "yes",
+          "no",
+          "unknown"
+        ],
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "type",
+      "required",
+      "description"
+    ],
+    "type": "object"
+  },
+  "__schema1": {
+    "additionalProperties": false,
+    "properties": {
+      "children": {
+        "items": {
+          "$ref": "#/$defs/__schema1"
+        },
+        "type": "array"
+      },
+      "description": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "type",
+      "description"
+    ],
+    "type": "object"
+  },
+  "__schema2": {
+    "additionalProperties": false,
+    "properties": {
+      "children": {
+        "items": {
+          "$ref": "#/$defs/__schema2"
+        },
+        "type": "array"
+      },
+      "defaultValue": {
+        "type": "string"
+      },
+      "description": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "type",
+      "description"
+    ],
+    "type": "object"
+  }
+}

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / mockFields / items / $ref
```
Added value: +"#/$defs/__schema2"
```
removedOutput schema / properties / mockFields / items / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / mockFields / items / properties

Removed value: -{
-  "children": {
-    "items": {
-      "$ref": "#/properties/mockFields/items"
-    },
-    "type": "array"
-  },
-  "defaultValue": {
-    "type": "string"
-  },
-  "description": {
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  },
-  "type": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / mockFields / items / required
```
Removed value: -[
-  "name",
-  "type",
-  "description"
-]
```
removedOutput schema / properties / mockFields / items / type
```
Removed value: -"object"
```

changedOutput schema / properties / parameters / properties / body / items / $ref

Previous value: -"#/properties/parameters/properties/query/items"New value: +"#/$defs/__schema0"

changedOutput schema / properties / parameters / properties / form / items / $ref

Previous value: -"#/properties/parameters/properties/query/items"New value: +"#/$defs/__schema0"

changedOutput schema / properties / parameters / properties / header / items / $ref

Previous value: -"#/properties/parameters/properties/query/items"New value: +"#/$defs/__schema0"

changedOutput schema / properties / parameters / properties / path / items / $ref

Previous value: -"#/properties/parameters/properties/query/items"New value: +"#/$defs/__schema0"

addedOutput schema / properties / parameters / properties / query / items / $ref
```
Added value: +"#/$defs/__schema0"
```
removedOutput schema / properties / parameters / properties / query / items / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / parameters / properties / query / items / properties

Removed value: -{
-  "children": {
-    "items": {
-      "$ref": "#/properties/parameters/properties/query/items"
-    },
-    "type": "array"
-  },
-  "description": {
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  },
-  "required": {
-    "enum": [
-      "yes",
-      "no",
-      "unknown"
-    ],
-    "type": "string"
-  },
-  "type": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / parameters / properties / query / items / required
```
Removed value: -[
-  "name",
-  "type",
-  "required",
-  "description"
-]
```
removedOutput schema / properties / parameters / properties / query / items / type
```
Removed value: -"object"
```
addedOutput schema / properties / responses / items / properties / fields / items / $ref
```
Added value: +"#/$defs/__schema1"
```
removedOutput schema / properties / responses / items / properties / fields / items / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / responses / items / properties / fields / items / properties

Removed value: -{
-  "children": {
-    "items": {
-      "$ref": "#/properties/responses/items/properties/fields/items"
-    },
-    "type": "array"
-  },
-  "description": {
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  },
-  "type": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / responses / items / properties / fields / items / required
```
Removed value: -[
-  "name",
-  "type",
-  "description"
-]
```
removedOutput schema / properties / responses / items / properties / fields / items / type
```
Removed value: -"object"
```

Changedswagger_list_sources7 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / sources / items / properties / cacheValidMinutes / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / sources / items / properties / cacheValidMinutes / minimum
```
Added value: +-9007199254740991
```

addedOutput schema / properties / sources / items / properties / fetchedAt / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"

addedOutput schema / properties / sources / items / properties / totalInterfaces / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / sources / items / properties / totalInterfaces / minimum
```
Added value: +-9007199254740991
```

Changedswagger_refresh_cache5 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / refreshed / items / properties / fetchedAt / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"

addedOutput schema / properties / refreshed / items / properties / totalInterfaces / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / refreshed / items / properties / totalInterfaces / minimum
```
Added value: +-9007199254740991
```

Changedswagger_search_api4 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / total / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / total / minimum
```
Added value: +-9007199254740991
```

4 tool updatesv1.0.5Aug 6, 2026
- First observedswagger_get_api_detail
- First observedswagger_list_sources
- First observedswagger_refresh_cache
- First observedswagger_search_api

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A4.3/5.0

Scored 2026-10-27 05:55 across 4 tools

Disambiguation5/5

Each tool targets a distinct stage of the Swagger documentation workflow: listing sources, searching APIs, retrieving interface detail, and refreshing the cache. There is no meaningful overlap; descriptions and required parameters make the intended use of each tool clear.

Naming Consistency5/5

All tools follow a consistent swagger_<verb>_<noun> pattern: swagger_list_sources, swagger_search_api, swagger_get_api_detail, swagger_refresh_cache. The convention is predictable and immediately readable.

Tool Count5/5

Four tools is a tight, well-scoped surface for a Swagger documentation server. Each tool earns its place by covering a necessary step in the discovery-to-detail workflow, with no obvious redundancy.

Completeness4/5

The set covers source discovery, keyword search, detailed interface lookup, and cache refresh, which handles the core read workflow. Minor gaps exist, such as browsing all interfaces without a keyword or listing modules/interfaces directly, but agents can work around these via search.

Maintenance

ActivityNo data

ResponsivenessSyncing

Resources

Related MCP Connectors

Cralo
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
https://mcp.cralo.ai/mcp
Knowa
com.knowalabs
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Documentation Access Knowledge & Memory Search
2
https://app.knowalabs.com/api/mcp
SkillDashB
io.github.AjnasNB
Search and inspect source-pinned agent skills, plugins and tools through a free public MCP.
Search Developer Tools
61
https://skills.maqamagent.com/mcp
DartzDabz AI agent tool directoryA
com.dartzdabz
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
Search AI & Machine Learning Developer Tools
1
https://dartzdabz.com/mcp/

Related MCP Servers

Knowledge Server
Documentation Access API Testing Search
atnguyen143
F
license
Not graded
quality
Not graded
maintenance
Provides LLM-agnostic access to API documentation through MCP and REST endpoints, enabling AI assistants to retrieve, search, and proxy requests to whitelisted APIs across multiple platforms.
Updated 10 months ago (2025-12-27 16:06 UTC)
-
mcp-swagger
awssam
A
license
A
quality
D
maintenance
Exposes Swagger/OpenAPI API documentation to AI models, enabling exploration, search, and interaction with endpoints, schemas, and execution of API calls.
Updated 7 months ago (2026-04-16 22:47 UTC)
14
26 npm
2
MIT
api-docs-mcp
Documentation Access Developer Tools
DucDA177
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI agents to explore, search, and query API definitions from OpenAPI/Swagger JSON files.
Updated 9 months ago (2026-01-27 14:25 UTC)
18 npm
MIT
openapi-mcp
API Testing Developer Tools Documentation Access
Arge2004
F
license
Not graded
quality
D
maintenance
Enables agents to query real-time OpenAPI documentation of backend services, providing tools to list services, endpoints, and schemas via MCP.
Updated 4 months ago (2026-07-01 20:11 UTC)
-

internal-swagger-mcp

Tools

Sources

Connecting MCP clients

Claude Code

opencode

Cursor and other mcpServers clients

HTTP deployment security

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cursor and other `mcpServers` clients