mcp-api-guardian
This server provides two local MCP tools for checking OpenAPI 3.0/3.1 documents without calling live endpoints.
Audit a single OpenAPI spec (
audit_openapi) for static contract issues and authentication declarations.Compare two OpenAPI documents (
compare_openapi) to find selected breaking changes, not exhaustive schema compatibility.Use it as a local-first guardrail before shipping API contract changes.
MCP API Guardian
Stop your AI agent from breaking your API: OpenAPI contract checks and breaking-change diffs over MCP, fully local.
Local-first guardrails for AI coding agents working with OpenAPI specs: catch contract errors (missing operation IDs, unresolved references, public auth), detect breaking changes (removed operations, new required parameters, changed authentication), and keep API consumers working before you ship.
Zero configuration. No API keys. No network. Runs entirely on your machine via the Model Context Protocol.
Table of Contents
Related MCP server: OpenAPI Contract Guard MCP
Quick Install
One-Click Install
Cursor:
Or use the direct protocol link: cursor://anysphere.cursor-deeplink/mcp/install?name=api-guardian&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIm1jcC1hcGktZ3VhcmRpYW4iXX0=
Claude Code:
claude mcp add api-guardian -- npx -y mcp-api-guardianOr if installed in the petrovicistefan/mcp-marketplace:
/plugin marketplace add petrovicistefan/mcp-marketplaceManual Install
Claude Desktop:
Add to claude_desktop_config.json:
{
"mcpServers": {
"api-guardian": {
"command": "npx",
"args": ["-y", "mcp-api-guardian"]
}
}
}Cursor:
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"api-guardian": {
"command": "npx",
"args": ["-y", "mcp-api-guardian"]
}
}
}VS Code / GitHub Copilot:
Or manually create/edit .vscode/mcp.json:
{
"servers": {
"api-guardian": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-api-guardian"]
}
}
}Windsurf:
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"api-guardian": {
"command": "npx",
"args": ["-y", "mcp-api-guardian"]
}
}
}Zed:
Add to your Zed settings.json:
{
"context_servers": {
"api-guardian": {
"command": "npx",
"args": ["-y", "mcp-api-guardian"]
}
}
}Direct npx (one-line test):
npx -y mcp-api-guardian⭐ Star This Repo If It Helps
Found this MCP useful? Star this repository!
A GitHub star helps other developers discover the project and lets you save it for later. Thanks for supporting open source!
Why API Guardian
AI coding agents increasingly modify OpenAPI specs as they work on API features, documentation, and integrations. A single agent iteration can:
Remove an operation a client depends on
Add a required request parameter without a default
Change an
operationIdthat generated SDKs rely onAccidentally publish a public endpoint with no authentication
Break external references or introduce duplicate IDs
API Guardian catches these before they break production. It provides two MCP tools your AI agent can call:
audit_openapi— lints a single OpenAPI spec for contract errors, missing metadata, auth riskscompare_openapi— diffs two spec versions and detects breaking changes
Fully local, read-only, zero dependencies. No telemetry, no API keys, no network calls.
Tools
API Guardian provides 2 MCP tools for validating OpenAPI 3.0.x and 3.1.x documents:
Tool | Description | Inputs |
| Static OpenAPI 3.0/3.1 lint and authentication declaration review. Does not call endpoints. |
|
| Find selected breaking changes between two OpenAPI documents; not exhaustive schema compatibility. |
|
audit_openapi({spec})
Static contract checks on a single OpenAPI spec:
Contract errors: Unresolved
$refreferences, missinginfo.title/info.version, invalid pathsOperation metadata: Missing or duplicate
operationId, missing response definitionsPath parameters: All
{param}placeholders must be declared as required path parametersSecurity warnings: Public operations (no auth required), basic auth over HTTP, API keys in query strings
External references: Flags unchecked external
$refURLs (not fetched)
Reports errors and warnings with severity, location, and actionable messages. Explicitly states coverage limits.
compare_openapi({before, after})
Breaking-change detection between two OpenAPI spec versions:
Removed operations: Previously available endpoints deleted
Changed operation IDs: Generated clients and agents may depend on stable IDs
New required parameters: Added inline required parameters (clients can't provide them)
Request body requirement: Optional body became required
Removed response codes: Status codes clients may handle are gone
Security changes: Authentication requirements modified (warning-level)
Reports definite breaks (error) and potential compatibility issues (warning). Schema variance and composed schemas are not yet analyzed (see Limitations).
Use Cases
For Individual Developers
Prompt: "Audit the OpenAPI spec at api/openapi.json before I commit"
Your AI agent calls audit_openapi, catches a missing operation ID, and suggests a fix — before the PR.
For CI / PR Checks
Prompt: "Compare the OpenAPI spec on this branch to main and fail if there are breaking changes"
Your agent runs compare_openapi, detects a removed endpoint, and blocks the merge with an actionable report.
For Teams and Enterprises
Prompt: "Check all OpenAPI specs in api/ for public endpoints without authentication"
Your agent audits each spec, flags public operations, and generates a security review checklist.
Comparison with Alternatives
Feature | MCP API Guardian | optic (archived) | ||
MCP integration | ✅ Native MCP server | ❌ CLI only | ❌ CLI only | ❌ CLI only |
AI agent friendly | ✅ JSON-RPC stdio, designed for agents | ⚠️ CLI output parsing | ⚠️ CLI output parsing | ⚠️ Archived |
Fully local (no network) | ✅ Zero network calls | ✅ Offline | ✅ Offline | ⚠️ Cloud offering existed |
Breaking-change detection | ✅ Core feature | ✅ Comprehensive (773 checks) | ✅ Comprehensive | ✅ (legacy) |
Static contract linting | ✅ Core feature | ⚠️ Validation only | ⚠️ Change-focused | ⚠️ Traffic-focused |
Git revision comparison | ❌ Planned | ✅ Built-in | ✅ Built-in | ✅ (legacy) |
Schema compatibility | ❌ Planned | ✅ Full | ✅ Full | ✅ (legacy) |
HTML/Markdown reports | ❌ JSON only | ✅ Multiple formats | ✅ Multiple formats | ✅ (legacy) |
License | MIT | Apache 2.0 | GPL-3.0 / Commercial | MIT (archived) |
When to use API Guardian:
✅ You want your AI agent (Claude, Cursor, etc.) to natively check OpenAPI contracts without CLI wrappers
✅ You need local-first, zero-network validation (no external dependencies)
✅ You want targeted linting + breaking-change detection in one MCP server
When to use alternatives:
Use oasdiff if you need the most comprehensive breaking-change ruleset (773 checks) and CI-native workflows
Use pb33f/openapi-changes if you need beautiful HTML/Markdown diff reports for human review
Both oasdiff and openapi-changes support full schema compatibility checks and git-native comparison, which API Guardian will add in future releases
Limitations
API Guardian is a targeted linter, not a complete OpenAPI validator. Current limitations:
❌ YAML specs not supported: Only JSON OpenAPI documents are accepted. Pass parsed JSON objects to the MCP tools. YAML support is on the roadmap (see below).
❌ External
$refnot fetched: External HTTP/HTTPS references are flagged as warnings but not resolved or validated❌ Schema compatibility not checked: Request vs response variance,
oneOf/anyOf/allOfcomposed schemas, and property-level breaking changes require a later release❌ Referenced parameters not compared: Only inline parameters are checked in
compare_openapi❌ No live HTTP probes: Does not test actual API behavior or validate runtime responses
❌ No filesystem access: You must pass the spec as a parsed JSON object (no file paths)
Public endpoints may be intentional; warnings are not proof of a vulnerability. Reports explicitly state coverage limits.
Run from Source
git clone https://github.com/petrovicistefan/mcp-api-guardian.git
cd mcp-api-guardian
npm test
npm startAdd to an MCP client's configuration, replacing the absolute path:
{
"mcpServers": {
"api-guardian": {
"command": "node",
"args": ["/absolute/path/mcp-api-guardian/src/server.js"]
}
}
}Requirements: Node.js 22+
Roadmap
Future releases will add:
YAML support: Parse and validate YAML OpenAPI specs (currently JSON only)
Full schema compatibility: Detect property-level breaking changes, composed schemas (
oneOf/anyOf/allOf), request vs response varianceLocal reference resolution: Fetch and validate external
$refreferences with configurable allowlistsGit-native comparison: Compare specs across branches/commits without manual file extraction
Live response validation: Opt-in HTTP probes with target allowlists, size limits, and secret redaction
Hosted Path (Control Plane)
The local stdio MCP server above stays fully useful without an account or network. Quotas are enforced only by a separate hosted HTTP process that reserves units on mcp-control-plane before running the same analysis core.
# Terminal 1 — control plane (see its README for ADMIN_TOKEN)
node --env-file=.env src/server.js # in mcp-control-plane
# Terminal 2 — hosted api-guardian
cp .env.example .env # set CONTROL_PLANE_URL
npm run start:hostedBootstrap a customer key with the control-plane admin API (POST /v1/admin/accounts, POST /v1/admin/keys). Then:
Method | Path | Body |
GET |
| Liveness |
POST |
|
|
POST |
|
|
Customer routes require Authorization: Bearer mcp_…. On success the response includes report and usage. Over quota returns 429 with { "error": "quota_exceeded" } and does not run analysis. Default bind: 127.0.0.1:3100. Production needs an HTTPS reverse proxy.
Privacy: OpenAPI documents are processed on the hosted host only. Control-plane requests carry solely product (api-guardian), requestId, and units — never specs, reports, or credentials. Successful consume has no refund in the control-plane MVP.
This hosted path is a reference integration for future commercial offerings, not a published multi-tenant deploy. README prices remain hypotheses until billing is live. A local MIT package cannot reliably enforce paid quotas; those belong to an authenticated hosted service.
Contributing
Contributions are welcome! Please:
Open an issue to discuss the change before starting work
Follow the existing code style (ESM,
node:test, zero dependencies)Add tests for new features
Keep commits focused and descriptive
See CONTRIBUTING.md if it exists, or open an issue if you'd like to contribute.
License
MIT — Free for personal and commercial use. See LICENSE for full terms.
More MCP Servers by the Author
Part of the petrovicistefan MCP suite — local-first guardrails for AI coding agents.
Server | Description |
Audit MCP servers for tool poisoning, rug pulls, shadowing, and leaked secrets. OWASP MCP Top 10. | |
Detect dependency vulnerabilities, license risks, and supply-chain issues in your project. | |
SQL schema linting, migration safety checks, and query performance analysis. | |
Find cloud cost optimization opportunities in your infrastructure configs. | |
Technical SEO audits for web projects: meta tags, schema.org, Core Web Vitals, accessibility. | |
Price comparison and deal discovery for e-commerce and SaaS. | |
Directory of all available MCP servers and plugins. |
All servers are MIT-licensed, fully local, and require no API keys.
⭐ If this project helps you, star it on GitHub to help others discover it!
Available Tools
2 toolsaudit_openapiB
Static OpenAPI 3.0/3.1 lint and authentication declaration review. Does not call endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the analysis is static and 'does not call endpoints' (a safety-relevant signal), but says nothing about what the lint checks, output shape, or failure modes for malformed specs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler; the core action and the key constraint (no endpoint calls) are front-loaded. It is terse to the point of being a fragment, but there is nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, an undocumented nested object parameter, and only a one-line description leave the agent without enough to call this confidently. It should at minimum describe the expected 'spec' input form and what the audit returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter 'spec', and the description never mentions it. Because 'spec' is a nested object, the agent gets no guidance on whether it should be a parsed object, raw string, or what OpenAPI versions/shape are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (lint/review) and resource (OpenAPI 3.0/3.1 specs), and the phrase 'authentication declaration review' scopes it further. It distinguishes itself from compare_openapi by implication (single-spec static analysis) but never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the scope 'static lint and authentication declaration review'; there is no explicit when-to-use, when-not-to-use, or statement routing the agent toward compare_openapi for multi-spec scenarios. An agent must infer the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_openapiB
Find selected breaking changes between two OpenAPI documents; not exhaustive schema compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds one useful caveat — results are a selected subset, not a complete compatibility check — but says nothing about output shape, ordering, determinism, or what 'breaking' means, leaving most behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that carries the verb, resource, and scope limit with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool taking two nested-object specs with no output schema and no annotations, the description omits the expected input shape and what the result actually contains. An agent can guess intent but cannot confidently construct or interpret a call from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the two parameters are untyped nested objects, so the description must compensate. It only implies that the two documents correspond to the before/after params and never explains their expected form (parsed object vs. spec version), so the gap is largely unfilled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it finds breaking changes between two OpenAPI documents, and immediately scopes what kind ('selected', 'not exhaustive'). It is distinguishable from 'audit_openapi' by its comparative framing, though it never names the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'not exhaustive schema compatibility' tells the agent when not to rely on this tool, which is a partial usage boundary. However, there is no explicit when-to-use versus audit_openapi, and no prerequisites (e.g., both documents must be supplied) are stated.
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.
2 tool updates
v0.1.1- First observed
audit_openapi - First observed
compare_openapi
TDQS
Scored across 2 tools
audit_openapi targets a single document (lint/auth review) while compare_openapi targets two documents (breaking-change diff), so the action and input shape differ clearly. They share the same domain and both are static analysis, so an agent could momentarily hesitate, but the descriptions disambiguate well.
Both tools follow the same verb_noun snake_case pattern (audit_openapi, compare_openapi), with the noun being the OpenAPI artifact. Fully predictable and readable.
Two tools is thin for a server presented as an API guardian; linting and diffing are the core operations but little else is exposed. It is borderline rather than mismatched, since the stated scope is narrow.
Auditing and comparing cover the main lifecycle of reviewing OpenAPI specs, with honest scope caveats in the descriptions. Gaps exist (no spec fetching/resolution, no remediation or validation-report output tooling), but agents can work around them.
Maintenance
Related MCP Connectors
Detect breaking changes, generate changelogs, diff, and validate OpenAPI specs.
Schema-aware API monitoring: diff OpenAPI specs for breaking changes, manage endpoints.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Dated, verified API breakages for coding agents, plus a local scan for them in your existing code.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceValidates OpenAPI documents, JSON Schemas, and JSON payloads. Also compares OpenAPI specs and displays breaking changes.-
- AlicenseAqualityDmaintenanceEnables AI clients to validate OpenAPI specs, compare versions, detect breaking changes, and generate changelogs.4MIT
- AlicenseNot gradedqualityCmaintenanceProvides AI coding agents with accurate OpenAPI contract details to prevent hallucinated API calls, supporting multi-version pinning, endpoint discovery, and request validation.42 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables agents to analyze OpenAPI contracts for deterministic integration risks, plan auth, sync, action, and webhook candidates, and diff contract versions for likely breaking changes through read-only tools.MIT