Skip to main content
Glama
Specwise MCP Server

Specwise MCP Server

Specwise MCP server

M8ven Score CI PyPI Python 3.10+ License: MIT

Let your coding agent check an API contract: validate an OpenAPI document, find the breaking changes between two versions (also against git), and validate JSON Schemas and data.

The server is open source (MIT). It calls the Specwise API, which is paid, with a free plan.

  • You use your own key, from RapidAPI or api.market.

  • Every tool call is one request on your plan.

  • The free Basic plan has 15 requests a month, with a hard limit, so it never runs up a bill.

1. Get a key

marketplace

RapidAPI

plans

api.market

store

Related MCP server: OpenAPI Contract Guard MCP

2. Add the server to your MCP client

The server runs locally over stdio with uv. Put your key in its environment.

JSON configuration (Claude Desktop, Cursor, VS Code and most clients):

{
  "mcpServers": {
    "specwise": {
      "command": "uvx",
      "args": ["--from", "bytestay-specwise-mcp", "specwise-mcp"],
      "env": { "RAPIDAPI_KEY": "your-rapidapi-key" }
    }
  }
}

Claude Code:

claude mcp add specwise --env RAPIDAPI_KEY=your-rapidapi-key -- uvx --from bytestay-specwise-mcp specwise-mcp

Environment

variable

meaning

RAPIDAPI_KEY

your RapidAPI key

API_MARKET_KEY

your api.market key, used when RAPIDAPI_KEY is not set

HFL_MARKETPLACE

rapidapi or apimarket, when both keys are set

Without a key the server still starts. The first tool call then explains where to get one.

Also listed on Glama:

specwise-mcp on Glama

3. Tools

tool

what it does

validate_openapi(spec=… | spec_path=…)

every error with its JSON Pointer, line and column, plus lint warnings (OpenAPI 3.x and Swagger 2.0)

diff_openapi(...)

each change between two OpenAPI 3.x versions is breaking, warning, non-breaking or info, with a semver suggestion

validate_json_schema(schema=… | schema_path=…, instance=… | instance_path=…, draft=None)

checks the schema against its meta-schema and, if given, the data against the schema

diff_openapi takes the two versions in one of three ways:

  • base and revision as text;

  • base_path and revision_path as files;

  • revision_path with base_git_ref. For example, after editing a spec: revision_path="openapi.yaml", base_git_ref="main".

Every tool returns the API's JSON response.

  • When the marketplace reports it, quota_remaining is added: the requests left on your plan this month.

  • Errors are explained in plain words, with what to do next:

    • key refused, with the link to subscribe;

    • quota reached, with the plans;

    • input the API couldn't process, with the API's reason.

Privacy

  • Local files are read only when a tool is given their path. They are sent to the API for that one request.

  • The API processes inputs in memory and doesn't store them. See the privacy policy.

  • Your key is only sent to the marketplace you chose.

Limits

  • Documents up to about 900 KiB each.

  • External $refs are not fetched. Bundle multi-file specs first (redocly bundle).

  • The diff needs OpenAPI 3.x; Swagger 2.0 can be validated, not diffed.

  • The server needs Python 3.10+ (uv installs it for you).

Development

uv venv && uv pip install -e ".[dev]"
.venv/bin/pytest            # unit tests, no network; 100% coverage required
.venv/bin/ruff check src tests scripts

scripts/e2e_stdio.py specwise runs the server over stdio, as a client would, and calls its tools against the real API. It needs RAPIDAPI_KEY or API_MARKET_KEY.

Licence

MIT. Specwise itself is a paid API with a free plan, run by ByteStay.

Available Tools

3 tools
diff_openapiA
Read-onlyIdempotent

Compare two OpenAPI 3.x documents. Each change is breaking, warning, non-breaking or info; breaking says whether any is breaking, and semver suggests the version bump.

Typical use after editing a spec: revision_path="openapi.yaml", base_git_ref="main".

Inputs: base, revision, base_path, base_git_ref, +1 more.

validate_json_schemaA
Read-onlyIdempotent

Check a JSON Schema against its meta-schema and, if given, validate data against it. Every error has the instance path, the schema path and, for text input, the line.

Inputs: draft, schema, instance, schema_path, +1 more.

validate_openapiA
Read-onlyIdempotent

Validate an OpenAPI 3.0/3.1/3.2 or Swagger 2.0 document. Returns every error (not just the first) with its JSON Pointer, line and column, plus lint warnings.

Inputs: spec, spec_path.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 3 tools

    Disambiguation4/5

    Each tool targets a distinct operation: validating an OpenAPI document, diffing two OpenAPI documents, and validating a JSON Schema. The two 'validate_' tools could superficially be confused, but the descriptions make the format boundary (OpenAPI vs JSON Schema) explicit, so an agent can select reliably.

    Naming Consistency5/5

    All three tools follow a clean verb_noun snake_case pattern (validate_openapi, diff_openapi, validate_json_schema). 'diff' is used consistently as a verb and the noun portion names the artifact being operated on.

    Tool Count4/5

    Three tools is a tight, well-scoped surface for a spec-quality server, with no filler. It is on the lean side — a couple more operations would not feel excessive — but nothing here is redundant.

    Completeness4/5

    The core lifecycle of 'validate my spec, compare it to baseline, validate underlying JSON Schema' is covered end to end, including multi-error reporting and semver hints. Minor gaps exist: no $ref bundling/resolution, no Swagger-to-OpenAPI conversion, and no standalone lint mode.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers