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 (5)
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.