Skip to main content
Glama

Verificate MCP

by ai.verificate
OverviewAdmin

Server Details

Agentic code review, no signup to try: reality gates + frontier-model review, with veto.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
VerificateAI/verificate-mcp-quickstart
GitHub Stars
1
Server Listing
Verificate MCP

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct lifecycle stage: analyze_code gives advisory feedback, validate_plan gates designs, validate_ai_output gates deliverables, validate_artifact checks deployable readiness, and generate_code combines generation with gating. Descriptions explicitly cross-reference when to use each, eliminating ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase with underscores: analyze_code, generate_code, validate_ai_output, validate_artifact, validate_plan. The verb clearly indicates the action and the object clarifies the target, making the naming predictable and readable.

Tool Count5/5

Five tools is well-scoped for a verification/gating server, covering analysis, generation, output validation, plan validation, and artifact validation without redundancy. Each tool earns its place and the count is appropriate for the clearly defined domain.

Completeness5/5

The tool surface covers the full lifecycle of AI-generated work: plan before coding, generate code, validate any AI output, analyze existing code, and check production readiness. There are no obvious gaps—every critical gate from plan to deployment is represented.

Available Tools

5 tools
analyze_codeAdvisory code deep-diveA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe source code to analyze — a function, file or pasted excerpt.
languageNoSource language, e.g. 'python', 'typescript', 'cpp', 'sql', 'swift'. Inferred if omitted; stating it sharpens findings.
analysis_typeNoLens for the review: 'quality' (default, broad ISO/IEC 25010 pass) or a focused pass on one dimension.quality

Output Schema

ParametersJSON Schema
NameRequiredDescription
issuesYesFindings as 'severity|category|detail' with supporting arithmetic
providerNo
complexityNolow | medium | high
suggestionsNo
quality_scoreYes0-100 advisory score for the chosen lens

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_codeGenerate gated codeA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesWhat to build, with any constraints worth enforcing — e.g. 'a rate-limited retry decorator with exponential backoff, stdlib only'.
languageNoTarget language for the generated code, e.g. 'python' (default), 'typescript', 'go', 'sql'.python
max_tokensNoGeneration budget. The default 4000 fits most functions/classes; raise it for multi-file scaffolds.

Output Schema

ParametersJSON Schema
NameRequiredDescription
codeNoThe generated implementation
attemptsNoGeneration attempts before approval or give-up
providerNo
generatedYesFalse only when no provider returned code
validatedNoTrue if the protection gates approved the final attempt; false means the gate findings in 'protection' explain the veto
protectionNoDeterministic gate result. A veto here is final — the model review cannot override it.
validation_scoreNoDeterministic gate score, 0-100

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.

validate_ai_outputGate AI-written output (code or documents)A
Read-onlyIdempotent
Inspect

The merge gate for ANY AI-written output — code, documentation, reports, emails, configs: returns a binary approve/reject verdict with veto power — e.g. it rejects code calling the nonexistent stripe.Inventory API, an N+1 loop with the latency arithmetic to prove it, or a doc claiming success with no evidence. 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 quality, accuracy, reliability and tech debt. In a benchmark, a frontier model reviewing alone caught reward-gaming and hallucinated APIs 0/6 times in a natural review workflow; these gates catch them deterministically on every call. Read-only: nothing is executed. Call it on every AI-generated deliverable before accepting it; use validate_plan for plans, analyze_code for an advisory report without a verdict.

ParametersJSON Schema
NameRequiredDescriptionDefault
contextNoOptional review context — an object like {"language": "cpp", "scale": "10k req/s"} ('language' sharpens SDK-reality checks) or a free-text sentence describing intent.
ai_outputYesThe AI-generated output to gate — source code (a diff, function or whole file, any mainstream language) or prose (documentation, a report, an email, release notes). For reliable latency keep one submission under ~15,000 characters; split larger artifacts at natural boundaries (functions, SQL statements, sections) and validate the units separately. Reviews are wall-clock bounded: an over-budget model review returns an explicit timed-out result (deterministic gates still run) rather than hanging.
validation_typeNoWhat the output is: 'code_generation' (default) for source code; 'documentation', 'report', 'email', 'text', ... for prose (code-marker gates are skipped, integrity gates and the frontier review still run); 'plan' for designs/specs.code_generation

Output Schema

ParametersJSON Schema
NameRequiredDescription
scoreYesCombined score 0-100 (gates fused with the model review)
validYesThe binary verdict: true = approved, false = rejected
issuesYesSeverity-ranked findings, each 'severity|category|detail' with the reasoning
providerNoModel that ran the deep review, or 'protection-gates-only'
confidenceNoscore / 100
protectionNoDeterministic gate result. A veto here is final — the model review cannot override it.
suggestionsNoConcrete fixes to reach approval

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint/idempotentHint, and the description adds substantial behavior: 'veto power,' deterministic gates that 'cannot be overridden,' the frontier-model review step, the timeout behavior, and a benchmark demonstrating why the gates exist. It explicitly confirms 'Read-only: nothing is executed,' matching the annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than a typical tool definition, but every sentence earns its place: purpose, examples, deterministic-gate mechanics, benchmark evidence, read-only confirmation, and sibling routing. It front-loads the core function before diving into details. The benchmark sentence is slightly tangential but supports the tool's value proposition.

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?

The description is remarkably complete: it explains the returned binary verdict, the two-stage review process, timeout behavior, read-only safety, when to use it, and which sibling to choose for alternatives. The output schema presumably covers the return shape; nothing critical for an agent to call this correctly is missing.

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?

Schema description coverage is 100% with detailed parameter explanations (including the 15,000-character guidance and validation_type meanings). The tool description itself adds little parameter-specific semantics; it focuses on tool-level purpose and sibling routing. Baseline 3 is appropriate because the schema already carries the parameter 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 clearly states a specific verb ('gate'), a resource ('ANY AI-written output'), and the binary verdict behavior. It distinguishes the tool from siblings by naming validate_plan and analyze_code as alternatives, so an agent can immediately tell this is the merge-gate tool and not an advisory analyzer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs 'Call it on every AI-generated deliverable before accepting it' and gives when-not conditions by pointing to siblings: 'use validate_plan for plans, analyze_code for an advisory report without a verdict.' This is direct, unambiguous usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_artifactGate a deployable artifact against the Verificate production doctrineAInspect

Deterministic production-readiness gate for AI-built systems. Verifies the invariants that stop a system silently shipping broken: every critical component is PRESENT and LOADS, the import closure resolves (nothing assumed 'already on the box'), all runtime dependencies are declared, and health is a REAL fail-closed check. Returns approve/reject with a fix plan and ISO 27001 / ISO 5055 control evidence. Facts are gathered by the Verificate collector in your CI; the gate is the authority. Non-bypassable, fails closed. This is the control-plane sibling of validate_ai_output — code quality is one invariant; this gates the whole deployable.

ParametersJSON Schema
NameRequiredDescriptionDefault
artifactYesCollected artifact facts: {critical_components:[{name,loads:bool}], import_closure_ok:bool, undeclared_deps:[str], health_truthful:bool}.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool is 'deterministic,' 'non-bypassable,' 'fails closed,' and that it 'Returns approve/reject with a fix plan and ISO 27001 / ISO 5055 control evidence.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and enumerates invariants efficiently. It is slightly repetitive, with 'fails closed' appearing twice ('fail-closed check' and 'Non-bypassable, fails closed'), but every sentence otherwise contributes distinct value.

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?

Despite having no output schema, the description explains the return value ('approve/reject with a fix plan and ISO 27001 / ISO 5055 control evidence'), the input provenance, the behavioral guarantees, and the relationship to siblings. For a single-parameter tool, this is complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the schema already documents the artifact object's structure. The description adds meaningful provenance context beyond the schema: facts come from 'the Verificate collector in your CI' and the gate itself is the authority, which helps an agent know what to pass.

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 opens with a specific verb and resource: 'Deterministic production-readiness gate for AI-built systems,' and enumerates the exact invariants verified. It also distinguishes itself from a sibling: 'This is the control-plane sibling of validate_ai_output — code quality is one invariant; this gates the whole deployable.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts this tool with validate_ai_output and clarifies which concern each gates, saying code quality is 'one invariant' while this tool gates the whole deployable. It also states the prerequisite context: 'Facts are gathered by the Verificate collector in your CI; the gate is the authority.' This gives an agent clear routing between alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_planGate an implementation planA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
planYesThe implementation plan, design or spec to validate, as plain text or markdown — e.g. a numbered migration plan or an architecture sketch.
contextNoOptional constraints the review should weigh, e.g. {"system": "payments API", "scale": "1M users", "constraints": "PostgreSQL only"}.

Output Schema

ParametersJSON Schema
NameRequiredDescription
scoreYesCombined score 0-100 (gates fused with the model review)
validYesThe binary verdict: true = approved, false = rejected
issuesYesSeverity-ranked findings, each 'severity|category|detail' with the reasoning
providerNoModel that ran the deep review, or 'protection-gates-only'
confidenceNoscore / 100
protectionNoDeterministic gate result. A veto here is final — the model review cannot override it.
suggestionsNoConcrete fixes to reach approval

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updates
    • Changedvalidate_ai_output1 field changed
      • changedInput schema / properties / ai_output / description
        Previous value: -"The AI-generated output to gate — source code (a diff, function or whole file, any mainstream language) or prose (documentation, a report, an email, release notes)."New value: +"The AI-generated output to gate — source code (a diff, function or whole file, any mainstream language) or prose (documentation, a report, an email, release notes). For reliable latency keep one submission under ~15,000 characters; split larger artifacts at natural boundaries (functions, SQL statements, sections) and validate the units separately. Reviews are wall-clock bounded: an over-budget model review returns an explicit timed-out result (deterministic gates still run) rather than hanging."
    • Addedvalidate_artifact
  2. 1 tool update
    • Changedvalidate_ai_output5 fields changed
      • changedInput schema / properties / ai_output / description
        Previous value: -"The AI-generated code to gate — a diff, function or whole file. Plain source text, any mainstream language."New value: +"The AI-generated output to gate — source code (a diff, function or whole file, any mainstream language) or prose (documentation, a report, an email, release notes)."
      • changedInput schema / properties / context / description
        Previous value: -"Optional review context, e.g. {\"language\": \"cpp\", \"scale\": \"10k req/s\"}. 'language' sharpens SDK-reality checks."New value: +"Optional review context — an object like {\"language\": \"cpp\", \"scale\": \"10k req/s\"} ('language' sharpens SDK-reality checks) or a free-text sentence describing intent."
      • changedInput schema / properties / context / type
        Previous value: -"object"New value: +[
+  "object",
+  "string"
+]
      • changedInput schema / properties / validation_type / description
        Previous value: -"'code_generation' (default) for source code; 'text' for prose output such as documentation or commit messages."New value: +"What the output is: 'code_generation' (default) for source code; 'documentation', 'report', 'email', 'text', ... for prose (code-marker gates are skipped, integrity gates and the frontier review still run); 'plan' for designs/specs."
      • removedInput schema / properties / validation_type / enum
        Removed value: -[
-  "code_generation",
-  "text"
-]
  3. 4 tool updates
    • Changedanalyze_code5 fields changed
      • changedInput schema / properties / analysis_type / description
        Previous 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."
      • addedInput schema / properties / analysis_type / enum
        Added value: +[
+  "quality",
+  "performance",
+  "scalability",
+  "security",
+  "tech_debt"
+]
      • changedInput schema / properties / code / description
        Previous value: -"Code to analyze"New value: +"The source code to analyze — a function, file or pasted excerpt."
      • changedInput schema / properties / language / description
        Previous 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."
      • changedOutput 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"
+}
    • Changedgenerate_code6 fields changed
      • 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"
+}
    • Changedvalidate_ai_output5 fields changed
      • changedInput schema / properties / ai_output / description
        Previous value: -"The AI-generated code to gate"New value: +"The AI-generated code to gate — a diff, function or whole file. Plain source text, any mainstream language."
      • changedInput schema / properties / context / description
        Previous value: -"Context, e.g. {\"language\": \"cpp\"}"New value: +"Optional review context, e.g. {\"language\": \"cpp\", \"scale\": \"10k req/s\"}. 'language' sharpens SDK-reality checks."
      • changedInput schema / properties / validation_type / description
        Previous value: -"code_generation (default) | text"New value: +"'code_generation' (default) for source code; 'text' for prose output such as documentation or commit messages."
      • addedInput schema / properties / validation_type / enum
        Added value: +[
+  "code_generation",
+  "text"
+]
      • changedOutput 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"
+}
    • Changedvalidate_plan3 fields changed
      • changedInput schema / properties / context / description
        Previous 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\"}."
      • changedInput schema / properties / plan / description
        Previous 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."
      • changedOutput 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"
+}
  4. 1 tool update
    • Changedvalidate_ai_output2 fields changed
      • changedInput schema / properties / ai_output / description
        Previous value: -"Code, plan, or output to validate"New value: +"The AI-generated code to gate"
      • changedInput schema / properties / validation_type / description
        Previous value: -"code_generation | plan | design | architecture | text"New value: +"code_generation (default) | text"
  5. 4 tool updates
    • First observedanalyze_code
    • First observedgenerate_code
    • First observedvalidate_ai_output
    • First observedvalidate_plan

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • ai-architect

    cdeust
    A
    license
    Not graded
    quality
    F
    maintenance
    An autonomous software-engineering pipeline for Claude Code that runs on real evidence: codebase intelligence tools, git analytics, deterministic verification rules, and zero LLM-judges-LLM. Every claim traces to a paper and every PR passes its own gates.
    1
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources