AI can make an MCP server look finished before anyone has checked the promises it makes.
The server starts. Its tools appear. A sample call returns something plausible. The same coding agent that wrote it may even declare the job done.
That is a build result, not independent evidence. Put mcp-doctor between “it runs” and “we are ready to launch”: inspect locally while the code is fresh, then repeat a pinned check in CI.
A CI result can be more specific than pass or fail
mcp-doctor v0.4.0 defines 52 stable finding codes: 1 informational, 5 warnings, 42 errors, and 4 critical findings.
These are diagnostic definitions across passive and active commands—not common findings, observed defects, server scans, incidence rates, a guarantee that every code runs in passive inspect, or proof of test coverage.
View source data and counting method
| Severity | Finding codes |
|---|---|
| Informational | 1 |
| Warning | 5 |
| Error | 42 |
| Critical | 4 |
Fast code creates a confidence gap
When one agent writes the schema, handler, and tests, one wrong assumption can travel through all three. A green test confirms only the behaviour that test asked about.
An independent diagnostic looks at the surface an MCP client will discover, not the intent the builder remembers. That difference is small in the workflow and large when a server reaches users.
Build
Check locally
Protect the change
Launch
Give every build a local checkpoint
mcp-doctor v0.4.0 inspect starts the local command or contacts the remote endpoint you select. It checks discovery, definitions, and schemas without invoking a listed tool.
Within that advertised contract, it can surface broken protocol behavior, unusable guidance, invalid or unsafe schema shapes, and credential-like literals.
Build → inspect → fix → inspect again. AI can still write the fix; mcp-doctor gives it a separate, bounded result to work from.
Make CI ask the same question
mcp-doctor v0.4.0 provides deterministic exit meanings and redacted JSON, JUnit, Markdown, and badge artifacts. Its repository also publishes a least-permission GitHub Actions passive-preflight starter.
This is the consistency win: the check no longer depends on a person remembering to run it or on the original agent’s context. Every relevant change can meet the same pinned gate.
What a smoother launch actually means
Before review
Find advertised-contract problems while the change is still fresh.
Before merge
Repeat the same check instead of relying on memory or agent confidence.
Before launch
Keep a reviewable record of what was checked and where the evidence stops.
Let AI build fast. Keep a separate gate.
AI shortens the path to working code. mcp-doctor shortens the distance between “it runs” and “we checked what it promises.”
Use it locally for fast feedback, carry the same bounded check into CI, and reach launch with fewer surprises and clearer evidence.
See how mcp-doctor fits into CI
Sources and boundaries
Product behaviour is scoped to the released mcp-doctor v0.4.0 documentation reviewed August 24, 2026.
- mcp-doctor README Current product overview, passive-inspection boundary, diagnostic coverage, and safety summary.
- mcp-doctor v0.4.0 release Immutable release evidence for passive guidance checks and deterministic CI artifacts.
- Automation and CI Stable exits, redacted report contracts, and the least-permission passive-preflight starter.
- mcp-doctor safety model Execution, authority, redaction, network, and diagnostic-limit boundaries.
- mcp-doctor v0.4.0 finding model Immutable stable-code and severity definitions used for the article graph; not observed server findings.