CodeGuardian MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_codeA | Validate code snippets or single-file changes for hallucinations, missing dependencies, and dead code in one pass. For full-project or monorepo-wide audits, use start_validation on a scoped subdirectory (e.g., frontend/ or backend/). |
| start_validationA | Start a background validation job for large codebases (>50 files) to avoid timeouts. In monorepos, run this on a scoped subdirectory (e.g., frontend/ or backend/) rather than the repo root. Use 'get_validation_status' to poll for progress. Results are saved to codeguardian-report.json at the project root (readable by file tools, NOT inside .codeguardian/). |
| get_validation_statusA | Check progress of a validation job. Poll every 3-5s until status is 'complete' or 'failed'. |
| get_validation_resultsA | Retrieve final results for a completed validation job. Results are also saved to codeguardian-report.json at the project root, readable by file tools. |
| build_contextB | Build or rebuild project context including symbols, git history, and intent signals. Usually auto-called by other tools. |
| get_dependency_graphA | The Ultimate Impact Analysis tool for Vibe Coders. Analyzes what files or symbols depend on a target. Use this to understand the "blast radius" of your changes. If you provide a 'symbol', it traces semantic call chains. Set 'includeSource: true' to get a bundled Markdown of all affected code, perfect for pasting into an AI prompt for safe refactoring. |
| start_guardianB | Activate a VibeGuard Agent. You can start multiple Guardians to watch different parts of your codebase (e.g., one for 'Frontend', one for 'Backend'). Each Guardian watches its own path and language. |
| stop_guardianA | Stop a specific Guardian Agent or all active Guardians. |
| get_guardian_alertsA | Get pending alerts from all active Guardians. Returns a compact summary with a pointer to the full LLM-readable alerts file (codeguardian-alerts.json) in the project root. |
| get_guardian_statusA | Get the current status of VibeGuard. Use this when the user asks for 'vibeguard status', 'what is running', or 'agent health'. Lists all active agents. |
| validate_api_contractsA | Validate API contracts between frontend and backend. Detects mismatches in endpoints, types, and parameters before runtime errors occur. |
| get_api_contract_reportC | Generate a detailed API Contract validation report with recommendations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| validate | Basic validation - Quick check for hallucinations |
| validate-detailed | Detailed validation with step-by-step reasoning |
| validate-with-examples | Validation with few-shot examples of common AI mistakes |
| validate-comprehensive | Comprehensive validation from multiple perspectives |
| validate-structured | Validation with structured output format |
| start-vibeguard | Start the VibeGuard agent with natural language (e.g., 'start vibeguard for my TypeScript project') |
| vibeguard-status | Check VibeGuard agent status (use when saying 'check vibeguard' or 'what's running') |
| vibeguard-validate | Use VibeGuard to validate code (e.g., 'vibeguard validate this file') |
| vibeguard-impact | Use VibeGuard to analyze impact (e.g., 'vibeguard what breaks if I change X') |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Quality Dashboard | Real-time code quality metrics and trends |
| Vulnerability Database | Common AI-generated security vulnerabilities |
| Best Practices Library | Context-aware coding best practices |
TDQS
Scored across 12 tools
Most tools have clear, distinct purposes, especially the lifecycle pairs for guardians and validation jobs. The main confusion risk is between validate_code and start_validation, which are distinguished primarily by codebase size, and validate_api_contracts vs get_api_contract_report, which could be seen as overlapping.
Tool names consistently follow a verb_noun pattern with get_, start_, stop_, and validate_ prefixes. There are no mixed casing or naming style violations, making the tool surface predictable.
Twelve tools is well within the sweet spot for a domain with multiple sub-areas: code validation, guardian lifecycle, alert retrieval, dependency analysis, and API contract checking. Each tool contributes a distinct capability without bloating the surface.
The set covers the main validation workflow (start/status/results), guardian lifecycle (start/stop/status/alerts), and API contract validation/reporting. A notable gap is the absence of a cancel or stop operation for background validation jobs, since stop_guardian only applies to Guardians.