The Verificate MCP server provides agentic code review featuring deterministic “reality gates” with veto power and a frontier-model enterprise review. It offers four tools:
validate_ai_output: Gate AI-generated code (diffs, functions, files) through 17 deterministic checks (mock/placeholder veto, invented-API detection) and an ISO/IEC 25010 review, returning a binary approve/reject verdict, score (0–100), severity-ranked findings, and fix suggestions. Any gate veto is final.
validate_plan: Gate implementation plans/designs before coding, checking completeness, feasibility, scalability, and security, with the same binary approve/reject verdict.
analyze_code: Advisory deep-dive on existing code—identifies hot paths, scalability cliffs, reliability gaps, and tech debt with concrete arithmetic. Supports focused lenses (quality, performance, scalability, security, tech debt) and deliberately returns no pass/fail verdict.
generate_code: Generate and auto-gate code in one step; if rejected, the system retries generation. Only approved code is presented as valid; vetoed attempts are clearly flagged with validation findings.
All tools are language-agnostic and integrate into AI assistants (Claude Code, Cursor, Windsurf) or CI/CD pipelines.
You vibe-coded the demo. This ships it. Between a working demo and a launched product used to stand an experienced CTO and a senior dev team — the people who catch the mock refund path, the invented SDK call, the loop that dies at real traffic. Verificate MCP is that review team as an MCP server: 17 deterministic reality gates with veto power, fused with a frontier-model enterprise review (ISO/IEC 25010: performance, scalability, reliability), run on every AI-written change before it reaches your codebase. The AI writes; the gate holds the bar; you ship. Hosted, zero-install, binary verdict in seconds — in Claude Code, Cursor, Windsurf or any MCP client.
Not another linter wrapper. The code-quality shelf on every MCP directory is two things: scanners (ESLint, Semgrep and SonarQube bridges — deterministic rules, no judgment) and prompt relays that pipe your repo to your own LLM key (self-review with extra steps). Verificate is neither: the gates hold veto power that no model output can override.
Your coding assistant writes a mock and calls it done. It invents an SDK call that doesn't exist. It ships an N+1 loop that passes every test and dies under load. Verificate MCP runs the deep review pass on every AI output — deterministic reality gates first (any one can veto), then an enterprise-grade review scores what survives — before the code reaches your codebase.
12 plausible lines of AI-written payment code were sent through the production gateway. Verdict: REJECTED — score 30.8/100, vetoed by code_reality_gate, with findings including:
"N+1 synchronous API calls … For 100 items, this results in 100 sequential HTTP roundtrips, taking ~10–20 seconds and blocking the event loop/worker thread … will trigger Stripe rate limiting (100 req/sec limit)." "
stripe.Inventoryis not a valid Stripe SDK resource." "Floating-point representation issues lead to rounding errors in financial transactions; Stripe API requires integer cents."
Each of those is an afternoon of production debugging, caught in seconds.
Related MCP server: Context7 MCP
A frontier model asked "is this OK to merge?" in a natural workflow missed reward-gaming (a test
that only does assert True) and a hallucinated API (stripe.Refund.create_partial) in 0 of 6
runs each. Verificate's gate caught both 6 of 6 — deterministically, with 0 false positives
on clean code.
Adversarial case | LLM review alone | Verificate gate |
Reward-gaming ( | 0 / 6 | 6 / 6 |
Hallucinated API (nonexistent SDK call) | 0 / 6 | 6 / 6 |
Battle-tested: 2,581 audited validations over 5 weeks (66 rejected, 270 flagged unfit),
including guarding the write-path of a 21M-entity source-cited knowledge base (98.6% cited,
100% licensed across 268 sources). Reproduce it: scripts/ · full write-up: COMPARISON.md.
Each tool has one job — two gates that return verdicts, one advisor that doesn't, one generator:
Tool | Job | Returns |
| The merge gate for AI-written code. Deterministic reality gates (mock/placeholder veto, gaming & bypass detection, invented-API checks) run first and can't be overridden; ISO/IEC 25010 review scores what survives. | Binary approve/reject verdict + severity-ranked findings |
| The gate for plans and designs, before any code exists — completeness, feasibility, scalability implications, risk. The cheapest place to catch a bad design. | Binary approve/reject verdict + findings |
| Advisory deep-dive on existing code — hot paths, rate-limit math, failure modes, tech debt. Use it to understand a rejection or review inherited code. | Scores + findings, deliberately no verdict |
| Generate + gate in one step — the LLM writes it, the same protection engine vets it before you see it. | Gated code (no placeholders, no invented APIs) |
The server also ships prompts and resources for a richer client experience:
Prompts gate_my_changes / review_my_plan — one-click workflows that loop validate → fix → re-validate until approved.
Resources verificate://gates (what each of the 17 deterministic gates watches for) and verificate://example-verdict (a verbatim production rejection).
Every machine gets 25 free validations — no account, no card, no key. Add the URL and go:
Claude Code
claude mcp add --transport http verificate https://mcp.verificate.ai/mcpCursor / VS Code — one-click install:
LM Studio and Goose one-click buttons are at https://verificate.ai/mcp (GitHub strips their custom-protocol links).
Windsurf / any MCP client (JSON)
{
"mcpServers": {
"verificate": {
"url": "https://mcp.verificate.ai/mcp",
"transport": "http"
}
}
}Cursor: ~/.cursor/mcp.json. Windsurf: ~/.codeium/windsurf/mcp_config.json.
Then ask your assistant to "validate this function with verificate" — a structured verdict comes back in seconds, and every free-tier response shows how many validations you have left and what the gate has caught for you.
Sign up at https://verificate.ai/auth/signup (30-day trial, no card — then $30/mo) and add your token to the same config:
claude mcp add --transport http verificate \
https://mcp.verificate.ai/mcp \
--header "Authorization: Bearer YOUR_TRIAL_TOKEN"or in the JSON config add "headers": { "Authorization": "Bearer YOUR_TRIAL_TOKEN" }.
Tools an agent may call are tools it will skip under pressure. Add a standing rule (Claude Code: CLAUDE.md; Cursor: a rule file):
Before presenting any substantive code change as complete:
1. Call validate_ai_output on the change.
2. If the verdict is REJECTED, fix the findings and re-validate.
3. Never claim tests pass or systems are deployed without proof.One-paste setup prompts that install these rules for you: PROMPTS.md. Or wire it into CI as a merge gate — see examples/.
AI output ──► Reality gates (deterministic, any one vetoes)
• mock/placeholder in the wire path
• invented/hallucinated APIs
• claimed-complete without proof
• gaming & bypass detection
│ survivors only
▼
Enterprise review (ISO/IEC 25010 + MLOps)
performance · scalability · reliability · tech debt
│
▼
Verdict: score /100 + severity-ranked findings
(REJECTED = agent fixes findings and re-validates)The two stages are deliberately separate: if reality and quality were blended into one score, a beautifully structured function that fakes its refund path could still average out to "acceptable." A veto architecture makes that impossible.
Everything else on the MCP code-quality shelf is free — and that's fair, because a wrapper should be free. What you can't get for free is judgment with authority:
What you'll find on the directories | What it is | What it structurally can't do |
Linter wrappers — ESLint MCP, Semgrep MCP, SonarQube MCP | Rule-based scanners exposed as MCP tools. Deterministic, free, worth running. | No judgment. Rules can't know the refund function never calls the payment provider, or that |
BYO-key review relays | Your repo + a review prompt, piped to your own OpenAI/Anthropic key. | Self-review with extra steps: the reviewer shares the generator's blind spots, there are no deterministic gates underneath, and whatever the model says goes. You maintain keys, versions and hosting. |
A bigger model | Hope the generator reviews itself better. | Self-review inherits self-blindness. An external gate holds the same bar for every model — which also makes smaller, cheaper models safe to ship with: same gate either way. |
Human review of every AI diff | The gold standard, at human speed. | Doesn't scale at AI generation speed. The gate does the first pass in seconds; humans review verdicts, not raw diffs. |
Verificate MCP | Deterministic reality gates with veto, then a frontier-model enterprise review — fused into one binary verdict. Hosted, always on the current model. | — |
That second layer is the part you pay for: a frontier agent doing the deep review — production arithmetic, failure modes, SDK reality — with a deterministic floor under it that the agent itself cannot argue away.
This repo is also a runnable, zero-dependency MCP server: a stdio bridge that serves initialize/tools/list locally and forwards tool calls to the hosted gateway. Use it with clients that prefer stdio servers:
VERIFICATE_TOKEN=<your-token> npx github:Verificate-Dev/verificate-mcp-quickstartOr with Docker:
docker build -t verificate-mcp .
docker run -i -e VERIFICATE_TOKEN=<your-token> verificate-mcpWithout VERIFICATE_TOKEN, introspection still works and tool calls return instructions for getting a trial token.
Does it slow the agent down? Each validation takes seconds, inside the loop, before work is presented. Compare with a defect found in CI or production plus the context switch to fix it — gating is net-faster for any change that matters.
Which languages? Validation is language-agnostic; analysis covers mainstream languages (Python, JS/TS, C++, SQL, Swift, …). Pass context.language for best results.
Can it block my agent? Yes — that's the point. A REJECTED verdict is designed to send the agent back to fix findings instead of presenting broken work. Your standing rule decides how hard the stop is.
What about false positives? Verdicts come with specific findings and the math, so they're auditable in seconds — you're never asked to trust a bare score.
Requests are authenticated with your personal token; keys are single-user and rate-limited, with key-sharing detection.
Code is processed to produce the verdict and is not used to train models.
initialize/tools/list are public (so clients and directories can introspect); every tools/call requires your key.
30-day free trial, then USD $30/month (launch offer: 50% off for 3 months). Volume and academic pricing: info@verificate.ai.
Every Bob needs a Wendy (IBM Community)
Built by Verificate Pty Ltd (Sydney, Australia) — an IBM Business Partner. Verificate builds sovereign AI infrastructure: the HELIX inference engine (calibrated confidence scores on every answer), the deterministic Decision Transformer, and this MCP validation server. Product page: https://verificate.ai/mcp · Official registry: ai.verificate/mcp
This repo (the stdio bridge, client configs and CI examples) is MIT — use it freely. The Verificate validation engine and hosted gateway it talks to are a commercial service (30-day free trial, then subscription): the 17 protection gates and the frontier-model review run server-side and are not part of this repository.
🌐 Not an English speaker? Install instructions in हिन्दी · Português · Bahasa Indonesia · Español · 中文 · Tiếng Việt → INSTALL.md
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to analyze — a function, file or pasted excerpt. | |
| language | No | Source language, e.g. 'python', 'typescript', 'cpp', 'sql', 'swift'. Inferred if omitted; stating it sharpens findings. | |
| analysis_type | No | Lens for the review: 'quality' (default, broad ISO/IEC 25010 pass) or a focused pass on one dimension. | quality |
| Name | Required | Description |
|---|---|---|
| issues | Yes | Findings as 'severity|category|detail' with supporting arithmetic |
| provider | No | |
| complexity | No | low | medium | high |
| suggestions | No | |
| quality_score | Yes | 0-100 advisory score for the chosen lens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, but the description reinforces and expands on them by stating the code is 'never executed' and that the tool intentionally avoids blocking verdicts. It also discloses the nature of output (scores, findings, latency arithmetic), adding meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The core purpose and key constraint (no pass/fail) are front-loaded, followed by concrete examples of output value and explicit alternative routing. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an analysis tool: it explains the advisory nature, read-only behavior, typical use cases, and the alternative decision tool. The output schema covers return details, and annotations cover safety. No critical missing guidance for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds context about analysis quality (e.g., 'performance hot paths, scalability cliffs') but does not materially clarify parameter syntax or formats beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb-resource pair ('Advisory deep-dive on existing code') and immediately differentiates itself from validate_ai_output by stating it deliberately offers no pass/fail verdict. This uniquely positions it against the sibling tools without requiring the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use scenarios ('understand a validate_ai_output rejection or review inherited code') and an explicit alternative ('use validate_ai_output when you need an accept/reject decision'). This removes any ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What to build, with any constraints worth enforcing — e.g. 'a rate-limited retry decorator with exponential backoff, stdlib only'. | |
| language | No | Target language for the generated code, e.g. 'python' (default), 'typescript', 'go', 'sql'. | python |
| max_tokens | No | Generation budget. The default 4000 fits most functions/classes; raise it for multi-file scaffolds. |
| Name | Required | Description |
|---|---|---|
| code | No | The generated implementation |
| attempts | No | Generation attempts before approval or give-up |
| provider | No | |
| generated | Yes | False only when no provider returned code |
| validated | No | True if the protection gates approved the final attempt; false means the gate findings in 'protection' explain the veto |
| protection | No | Deterministic gate result. A veto here is final — the model review cannot override it. |
| validation_score | No | Deterministic gate score, 0-100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond the annotations: retries generation when the gate rejects, returns the last attempt with validated:false if all attempts fail, and explicitly states 'rejected code is never presented as clean.' It also clarifies that generation runs on infrastructure and 'nothing executes in your environment,' aligning with readOnlyHint and providing safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the core action is front-loaded, the failure behavior is explained, and the security/safety boundary is stated. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are rich, the description covers what an agent needs: the generation-vetting workflow, failure fallback, and execution boundary. Nothing critical is missing for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so every parameter is already documented. The description adds context about generation and gating behavior but does not add meaning to specific parameters like prompt, language, or max_tokens. A baseline 3 is appropriate since schema already carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Generate code and gate it in one step.' It clearly distinguishes the tool from siblings by noting it uses 'the same protection engine as validate_ai_output' while adding the generation step. This immediately differentiates it from the validation-only sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating code that is then automatically vetted, but it does not explicitly say when to choose this over validate_ai_output or other siblings. Referencing validate_ai_output as the engine source hints at the relationship but does not provide explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional review context, e.g. {"language": "cpp", "scale": "10k req/s"}. 'language' sharpens SDK-reality checks. | |
| ai_output | Yes | The AI-generated code to gate — a diff, function or whole file. Plain source text, any mainstream language. | |
| validation_type | No | 'code_generation' (default) for source code; 'text' for prose output such as documentation or commit messages. | code_generation |
| Name | Required | Description |
|---|---|---|
| score | Yes | Combined score 0-100 (gates fused with the model review) |
| valid | Yes | The binary verdict: true = approved, false = rejected |
| issues | Yes | Severity-ranked findings, each 'severity|category|detail' with the reasoning |
| provider | No | Model that ran the deep review, or 'protection-gates-only' |
| confidence | No | score / 100 |
| protection | No | Deterministic gate result. A veto here is final — the model review cannot override it. |
| suggestions | No | Concrete fixes to reach approval |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, but the description goes further by stating 'Read-only: the code is analyzed, never executed,' explaining deterministic gates with veto power that 'cannot be overridden,' and describing the frontier-model scoring dimensions. This is rich behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense. The core verdict mechanism is front-loaded; subsequent sentences add behavior, use-case guidance, and alternatives without redundancy. Every sentence contributes distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need to explain return values. It covers purpose, when to use, safety behavior, parameter nuances, and examples of rejection logic. The tool is fully contextualized for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining that context 'language sharpens SDK-reality checks' and by distinguishing validation_type options ('code_generation' vs 'text'), deepening meaning beyond enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'The merge gate for AI-written CODE: returns a binary approve/reject verdict.' It immediately distinguishes the tool from siblings by naming validate_plan and analyze_code as alternatives for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit invocation guidance is given: 'Call it on every AI-generated diff before accepting it.' It also provides clear when-not/when-else direction: 'use validate_plan for plans, analyze_code for an advisory report without a verdict.' This fully covers selection vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | The implementation plan, design or spec to validate, as plain text or markdown — e.g. a numbered migration plan or an architecture sketch. | |
| context | No | Optional constraints the review should weigh, e.g. {"system": "payments API", "scale": "1M users", "constraints": "PostgreSQL only"}. |
| Name | Required | Description |
|---|---|---|
| score | Yes | Combined score 0-100 (gates fused with the model review) |
| valid | Yes | The binary verdict: true = approved, false = rejected |
| issues | Yes | Severity-ranked findings, each 'severity|category|detail' with the reasoning |
| provider | No | Model that ran the deep review, or 'protection-gates-only' |
| confidence | No | score / 100 |
| protection | No | Deterministic gate result. A veto here is final — the model review cannot override it. |
| suggestions | No | Concrete fixes to reach approval |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only: nothing is executed or stored beyond the verdict,' which adds concrete side-effect context beyond the annotations. It also describes the verdict shape and the categories of findings, such as security risks and request-volume feasibility checks. No contradiction with annotations; the description enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: gate/timing, verdict shape and findings, read-only guarantee, and routing to the sibling tool. It is front-loaded with the most important decision guidance and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers what it does, when to use it, what it returns, safety guarantees, and the key alternative. The output schema covers return-value structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the plan and context parameters with examples. The tool description does not substantially add parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: validate PLANS, designs and specs. It positions itself as 'the gate' before code is written and distinguishes itself from validate_ai_output for the code that follows. An agent can select this tool confidently without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance: run BEFORE any code is written. It also names the relevant alternative, 'Use validate_ai_output for the code that follows,' making the when-to-use and when-not-to-use boundary explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.8.6analyze_code5 fields changedInput schema / properties / analysis_type / descriptionPrevious value: -"quality | performance | scalability | security | tech_debt"New value: +"Lens for the review: 'quality' (default, broad ISO/IEC 25010 pass) or a focused pass on one dimension."Input schema / properties / analysis_type / enumAdded value: +[
+ "quality",
+ "performance",
+ "scalability",
+ "security",
+ "tech_debt"
+]Input schema / properties / code / descriptionPrevious value: -"Code to analyze"New value: +"The source code to analyze — a function, file or pasted excerpt."Input schema / properties / language / descriptionPrevious value: -"Source language (python, cpp, sql, swift, ...)"New value: +"Source language, e.g. 'python', 'typescript', 'cpp', 'sql', 'swift'. Inferred if omitted; stating it sharpens findings."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "complexity": {
+ "description": "low | medium | high",
+ "type": "string"
+ },
+ "issues": {
+ "description": "Findings as 'severity|category|detail' with supporting arithmetic",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "quality_score": {
+ "description": "0-100 advisory score for the chosen lens",
+ "type": "number"
+ },
+ "suggestions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "quality_score",
+ "issues"
+ ],
+ "type": "object"
+}generate_code6 fields changedInput schema / properties / language / descriptionAdded value: +"Target language for the generated code, e.g. 'python' (default), 'typescript', 'go', 'sql'."Input schema / properties / max_tokens / descriptionAdded value: +"Generation budget. The default 4000 fits most functions/classes; raise it for multi-file scaffolds."Input schema / properties / max_tokens / maximumAdded value: +32768Input schema / properties / max_tokens / minimumAdded value: +256Input schema / properties / prompt / descriptionPrevious value: -"Code generation prompt"New value: +"What to build, with any constraints worth enforcing — e.g. 'a rate-limited retry decorator with exponential backoff, stdlib only'."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "attempts": {
+ "description": "Generation attempts before approval or give-up",
+ "type": "integer"
+ },
+ "code": {
+ "description": "The generated implementation",
+ "type": "string"
+ },
+ "generated": {
+ "description": "False only when no provider returned code",
+ "type": "boolean"
+ },
+ "protection": {
+ "additionalProperties": true,
+ "description": "Deterministic gate result. A veto here is final — the model review cannot override it.",
+ "properties": {
+ "protection_score": {
+ "description": "Deterministic gate score, 0-100",
+ "type": "number"
+ },
+ "verdict": {
+ "description": "'approved' or 'rejected' from the gate layer",
+ "type": "string"
+ },
+ "vetoed": {
+ "description": "True if any veto gate failed the submission",
+ "type": "boolean"
+ },
+ "vetoed_by": {
+ "description": "Names of the gates that vetoed, e.g. ['code_reality_gate']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "validated": {
+ "description": "True if the protection gates approved the final attempt; false means the gate findings in 'protection' explain the veto",
+ "type": "boolean"
+ },
+ "validation_score": {
+ "description": "Deterministic gate score, 0-100",
+ "type": "number"
+ }
+ },
+ "required": [
+ "generated"
+ ],
+ "type": "object"
+}validate_ai_output5 fields changedInput schema / properties / ai_output / descriptionPrevious value: -"Code, plan, or output to validate"New value: +"The AI-generated code to gate — a diff, function or whole file. Plain source text, any mainstream language."Input schema / properties / context / descriptionPrevious value: -"Context, e.g. {\"language\": \"cpp\"}"New value: +"Optional review context, e.g. {\"language\": \"cpp\", \"scale\": \"10k req/s\"}. 'language' sharpens SDK-reality checks."Input schema / properties / validation_type / descriptionPrevious value: -"code_generation | plan | design | architecture | text"New value: +"'code_generation' (default) for source code; 'text' for prose output such as documentation or commit messages."Input schema / properties / validation_type / enumAdded value: +[
+ "code_generation",
+ "text"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "confidence": {
+ "description": "score / 100",
+ "type": "number"
+ },
+ "issues": {
+ "description": "Severity-ranked findings, each 'severity|category|detail' with the reasoning",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "protection": {
+ "additionalProperties": true,
+ "description": "Deterministic gate result. A veto here is final — the model review cannot override it.",
+ "properties": {
+ "protection_score": {
+ "description": "Deterministic gate score, 0-100",
+ "type": "number"
+ },
+ "verdict": {
+ "description": "'approved' or 'rejected' from the gate layer",
+ "type": "string"
+ },
+ "vetoed": {
+ "description": "True if any veto gate failed the submission",
+ "type": "boolean"
+ },
+ "vetoed_by": {
+ "description": "Names of the gates that vetoed, e.g. ['code_reality_gate']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "provider": {
+ "description": "Model that ran the deep review, or 'protection-gates-only'",
+ "type": "string"
+ },
+ "score": {
+ "description": "Combined score 0-100 (gates fused with the model review)",
+ "type": "number"
+ },
+ "suggestions": {
+ "description": "Concrete fixes to reach approval",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "valid": {
+ "description": "The binary verdict: true = approved, false = rejected",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "valid",
+ "score",
+ "issues"
+ ],
+ "type": "object"
+}validate_plan3 fields changedInput schema / properties / context / descriptionPrevious value: -"Optional context (system, constraints, scale targets)"New value: +"Optional constraints the review should weigh, e.g. {\"system\": \"payments API\", \"scale\": \"1M users\", \"constraints\": \"PostgreSQL only\"}."Input schema / properties / plan / descriptionPrevious value: -"The plan/design/spec to validate"New value: +"The implementation plan, design or spec to validate, as plain text or markdown — e.g. a numbered migration plan or an architecture sketch."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "confidence": {
+ "description": "score / 100",
+ "type": "number"
+ },
+ "issues": {
+ "description": "Severity-ranked findings, each 'severity|category|detail' with the reasoning",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "protection": {
+ "additionalProperties": true,
+ "description": "Deterministic gate result. A veto here is final — the model review cannot override it.",
+ "properties": {
+ "protection_score": {
+ "description": "Deterministic gate score, 0-100",
+ "type": "number"
+ },
+ "verdict": {
+ "description": "'approved' or 'rejected' from the gate layer",
+ "type": "string"
+ },
+ "vetoed": {
+ "description": "True if any veto gate failed the submission",
+ "type": "boolean"
+ },
+ "vetoed_by": {
+ "description": "Names of the gates that vetoed, e.g. ['code_reality_gate']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "provider": {
+ "description": "Model that ran the deep review, or 'protection-gates-only'",
+ "type": "string"
+ },
+ "score": {
+ "description": "Combined score 0-100 (gates fused with the model review)",
+ "type": "number"
+ },
+ "suggestions": {
+ "description": "Concrete fixes to reach approval",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "valid": {
+ "description": "The binary verdict: true = approved, false = rejected",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "valid",
+ "score",
+ "issues"
+ ],
+ "type": "object"
+}v0.1.0analyze_codegenerate_codevalidate_ai_outputvalidate_planScored 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.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Build and test FaceSign step-up verification flows from your AI coding tool
