evalgate-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EVALGATE_DIR | No | Path to the evalgate checkout. Defaults to ../evalgate. | ../evalgate |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_suitesA | Load and validate the eval suites in a directory or file. Returns each suite name, its cases, the assertions declared on each case, and the threshold policy that gates it. Read-only — no model calls, no cost. |
| explain_resultA | Read an evalgate result artifact (.evalgate/result.json) and explain why it passed or failed: which gates tripped, which cases failed, and the per-assertion explanation for each — including the claim-level grounding breakdown. Read-only. |
| check_driftA | Analyze .evalgate/history.jsonl for slow decline the per-PR regression gate cannot see. A case sliding a little each run passes every individual gate by construction. Reports per-series delta and slope. Read-only. |
| judge_statusA | Read .evalgate/calibration.json and report the judge’s measured agreement with human scores. An uncalibrated judge is a random number generator with good manners — call this before trusting any rubric or grounded score. Read-only. |
| run_suiteA | Run the suites at a path against a system-under-test module and return the scored result. EXECUTES the SUT module and may call model providers, so it can incur real cost. Writes nothing — the result is returned in memory, not saved as an artifact. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct operation: listing suites, running them, explaining results, checking drift, and assessing judge calibration. No two tools overlap in purpose or behavior.
All tool names follow a consistent verb_noun pattern: list_suites, run_suite, explain_result, check_drift, judge_status. The naming is uniform and predictable.
With 5 tools, the server covers the core evaluation lifecycle without bloat. Each tool earns its place and the count is well-scoped for the domain.
The surface covers listing, running, explaining, monitoring, and validating calibration. Minor gaps exist (e.g., no tool for editing suites or historical per-case comparison) but core workflows are complete.