Verificate MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERIFICATE_TOKEN | No | Your Verificate API token. Without this, introspection still works but tool calls return instructions for getting a trial token. |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_ai_outputA | The merge gate for AI-written CODE: returns a binary approve/reject verdict with veto power — e.g. it rejects code calling the nonexistent stripe.Inventory API, or an N+1 loop with the latency arithmetic to prove it. Deterministic reality gates (mock/placeholder veto, gaming and bypass detection, invented-API checks) run first and cannot be overridden; a frontier-model review (ISO/IEC 25010) then scores performance, scalability, reliability and tech debt. Read-only: the code is analyzed, never executed. Call it on every AI-generated diff before accepting it; use validate_plan for plans, analyze_code for an advisory report without a verdict. |
| validate_planA | The gate for PLANS, designs and specs — run BEFORE any code is written, the cheapest place to catch a bad design. Returns the same binary verdict shape as validate_ai_output, with findings on completeness, feasibility, performance and scalability implications, security risks and missing considerations (e.g. it rejects a plan that polls an API every 100ms per client, with the request-volume math). Read-only: nothing is executed or stored beyond the verdict. Use validate_ai_output for the code that follows. |
| analyze_codeA | Advisory deep-dive on existing code — scores and findings, deliberately NO pass/fail verdict, so it never blocks an agent. Surfaces performance hot paths, scalability cliffs, reliability gaps and tech debt with concrete latency/throughput arithmetic (e.g. 'O(n²) dedup: ~4s at 10k items'). Read-only: the code is analyzed, never executed. Use it to understand a validate_ai_output rejection or review inherited code; use validate_ai_output when you need an accept/reject decision. |
| generate_codeA | Generate code and gate it in one step: an LLM writes the implementation, then the same protection engine as validate_ai_output vets it — retrying generation when the gate rejects. If every attempt is vetoed you still receive the last attempt, clearly marked validated:false with the gate findings — rejected code is never presented as clean. Generation runs on our infrastructure; nothing executes in your environment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| gate_my_changes | Run the Verificate merge gate on code and loop until it is approved: validate, fix every finding, re-validate. |
| review_my_plan | Gate an implementation plan before any code is written: validate it, address every finding, re-validate. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| The 17 protection gates | What each deterministic gate watches for, and why a veto cannot be overridden. |
| Example rejection verdict | A verbatim REJECTED 30.8/100 verdict from the production gateway. |
TDQS
Scored across 4 tools
Each tool targets a distinct artifact and action: validate_plan is for design specs, validate_ai_output is for code verification, analyze_code is advisory without a verdict, and generate_code is generation with built-in validation. Even the overlapping gate logic in validate_ai_output and generate_code is clearly differentiated by purpose, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern using lowercase and underscores: validate_*, analyze_code, generate_code. The verbs clearly indicate the action (validate, analyze, generate) and the objects specify the target, making the naming predictable and scannable.
Four tools is an ideal size for this server's purpose—covering validation, analysis, and generation without unnecessary bloat. Each tool earns its place in the workflow, and the count is well within the 3-15 range for a focused server.
The server covers the full verification lifecycle: plan validation before code, code validation for AI-generated diffs, advisory analysis for existing code, and generation with built-in gating. There are no obvious missing operations or dead ends—the tools form a complete pipeline.