Specwise MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAPIDAPI_KEY | No | Your RapidAPI key. Every tool call is one request on your RapidAPI plan. | |
| API_MARKET_KEY | No | Your api.market key, used when RAPIDAPI_KEY is not set. | |
| HFL_MARKETPLACE | No | Either "rapidapi" or "apimarket", used to choose the marketplace when both keys are set. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_openapiA | 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. |
| diff_openapiA | Compare two OpenAPI 3.x documents. Each change is breaking, warning, non-breaking or info; Typical use after editing a spec: revision_path="openapi.yaml", base_git_ref="main". |
| validate_json_schemaA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
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.
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.
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.
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.