Verificate MCP

Official

by VerificateAI

Overview Schema Source Related Servers Discussions(2)Admin

JavaScript

Remote

Advisory code deep-dive

analyze_code

Read-onlyIdempotent

Deep-dive into existing code with quantified findings on performance, scalability, and tech debt. Read-only advisory with no pass/fail verdict, so it never blocks an agent.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.8.6Jul 31, 2026

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

First observedv0.1.0Jul 31, 2026

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.

Deploy Server