Correctover MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GROQ_API_KEY | No | API key for Groq provider | |
| GROQ_BASE_URL | No | Base URL override for Groq | |
| ZHIPU_API_KEY | No | API key for Zhipu AI provider | |
| OPENAI_API_KEY | No | API key for OpenAI provider | |
| ZHIPU_BASE_URL | No | Base URL override for Zhipu AI | |
| OPENAI_BASE_URL | No | Base URL override for OpenAI (e.g., https://your-proxy.com/v1) | |
| DEEPSEEK_API_KEY | No | API key for DeepSeek provider | |
| MOONSHOT_API_KEY | No | API key for Moonshot provider | |
| TOGETHER_API_KEY | No | API key for Together AI provider | |
| ANTHROPIC_API_KEY | No | API key for Anthropic provider | |
| DASHSCOPE_API_KEY | No | API key for Alibaba Qwen (DashScope) | |
| DEEPSEEK_BASE_URL | No | Base URL override for DeepSeek | |
| MOONSHOT_BASE_URL | No | Base URL override for Moonshot | |
| TOGETHER_BASE_URL | No | Base URL override for Together AI | |
| ANTHROPIC_BASE_URL | No | Base URL override for Anthropic | |
| DASHSCOPE_BASE_URL | No | Base URL override for DashScope | |
| SILICONFLOW_API_KEY | No | API key for SiliconFlow provider | |
| SILICONFLOW_BASE_URL | No | Base URL override for SiliconFlow |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Check health and availability of all configured LLM providers. Returns a list of active providers with their default models and session statistics. Call this first to verify your configuration before using the chat tool. |
| providersA | List all supported LLM providers with their configuration details, default models, base URLs, and current status. Use this to see which providers are available, what model each uses by default, and whether custom base URLs are configured for proxy or mirror setups. |
| statsA | Show Correctover session statistics including total API calls, validation pass rate, failover count, active providers, and server version. Use this after a working session to review reliability metrics and see how many self-healing events occurred. |
| validation_historyA | Query recent validation results with pagination. Returns the most recent LLM call validation records, newest first. Each record includes provider, model, latency, pass/fail status, validation score, and failure reasons. Use limit and offset to paginate through results. Default returns the 20 most recent records. Maximum 100 per page. The buffer holds up to 500 records; older entries are automatically overwritten. |
| chatA | Send a chat message to an LLM with automatic output verification. Routes through the best available provider, validates the response across 6 dimensions (structure, schema, latency, cost, identity, integrity), and auto-heals on failure by retrying or failing over to another provider. Returns the response text plus a validation report showing which dimensions passed or failed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| verify-output | Verify a specific piece of AI-generated content for correctness, completeness, and reliability across 6 dimensions. Use this when you want to check if a response is trustworthy. |
| compare-providers | Compare responses from multiple LLM providers on the same prompt to identify quality differences, hallucinations, or inconsistencies. Useful for provider selection and reliability testing. |
| reliability-audit | Run a comprehensive reliability audit on your LLM provider configuration. Tests connectivity, validates API keys, checks response quality, and identifies potential failure points in your setup. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: chat for sending validated messages, health for checking provider availability, providers for listing all supported providers, stats for session statistics, and validation_history for reviewing past validation results. There is no overlap in functionality.
All tool names follow a consistent pattern: single words or compound words with underscores (e.g., validation_history). They are all lowercase and descriptive of their function, making them easy to understand and predict.
With 5 tools, the server is well-scoped for its purpose of managing LLM chat with validation and monitoring. Each tool covers a core aspect without being overly specialized or too sparse.
The tool surface covers the full lifecycle of interacting with LLM providers: checking configuration (health, providers), sending messages (chat), reviewing performance (stats), and auditing (validation_history). No obvious gaps are present for the stated purpose.