Skip to main content
Glama
Sign In
Specwise MCP Server

Specwise MCP Server

by Bytestay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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".

NameRequiredDescriptionDefault
baseNoThe old version, as YAML or JSON text (or a JSON object).
revisionNoThe new version, as YAML or JSON text (or a JSON object).
base_pathNoThe old version as a local file.
base_git_refNoUse revision_path as it is at this git ref (e.g. main, HEAD) as the base.
revision_pathNoThe new version as a local file.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and open-world, so the safety profile is settled. The description adds value beyond that by disclosing the returned classification scheme (breaking/warning/non-breaking/info) and the `breaking` and `semver` result fields, which is exactly the extra context needed for a diff tool. It doesn't explain how the five optional source parameters interact or conflict, but that is largely the schema's job.

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 sentences with the purpose front-loaded, then result semantics, then an example – no filler. Minor cost from the inline backticked field names reading slightly clipped, but nothing wasteful.

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?

There is no output schema, and the description appropriately compensates with the shape of the result (change severities, `breaking`, `semver`). The remaining gap is that all five parameters are optional, and the description never states that at least one base/revision source pair must be supplied or what precedence applies.

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% with per-parameter descriptions, so the baseline is 3. The description rises above that by demonstrating a specific parameter pairing (revision_path together with base_git_ref) that shows how to build a git-ref comparison, which the schema alone does not convey.

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: 'Compare two OpenAPI 3.x documents', and follows with the semantics of the change categories it produces. That mostly separates it from the sibling validate_openapi, though it never says so explicitly.

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?

Adds one concrete usage scenario ('Typical use after editing a spec: revision_path="openapi.yaml", base_git_ref="main"') which implicitly shows the main workflow. It never mentions when not to use it or why to pick it over validate_openapi/validate_json_schema, so the routing decision is left to inference.

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

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.

NameRequiredDescriptionDefault
draftNoForce a draft; by default from $schema, else 2020-12.
schemaNoThe JSON Schema, as JSON or YAML text (or a JSON object).
instanceNoData to validate: JSON or YAML text, or the value itself. Optional.
schema_pathNoA local file instead of `schema`.
instance_pathNoData to validate, from a local file.

TDQS

A3.8/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), and the description adds genuinely new behavioral context: it discloses that every error carries an instance path, a schema path, and, for text input, a line number. It stops short of describing overall result shape or how errors are ordered/aggregated, so it is helpful but not complete.

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?

Two tight sentences with no filler: the primary purpose is front-loaded, the optional second mode follows, and the error-reporting detail closes it out. Every clause carries information.

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?

With five all-optional parameters, no output schema, and full annotation coverage, the description is close to sufficient, and the error-structure sentence compensates partially for the missing output schema. The remaining gap is that it never explains conflict behavior between the paired parameters (schema vs schema_path, instance vs instance_path) or the draft inference fallback beyond what the schema's default note says.

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 coverage is 100%, so every parameter is documented in the schema itself, which sets the baseline at 3. The description only reinforces the schema/instance duality and the text-vs-object input forms already stated in the parameter descriptions, adding no new semantics about precedence when both schema and schema_path (or instance and instance_path) are supplied.

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 gives a specific verb+resource pair ('Check a JSON Schema against its meta-schema') plus the secondary mode ('validate data against it'), so the agent knows exactly what the tool does. It never names its siblings validate_openapi or diff_openapi, leaving the agent to infer differentiation from the names alone.

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?

Usage is only implied: the description notes that data validation happens 'if given', which hints at the two modes but never states when to prefer this tool over validate_openapi or when a schema-only check is appropriate. No prerequisites, exclusions, or alternative routing are provided.

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

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.

NameRequiredDescriptionDefault
specNoThe document as YAML or JSON text (or a JSON object).
spec_pathNoA local file instead of `spec`.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral information beyond that: it reports every error rather than the first, includes JSON Pointer plus line/column locations, and also emits lint warnings — useful expectations for an agent planning to parse results.

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?

Two tight sentences with the verb and resource front-loaded, followed by the return contract. Nothing is redundant or padded.

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 two-parameter, read-only validation tool with no output schema, the description covers purpose and the shape of results (per-error pointers, line/column, lint warnings) adequately. The remaining gap is the input-selection rule between `spec` and `spec_path`, which neither the description nor the zero-required-parameter schema resolves.

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%, and the schema itself explains that `spec` is YAML/JSON text or an object and `spec_path` is a local file alternative. The description adds no further meaning, such as precedence when both are provided or the mutual-exclusion/at-least-one rule implied by zero required parameters, 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 (validate) and resource (OpenAPI document) and enumerates the supported formats/versions (OpenAPI 3.0/3.1/3.2, Swagger 2.0), which implicitly separates it from validate_json_schema. It never names the siblings diff_openapi or validate_json_schema directly, so the differentiation is scope-based rather than explicit.

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?

Usage is only implied by the resource scope — an agent can infer this is for checking an OpenAPI document for correctness. There is no statement of when to prefer diff_openapi (comparing two specs) or validate_json_schema, and no guidance about prerequisites such as needing either `spec` or `spec_path` supplied.

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. 3 tool updatesv0.2.2
    • First observeddiff_openapi
    • First observedvalidate_json_schema
    • First observedvalidate_openapi
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.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

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers