Verificate MCP

Official

by VerificateAI

Overview Schema Source Related Servers Discussions(2)Admin

JavaScript

Remote

Generate gated code

generate_code

Read-only

Generate code with built-in validation, retrying when gates reject. If all attempts fail, returns the last attempt clearly marked as unvalidated, so unverified code is never presented as clean.

Instructions

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.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.8.6Jul 31, 2026

addedInput schema / properties / language / description

Added value: +"Target language for the generated code, e.g. 'python' (default), 'typescript', 'go', 'sql'."

addedInput schema / properties / max_tokens / description

Added value: +"Generation budget. The default 4000 fits most functions/classes; raise it for multi-file scaffolds."

addedInput schema / properties / max_tokens / maximum
```
Added value: +32768
```
addedInput schema / properties / max_tokens / minimum
```
Added value: +256
```

changedInput schema / properties / prompt / description

Previous 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'."

changedOutput 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"
+}

First observedv0.1.0Jul 31, 2026

TDQS

A4.3/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Deploy Server