oasdiff
Detect breaking changes, generate changelogs, diff, and validate OpenAPI specs.
Should I use this
Quality & Safety
Based on automated analysis of tool definitions and protocol compliance.
Context Cost
This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.
Install
One-Click Install
Add this to your `claude_desktop_config.json` file:
{
"mcpServers": {
"oasdiff": {
"url": "https://api.oasdiff.com/mcp"
}
}
}Remote endpoints
https://api.oasdiff.com/mcpstreamable-httpWhat it can do
Tool inventory
Tools (4)
🟡oasdiff_breaking_changes(base, revision)
Detect breaking API changes between two OpenAPI specifications. Pass the base (old) and revision (new) specs as YAML or JSON; returns the breaking and warning-level changes. Use this when the question is whether an API change breaks existing clients. Use oasdiff_changelog instead to list every change including non-breaking and informational ones, oasdiff_diff for the raw added/removed/modified structure, or oasdiff_validate to check a single spec rather than compare two. Both specs must be valid, self-contained OpenAPI (external $ref URLs or files are not resolved).
Input Schema
{
"type": "object",
"properties": {
"base": {
"type": "string",
"description": "the base (old) OpenAPI specification, as YAML or JSON"
},
"revision": {
"type": "string",
"description": "the revision (new) OpenAPI specification, as YAML or JSON"
}
},
"required": [
"base",
"revision"
],
"additionalProperties": false
}🟡oasdiff_changelog(base, revision)
Produce a full changelog of every detected change between two OpenAPI specifications (base vs revision), down to informational changes. Pass both specs as YAML or JSON. Use this when you want the complete set of changes at every severity. Use oasdiff_breaking_changes instead when you only care whether the change is breaking (less noise), or oasdiff_diff for the raw structural diff without a backward-compatibility judgment. Both specs must be valid, self-contained OpenAPI (external $ref URLs or files are not resolved).
Input Schema
{
"type": "object",
"properties": {
"base": {
"type": "string",
"description": "the base (old) OpenAPI specification, as YAML or JSON"
},
"revision": {
"type": "string",
"description": "the revision (new) OpenAPI specification, as YAML or JSON"
}
},
"required": [
"base",
"revision"
],
"additionalProperties": false
}🟢oasdiff_diff(base, revision)
Show the structural diff between two OpenAPI specifications (base vs revision): what was added, removed, or modified. Pass both specs as YAML or JSON. Use this when you want the raw structural changes rather than a backward-compatibility verdict. Use oasdiff_breaking_changes to judge whether changes break clients, or oasdiff_changelog for a severity-classified changelog. Both specs must be valid, self-contained OpenAPI (external $ref URLs or files are not resolved).
Input Schema
{
"type": "object",
"properties": {
"base": {
"type": "string",
"description": "the base (old) OpenAPI specification, as YAML or JSON"
},
"revision": {
"type": "string",
"description": "the revision (new) OpenAPI specification, as YAML or JSON"
}
},
"required": [
"base",
"revision"
],
"additionalProperties": false
}🟢oasdiff_validate(spec)
Validate a single OpenAPI specification against the OpenAPI and JSON Schema rules. Pass the spec as YAML or JSON; returns the findings (empty when the spec is valid). Use this when you have one spec and want to check it is well-formed. For comparing two specs, use oasdiff_breaking_changes, oasdiff_changelog, or oasdiff_diff instead. The spec must be self-contained (external $ref URLs or files are not resolved).
Input Schema
{
"type": "object",
"properties": {
"spec": {
"type": "string",
"description": "the OpenAPI specification to validate, as YAML or JSON"
}
},
"required": [
"spec"
],
"additionalProperties": false
}Community
Evidence