Skip to main content
Glama

MCP API Guardian

Stop your AI agent from breaking your API: OpenAPI contract checks and breaking-change diffs over MCP, fully local.

npm version npm downloads Glama License: MIT

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:

Add to 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-guardian

Or if installed in the petrovicistefan/mcp-marketplace:

/plugin marketplace add petrovicistefan/mcp-marketplace

Manual 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:

Add to VS Code

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 operationId that generated SDKs rely on

  • Accidentally 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:

  1. audit_openapi — lints a single OpenAPI spec for contract errors, missing metadata, auth risks

  2. compare_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

audit_openapi

Static OpenAPI 3.0/3.1 lint and authentication declaration review. Does not call endpoints.

spec (object): OpenAPI document as JSON

compare_openapi

Find selected breaking changes between two OpenAPI documents; not exhaustive schema compatibility.

before (object): Original OpenAPI documentafter (object): Updated OpenAPI document

audit_openapi({spec})

Static contract checks on a single OpenAPI spec:

  • Contract errors: Unresolved $ref references, missing info.title/info.version, invalid paths

  • Operation metadata: Missing or duplicate operationId, missing response definitions

  • Path parameters: All {param} placeholders must be declared as required path parameters

  • Security warnings: Public operations (no auth required), basic auth over HTTP, API keys in query strings

  • External references: Flags unchecked external $ref URLs (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

oasdiff

pb33f/openapi-changes

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 $ref not fetched: External HTTP/HTTPS references are flagged as warnings but not resolved or validated

  • ❌ Schema compatibility not checked: Request vs response variance, oneOf/anyOf/allOf composed 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 start

Add 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:

  1. YAML support: Parse and validate YAML OpenAPI specs (currently JSON only)

  2. Full schema compatibility: Detect property-level breaking changes, composed schemas (oneOf/anyOf/allOf), request vs response variance

  3. Local reference resolution: Fetch and validate external $ref references with configurable allowlists

  4. Git-native comparison: Compare specs across branches/commits without manual file extraction

  5. 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:hosted

Bootstrap a customer key with the control-plane admin API (POST /v1/admin/accounts, POST /v1/admin/keys). Then:

Method

Path

Body

GET

/health

Liveness

POST

/v1/audit

{ "requestId": "scan-1", "units": 1, "spec": { … } }

POST

/v1/compare

{ "requestId": "diff-1", "before": { … }, "after": { … } }

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:

  1. Open an issue to discuss the change before starting work

  2. Follow the existing code style (ESM, node:test, zero dependencies)

  3. Add tests for new features

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

mcp-security-guard

Audit MCP servers for tool poisoning, rug pulls, shadowing, and leaked secrets. OWASP MCP Top 10.

mcp-dependency-doctor

Detect dependency vulnerabilities, license risks, and supply-chain issues in your project.

mcp-database-doctor

SQL schema linting, migration safety checks, and query performance analysis.

mcp-cost-optimizer

Find cloud cost optimization opportunities in your infrastructure configs.

mcp-seo-auditor

Technical SEO audits for web projects: meta tags, schema.org, Core Web Vitals, accessibility.

mcp-dealfinder

Price comparison and deal discovery for e-commerce and SaaS.

mcp-marketplace

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 tools
audit_openapiB

Static OpenAPI 3.0/3.1 lint and authentication declaration review. Does not call endpoints.

NameRequiredDescriptionDefault
specYes

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

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

NameRequiredDescriptionDefault
afterYes
beforeYes

TDQS

B3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updatesv0.1.1
    • First observedaudit_openapi
    • First observedcompare_openapi

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers