How it works

1. You give us the code

Either upload a ZIP of your project folder, or paste the address of a public GitHub repository. For a GitHub repository we resolve the default branch to a specific commit and scan that exact commit, so the report records precisely what was read and a repeat scan of the same commit gives the same answer.

2. We read it, and only read it

The scanner parses your source files and matches them against a set of rules derived from the published protocol changes. It is worth being precise about what does not happen:

• Your code is never executed.
• No module from your project is imported.
• No package scripts run.
• No dependencies are installed.
• The scan has no network access.

Archives are unpacked with hard limits on size, file count and nesting, and entries that try to write outside the scan folder are refused rather than sanitised.

3. You get a report

Every finding is graded. Will break means a confirmed incompatibility. Deprecated means a feature that still works during its deprecation window but is going away. Needs review means we found something that may or may not matter and a person has to decide.

Each finding says what was found, why it matters, what may stop working, and a sentence you can send to whoever maintains the code. The technical detail and a link to the official source sit underneath.

4. Then we delete it

Uploaded archives are held only until the scan runs, then deleted. The unpacked source is removed as soon as the scan finishes — on success, on failure and on timeout alike. We keep the report, not your code.

What we cannot tell you

A clean report means that no implemented rule fired. It does not guarantee complete compatibility with the target MCP specification. Static analysis cannot see what your code does at runtime, cannot follow behaviour through a dependency it has not been taught about, and cannot know about a change we have not written a rule for.