The first contract-validation MCP server on the Official Registry — because failover switches, but Correctover verifies.
What Just Happened
Correctover MCP Server (v1.0.3) is now live on the Official MCP Registry — the same registry VS Code 1.102+ uses to discover MCP tools.
This means: any developer using Cursor, Claude Desktop, VS Code, or Windsurf can type correctover in their MCP settings and instantly get contract-validation capabilities inside their AI assistant.
No gateway. No proxy. No Docker. No K8s. Just npx -y correctover-mcp-server.
Why This Matters
Most developers using LLM APIs rely on failover — switching providers when one goes down. But failover only checks one thing: "did Provider B respond?"
Here's what failover never checks:
- Model substitution: You request GPT-4o, silently receive GPT-4o-mini. You pay 4o tokens, get mini quality.
- Schema drift: Your structured output suddenly drops a required field. Downstream pipeline crashes.
- Cost overruns: Token count doesn't match what the requested model should produce.
- Semantic quality: The output "looks OK" but doesn't actually satisfy your prompt intent.
Failover answers: did it respond?
Correctover answers: is the response correct?
That's the gap. And now your AI coding assistant can help you close it.
How It Works: Inside Your IDE
Install the MCP server in your IDE config:
{
"mcpServers": {
"correctover": {
"command": "npx",
"args": ["-y", "correctover-mcp-server"],
"env": {
"DEEPSEEK_API_KEY": "your-key",
"MOONSHOT_API_KEY": "your-key",
"DASHSCOPE_API_KEY": "your-key"
}
}
}
}
Once connected, your AI assistant can:
- Validate LLM responses — Ask "is this GPT-4o response contractually correct?" and get a 6-dimension analysis (structure, schema, latency, cost, identity, integrity)
- Test failover paths — Ask "simulate an OpenAI timeout and verify the DeepSeek fallback response" — get real-time contract validation on the switched provider
- Detect silent model swaps — Ask "check if my recent API calls received the correct model" — get identity verification results
- Monitor API health — Ask "what's the health score of my configured providers?" — get real-time status
All inside your coding workflow. No separate dashboard needed.
6-Dimension Contract Validation
The CANON engine validates every response across 6 dimensions in 22μs P50:
| Dimension | What It Checks | Example Failure |
|---|---|---|
| Structure | Response format matches schema | JSON missing choices array |
| Schema | Required fields + correct types |
action_items field is null |
| Latency | Response time within SLA | 15s response from normally 1s provider |
| Cost | Token usage matches model range | 4o pricing but mini token output |
| Identity | Model matches requested model | Requested 4o, received 4o-mini |
| Integrity | Output meets quality threshold | Summary misses critical clauses |
The overhead is <0.01% of a typical LLM call (200-2000ms). You literally cannot measure the difference.
BYOK — Zero Markup, Zero Token Resale
Correctover uses your own API keys. Direct connect to providers:
- DeepSeek (via Anthropic-compatible endpoint)
- Moonshot / Kimi
- Alibaba DashScope (Qwen models)
- OpenAI (coming soon)
- Anthropic (coming soon)
No middleman. No token resale. No markup. Your data stays in your process.
Installation Options
VS Code 1.102+: Search "correctover" in MCP Extensions → Install
Cursor / Claude Desktop / Windsurf: Add to your mcp.json:
{
"mcpServers": {
"correctover": {
"command": "npx",
"args": ["-y", "correctover-mcp-server"],
"env": {
"DEEPSEEK_API_KEY": "sk-xxx",
"MOONSHOT_API_KEY": "sk-xxx",
"DASHSCOPE_API_KEY": "sk-xxx"
}
}
}
}
Smithery: Deploy with one click — scored 82/100 on quality assessment.
npm: npm install correctover-mcp-server
What's Different from Other MCP Servers
| Feature | Typical LLM MCP | Correctover MCP |
|---|---|---|
| Routes requests to LLMs | ✓ | ✓ |
| Validates response contracts | ✗ | ✓ |
| Detects silent model swaps | ✗ | ✓ |
| Catches schema drift | ✗ | ✓ |
| Prevents cost overruns | ✗ | ✓ |
| Self-healing (87 rules) | ✗ | ✓ |
| BYOK zero markup | ✗ | ✓ |
Other MCP servers help you call LLMs. Correctover helps you trust the responses.
The Numbers
| Metric | Value |
|---|---|
| Contract validation P50 | 22μs |
| Contract validation P99 | 99μs |
| L3 Failover E2E | 949ms |
| Self-healing rules | 87 |
| MCP Server version | 1.0.3 |
| Package size | <500KB |
| Dependencies | Minimal |
Why MCP Matters for LLM Reliability
MCP (Model Context Protocol) is becoming the standard way AI assistants interact with external tools. By making contract validation available as an MCP tool, Correctover bridges two worlds:
- Your AI coding assistant — which helps you write code that calls LLM APIs
- Your LLM API reliability — which ensures those calls produce correct results
Before: you write LLM code → hope it works → manually check dashboards
After: you write LLM code → assistant validates contracts in real-time → catches silent failures before they cascade
Try It Now
# Quick test without IDE integration
npx correctover-mcp-server
Or add to your IDE and ask your assistant:
"Use correctover to validate whether my last DeepSeek API call returned the correct model and schema."
Correctover MCP Server: npmjs.com/package/correctover-mcp-server
Correctover SDK: pypi.org/project/correctover
Website: correctover.com
Official Registry: VS Code MCP Extensions → search "correctover"
Because failover switches. Correctover verifies.
License: Proprietary Commercial License. SDK is free to integrate; core engine is proprietary.
© 2026 Guigui Wang. All rights reserved.
Top comments (10)
The failover versus verification distinction is a good one to draw, they get conflated constantly. One question on the contract-validation side: does it check structural validity (schema, types, required fields) or also semantic correctness, whether the values actually answer the request? Structural catches a lot and is the easy win, but the failures that hurt in production are usually schema-valid and still wrong. If semantic checks can be expressed as part of the contract, that is where it gets really useful. Putting it behind an MCP tool so the assistant can self-check mid-chain is a nice place for it.
That 495-distinct-failure-modes number is the interesting part to me - most teams doing this kind of validation stop at 5 or 10 rules and call it done. Curious how you're maintaining that taxonomy as models and use cases evolve: is it a living dataset you keep expanding as new failure shapes show up in production, or did it stabilize early? That's usually the harder problem than the initial detection logic.d
Good question. It's absolutely a living dataset — it didn't stabilize early.
The taxonomy started from ~30 real failure patterns we observed in production. As we scaled to more providers and more complex agent workflows, new failure shapes kept surfacing: compound fault chains, temporal drift, cascade failover gaps, partial heal inconsistencies. Things you can't anticipate from a design doc.
The rule we follow: if a failure shows up twice in production, it gets a permanent entry. Not "might happen" — actually happened. That keeps the signal-to-noise ratio high while the surface area keeps growing.
Current count: 495 and still climbing. The interesting part isn't the number — it's that ~38% of edge cases only appeared after the first 10K API calls. Most teams ship after 100 tests and call it robust. Real production tells a different story
38% after the first 10K calls is a rough number for anyone shipping after a 100-test suite and calling it done. It matches what I've seen too: the failures that actually cost you almost never show up in the first thousand runs, they show up when a provider changes something upstream or an edge case in the input distribution finally hits. The "happened twice, gets a permanent entry" rule is a good discipline, it keeps the taxonomy honest instead of theoretical.
Thanks for clarifying. Let's keep the technical discussion here on DEV so the evaluation setup and failure cases remain visible to other readers. If you share the dataset shape and the main false-positive pattern, I can comment on the calibration approach.
Fair call, and before I answer the shape question I need to correct the record on this thread.
The numbers in my July 2 reply — "20,000+ real API call dataset", "495 distinct failure modes", and the "~38% after the first 10K calls" figure — cannot be re-derived from an auditable trace. They shouldn't have been stated as measured. That's on me, and I'm withdrawing them here rather than letting a curious reader build on them. The follow-up note I posted on Aug 12 was meant to flag this kind of drift, but it didn't call out those specific numbers, which was a miss.
Here is the actual shape as it stands today.
What the test corpus actually isThe runtime verifier's security regression set is 51 hand-authored vectors across five classes: SSRF / command injection / credential leak / tool poisoning (manifest-vs-behavior drift) / identity & integrity (Ed25519). Each vector is a standalone positive or negative — a crafted MCP tool call or response plus an expected verdict. It isn't sampled from production traffic and isn't stratified by tool category or tenant. Across these 51 vectors, every "block" fires on a case authored as malicious and every "pass" on a case authored as safe — real but narrow.
The CCS receipt defines seven dimensions (Structure, Schema, Latency, Cost, Identity, Integrity, Security). Three — Security, Integrity, Identity — have shipped runtime rules today. The other four are protocol-level definitions with L1/L2 parameter checks, not full runtime enforcement yet.
On false positivesI don't have a real false-positive pattern from production traffic, because we haven't run the verifier against a corpus of real MCP production calls yet. "0 false positives" on the 51-vector set tells us the shipped rules don't fire on their own negative controls — it doesn't tell us what happens when a legitimate tool returns a blob that trips a credential regex, or when a developer's bash -c "echo $BUILD_ID" brushes the command-injection rule. Naming a dominant pattern without that data would repeat the 495 mistake.
Where I'd actually like your calibration read
As rules learn from new traces, how do you keep the held-out eval set from drifting in a direction that flatters the rules? Per-release pinning plus a shadow-traffic holdout, or something lighter?
For LLM-judged semantic verdicts (manifest-vs-behavior), what's the smallest setup you've seen that actually keeps the judge calibrated against human labels without becoming a full annotation program?
Happy to post the per-class breakdown as a gist if useful.
— Guigui Wang, Correctover — runtime verification for agent systems · IETF draft-correctover-ccs (Internet-Draft, not an RFC)
Retracting your own numbers mid-thread is rare, and it makes the rest of this easier to read - a 51-vector hand-authored set with zero production sampling is a narrow but honest claim, and "0 false positives on our own negative controls" is exactly the right way to state it.
On keeping the held-out set from flattering the rules: per-release pinning alone tends to drift, because the same person who writes the rule also curates the pin. What has worked better for me is splitting by provenance rather than by date. Any trace that was ever looked at while authoring or tuning a rule is permanently disqualified from eval, forever, even if it later looks like a great test case. Practically that means two buckets: an open bucket you are allowed to read and mine for rules, and a quarantined bucket from the same time window that nobody opens until the release is cut. Shadow traffic on top of that is worth it, but mostly as a false-positive detector rather than a correctness measure, since you have no labels there - what you are really watching is the block rate per tool category, and any rule whose fire rate jumps after a deploy gets looked at by hand.
On keeping an LLM judge calibrated without building an annotation program: the smallest thing I have seen hold up is a fixed calibration set of roughly 100-200 human-labeled cases, deliberately sampled from the disagreement-prone middle rather than the obvious extremes. Easy positives and easy negatives tell you nothing after the first week. Re-run that set on every judge prompt edit, model version bump, or threshold change, and track agreement with the human labels rather than raw accuracy - kappa or even a plain confusion matrix, because a judge can keep 90% accuracy while quietly moving all its errors into one class. Two things make it sustainable: version the judge prompt in the repo like code, since most "the judge got worse" incidents turn out to be an unreviewed prompt edit, and spot-check about twenty near-threshold verdicts a week. That is an hour, not a program, and near-threshold is where the information is.
For manifest-vs-behavior specifically I would also keep a rule-based pre-filter in front of the judge for anything structurally checkable, so the judge only sees genuinely ambiguous cases. It shrinks the calibration surface a lot.
The per-class breakdown as a gist would be useful, particularly the credential-leak and command-injection classes, since those are the two where legitimate traffic is most likely to look malicious.
Appreciate you reading it as honestly as it was meant — "38% of edge cases only appearing after the first 10K calls" reads very differently the day after you ship.
On keeping the taxonomy honest: every entry starts as provisional and only sticks after it's re-derived from an auditable trace. We've started attaching correction notices when a claim can't be re-verified from that record (our audit article now carries one), because a taxonomy that stops being re-checked turns back into theory.
And you're right that it's deliberately lagging — we're open about that tradeoff. Novel shapes (compound fault chains, cascade failover gaps) tend to surface at the seams, usually when a provider or tool surface changes upstream. That's exactly the boundary case you described.
To get more eyes on it, we're turning the catalog into a published artifact sourced from our 20,000+ call public trace dataset. Happy to share the draft here when it's ready — and your question about maintaining it as a living dataset is a good one to fold into that writeup.
On your original point: the verification layer is exposed as an MCP tool precisely so agents can self-check mid-chain rather than only at the end. That's what makes the taxonomy useful at runtime, not just in tests.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.