MCP Verification Gate: check an MCP server or an A2A agent before you connect or delegate

Get the conformance conditions

get_conditions

Read-onlyIdempotent

Return the five conditions this gate measures, what it explicitly does not verify, and the tier definitions. Takes no arguments and returns identical output every time. Read this before running a check so you know what a verdict does and does not claim.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`gate`	No	Name of this gate.
`tiers`	No	The status words a verdict can carry and what each one means.
`lookup`	No	How to read the register for one endpoint before connecting (GET /register/lookup).
`consent`	No	When this gate calls a tool on a checked server, and what counts as the owner's consent.
`version`	No	Version of the gate code that produced this document.
`operator`	No	Who operates this gate.
`red_team`	No	The adversarial test suite this gate is run against, with its scores by version.
`conditions`	No	The measured conditions, keyed by condition id, each with what is measured and how.
`gate_commit`	No	Git commit of the deployed gate, or a sentence saying the deployment did not pin one.
`reachability`	No	How an answer from the server is told apart from a failure to reach it (pending versus held).
`record_bytes`	No	Where the exact bytes that record_sha256 hashes are served, and since when.
`self_applied`	No	Statement that this gate is measured under its own conditions.
`number_safety`	No	How numbers in a verdict are kept recomputable across JSON implementations.
`instant_coordinate`	No	How the time of a scheduled measurement and the measured tool are derived rather than chosen.
`well_known_consent`	No	The consent file an origin can publish, its path and its fields.
`what_this_verifies`	No	The claims a verdict from this gate supports, as sentences.
`also_measured_no_verdict`	No	Measurements that are disclosed and never change a verdict.
`what_this_does_not_verify`	No	What a verdict from this gate never supports, as sentences.
`establishes_and_does_not_establish`	No	What a verdict establishes and what it does not, as two lists.

Schema Changelog

Changes observed during successful MCP inspections.

Changed22 schema fields changedOct 7, 2026

addedOutput schema / properties / also_measured_no_verdict

Added value: +{
+  "description": "Measurements that are disclosed and never change a verdict.",
+  "type": "object"
+}

addedOutput schema / properties / conditions / description

Added value: +"The measured conditions, keyed by condition id, each with what is measured and how."

changedOutput schema / properties / conditions / type

Previous value: -[
-  "array",
-  "object"
-]New value: +"object"

addedOutput schema / properties / consent

Added value: +{
+  "description": "When this gate calls a tool on a checked server, and what counts as the owner's consent.",
+  "type": "string"
+}

addedOutput schema / properties / establishes_and_does_not_establish

Added value: +{
+  "description": "What a verdict establishes and what it does not, as two lists.",
+  "type": "object"
+}

addedOutput schema / properties / gate

Added value: +{
+  "description": "Name of this gate.",
+  "type": "string"
+}

addedOutput schema / properties / gate_commit

Added value: +{
+  "description": "Git commit of the deployed gate, or a sentence saying the deployment did not pin one.",
+  "type": "string"
+}

addedOutput schema / properties / instant_coordinate

Added value: +{
+  "description": "How the time of a scheduled measurement and the measured tool are derived rather than chosen.",
+  "type": "object"
+}

addedOutput schema / properties / lookup

Added value: +{
+  "description": "How to read the register for one endpoint before connecting (GET /register/lookup).",
+  "type": "object"
+}

removedOutput schema / properties / not_verified

Removed value: -{
-  "type": [
-    "array",
-    "object",
-    "string"
-  ]
-}

addedOutput schema / properties / number_safety

Added value: +{
+  "description": "How numbers in a verdict are kept recomputable across JSON implementations.",
+  "type": "object"
+}

addedOutput schema / properties / operator

Added value: +{
+  "description": "Who operates this gate.",
+  "type": "string"
+}

addedOutput schema / properties / reachability

Added value: +{
+  "description": "How an answer from the server is told apart from a failure to reach it (pending versus held).",
+  "type": "string"
+}

addedOutput schema / properties / record_bytes

Added value: +{
+  "description": "Where the exact bytes that record_sha256 hashes are served, and since when.",
+  "type": "object"
+}

addedOutput schema / properties / red_team

Added value: +{
+  "description": "The adversarial test suite this gate is run against, with its scores by version.",
+  "type": "string"
+}

addedOutput schema / properties / self_applied

Added value: +{
+  "description": "Statement that this gate is measured under its own conditions.",
+  "type": "string"
+}

addedOutput schema / properties / tiers / description

Added value: +"The status words a verdict can carry and what each one means."

changedOutput schema / properties / tiers / type

Previous value: -[
-  "array",
-  "object"
-]New value: +"object"

addedOutput schema / properties / version

Added value: +{
+  "description": "Version of the gate code that produced this document.",
+  "type": "string"
+}

addedOutput schema / properties / well_known_consent

Added value: +{
+  "description": "The consent file an origin can publish, its path and its fields.",
+  "type": "object"
+}

addedOutput schema / properties / what_this_does_not_verify

Added value: +{
+  "description": "What a verdict from this gate never supports, as sentences.",
+  "type": "array"
+}

addedOutput schema / properties / what_this_verifies

Added value: +{
+  "description": "The claims a verdict from this gate supports, as sentences.",
+  "type": "array"
+}

Changed1 schema field changedAug 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Deterministic. Takes no arguments, looks nothing up, and returns the same document every time. It therefore declares no read-state field, and a structural probe will score it as unable to hold the difference between a failed read and an empty one. That score is correct and is left standing: this tool has no read to fail. Adding a state field it can never use would make the number look better and mean less.",
+  "properties": {
+    "conditions": {
+      "type": [
+        "array",
+        "object"
+      ]
+    },
+    "not_verified": {
+      "type": [
+        "array",
+        "object",
+        "string"
+      ]
+    },
+    "tiers": {
+      "type": [
+        "array",
+        "object"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedAug 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds genuine context beyond that: the output is deterministic ('identical output every time') and, importantly, it discloses what the tool does not claim to verify, which is a semantic boundary the annotations cannot express.

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?

Two sentences, zero padding. It front-loads the payload contents and puts the usage instruction last, which is the right order for a reference-lookup tool.

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?

An output schema exists, so the description is not obligated to describe return values. Given a no-arg, deterministic read tool, the description covers everything an agent needs: what it returns, that it is stable, and when to read it.

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?

Zero parameters, so the baseline per the rubric is 4. The description correctly reinforces this with 'takes no arguments', leaving no ambiguity about call shape.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 (return the five conditions this gate measures) and enumerates the payload contents (what it does not verify, tier definitions). It differentiates itself from the check-running siblings by framing itself as the reference read that precedes a check, though it does not name check_conformance or verify_verdict explicitly.

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

Usage Guidelines4/5

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

It gives a clear condition for use: read this before running a check so you know what a verdict does and does not claim. That establishes ordering relative to the check/verify siblings, but it does not spell out when this is unnecessary or name the alternatives it complements.

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

All MCP Verification Gate: check an MCP server or an A2A agent before you connect or delegate tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.