# GraphQL Schema Breaking Change Detector MCP for AI Agents MCP

> GraphQL Schema Breaking Change Detector identifies regressions in your API evolution. It compares two versions of your schema to find deletions, type mutations, or nullability changes that would break clients.

## Overview
- **Category:** testing
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_KH8mghwVKDglJayUAAqHrgdiSU4KU6kgm73FDTpK/mcp
- **Tags:** graphql, schema, api, validation, regression

## Description

You are evolving an API and need to know if a change will crash your mobile app or web frontend. This MCP lets you drop two versions of your schema into your AI client and instantly see what is broken. It catches things like field deletions, type changes, or making a previously nullable field required. Instead of manually diffing massive SDL files, you just ask your agent to check the difference. Through the Vinkius catalog, you get direct access to these checks without setting up complex local environments. You can also verify that your syntax is valid before you even attempt a comparison, ensuring your schema structure is exactly what you expect it to be.

## Tools

### compare_schemas
Compares two GraphQL schemas to find breaking changes like deletions or mutations. It helps you prevent client-side crashes.

### inspect_schema
Breaks down the internal structure of your types and fields. Use this to see exactly how your schema is parsed.

### validate_syntax
Checks your GraphQL SDL for any structural or syntax errors. This ensures your schema is valid before you run comparisons.

## Prompt Examples

**Prompt:** 
```
Is there anything breaking in this new schema compared to the old one?
```

**Response:** 
```
I have analyzed both versions. A breaking change was found: The field `user.email` changed from `String` to `
* **Type Change**: `String` $\rightarrow$ `String!`
This may break clients that expect null values.
```

**Prompt:** 
```
Check if my GraphQL syntax is okay in this snippet.
```

**Response:** 
```
The syntax is valid. I did not find any structural errors or missing brackets in the SDL provided.
```

**Prompt:** 
```
What does the structure of the User type look like?
```

**Response:** 
```
The `User` type consists of the following fields:
* `id`: ID!
* `username`: String!
* `email`: String
```

## Capabilities

### Detect breaking API changes
Finds field deletions and type mutations between two schemas.

### Verify GraphQL SDL syntax
Checks your schema strings for structural or syntax errors.

### Analyze schema structure
Reveals the parsed internal structure of your types and fields.

### Identify nullability shifts
Spots dangerous changes where a field becomes non-nullable.

## Use Cases

### Detecting field deletions
A developer updates a type but accidentally removes a field used by the mobile app. They ask their agent to compare the old and new schema, and the MCP flags the deletion immediately.

### Verifying nullability changes
An engineer makes a field non-nullable in a new version. The agent uses compare_schemas to alert them that this change will break existing queries.

### Validating new SDL files
A developer pastes a large, messy SDL block into the chat. They use validate_syntax to ensure there are no typos before committing the code.

## Benefits

- Stop shipping breaking changes by catching field deletions before they hit production.
- Reduce manual diffing time using compare_schemas to automate schema audits.
- Ensure structural integrity with validate_syntax checks.
- Avoid client-side crashes caused by unexpected nullability shifts.
- Get a clear view of your API structure through inspect_schema.

## How It Works

The bottom line is you stop shipping broken APIs.

1. Provide two versions of your GraphQL SDL to the agent.
2. The MCP analyzes the differences between the strings.
3. You receive a clear report of every breaking change detected.

## Frequently Asked Questions

**How can I prevent breaking changes in my GraphQL API with this MCP?**
You use it to compare your current schema against a proposed version. The agent will flag any deletions or type mutations that would break existing queries.

**Can the GraphQL Schema Breaking Change Detector find syntax errors?**
Yes, you can use it to check if your SDL is structurally sound before you attempt to deploy it.

**Does this MCP work with any AI client?**
It works with any MCP-compatible client like Claude, Cursor, or Windsurf, allowing you to run schema audits directly in your coding environment.

**What kind of breaking changes does the GraphQL Schema Breaking Change Detector catch?**
It specifically looks for field deletions, type mutations, and changes in nullability that would cause existing client queries to fail.

**Can I use this MCP to inspect my schema structure?**
Yes, you can ask your agent to break down the types and fields within your GraphQL SDL to understand its internal organization.

**What constitutes a breaking change in this tool?**
A breaking change is any modification that violates the existing contract, such as removing a type or field, changing an argument, or transitioning a field from nullable to non-null.

**Can I use this to verify my new schema before deployment?**
Yes, by using `compare_schemas` with your current production schema as the base and your proposed changes as the next version, you can identify all potential regressions.

**Does it support all GraphQL features?**
The tool parses and compares types, fields, arguments, and enums. It specifically monitors nullability constraints and type mutations.