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

Check an MCP server for conformance and disclosure

check_conformance

Read-only

Measure a public MCP endpoint against five conditions: it speaks MCP, it publishes an A2A agent card, it declares who pays it, identical input returns identical output, and the verdict itself can be recomputed by anyone. Free, no key. Conformance and disclosure only; this says nothing about whether any figure the checked server returns is correct. By default no tool on the checked server is called, so determinism comes back as not measured rather than guessed. It is measured when the owner has published /.well-known/mcp-conduct.json with allow_tool_call true.

Input Schema

Name	Required	Description	Default
`endpoint`	Yes	https URL of the MCP endpoint to measure
`allow_tool_call`	No	Kept for compatibility. Since 2026-10-08 an assertion alone calls no tool: consent is proven only by the owner's /.well-known/mcp-conduct.json. Default false.

Output Schema

Name	Required	Description
`gate`	No	Name of this gate.
`checks`	No	One entry per condition, each with whether it was measured, whether it passed, and the detail.
`status`	No	verified = every measured condition passed. pending = measured, not all passing. held = could not be reached, nothing established.
`endpoint`	No	The MCP endpoint that was measured.
`reachable`	No	Three-valued on purpose (gate58). true = measured and answered. false = measured and did not answer. null = NOT MEASURED. null is never to be read as a failing endpoint; it means this gate has nothing to say.
`checked_at`	No	When the measurement started, ISO 8601 UTC.
`probed_via`	No	The network path the probe took (relay or direct).
`scope_note`	No	What this measurement covers and what it does not.
`establishes`	No	What this verdict establishes, as sentences.
`gate_commit`	No	Git commit of the deployed gate, or a sentence saying the deployment did not pin one.
`gate_version`	No	Version of the gate code that took this measurement.
`tools_called`	No	Whether a tool on the checked server was executed, in words.
`consent_basis`	No	On what basis a tool call was or was not made.
`number_safety`	No	Whether every number in this verdict survives a JSON round trip unchanged.
`record_sha256`	No	Hash of this verdict with record_sha256 and recompute_note removed. Recompute it yourself; verify_verdict does the same arithmetic.
`consent_lookup`	No	Present when no proven consent was found: the consent file that was read, the result, and how to consent.
`consent_source`	No	Where the consent came from: operator_list, well_known, requester or none.
`recompute_note`	No	How to recompute record_sha256. Not part of the hashed bytes.
`canonicalization`	No	Condition 07, disclosed and never a verdict: whether the declared tool surface canonicalizes under RFC 8785.
`measurement_note`	No	Present only when the gate's own relay failed, so that nothing here is read as a statement about the target.
`absence_vs_failure`	No	Condition 06, disclosed and never a verdict: whether the server's tools can tell a failed lookup from an empty one.
`does_not_establish`	No	What this verdict does not establish, as sentences.
`coordinate_derivation`	No	How the measured tool and instant were derived, or that the legacy rule applied.
`consent_assertion_ignored`	No	Present when the request set allow_tool_call true without proven consent: the assertion was recorded and no tool was called.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

changedInput schema / properties / allow_tool_call / description

Previous value: -"Consent to executing one tool on the checked server, twice, with empty arguments. Only set this for a server you own. Default false."New value: +"Kept for compatibility. Since 2026-10-08 an assertion alone calls no tool: consent is proven only by the owner's /.well-known/mcp-conduct.json. Default false."

addedOutput schema / properties / consent_assertion_ignored

Added value: +{
+  "description": "Present when the request set allow_tool_call true without proven consent: the assertion was recorded and no tool was called.",
+  "type": "object"
+}

Changed24 schema fields changedOct 7, 2026

addedOutput schema / properties / absence_vs_failure

Added value: +{
+  "description": "Condition 06, disclosed and never a verdict: whether the server's tools can tell a failed lookup from an empty one.",
+  "type": "object"
+}

addedOutput schema / properties / canonicalization

Added value: +{
+  "description": "Condition 07, disclosed and never a verdict: whether the declared tool surface canonicalizes under RFC 8785.",
+  "type": "object"
+}

addedOutput schema / properties / checked_at

Added value: +{
+  "description": "When the measurement started, ISO 8601 UTC.",
+  "type": "string"
+}

addedOutput schema / properties / checks

Added value: +{
+  "description": "One entry per condition, each with whether it was measured, whether it passed, and the detail.",
+  "type": "object"
+}

removedOutput schema / properties / conditions

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

addedOutput schema / properties / consent_basis

Added value: +{
+  "description": "On what basis a tool call was or was not made.",
+  "type": "string"
+}

addedOutput schema / properties / consent_lookup

Added value: +{
+  "description": "Present when no proven consent was found: the consent file that was read, the result, and how to consent.",
+  "type": "object"
+}

addedOutput schema / properties / consent_source

Added value: +{
+  "description": "Where the consent came from: operator_list, well_known, requester or none.",
+  "type": "string"
+}

addedOutput schema / properties / coordinate_derivation

Added value: +{
+  "description": "How the measured tool and instant were derived, or that the legacy rule applied.",
+  "type": "object"
+}

addedOutput schema / properties / does_not_establish

Added value: +{
+  "description": "What this verdict does not establish, as sentences.",
+  "type": "array"
+}

addedOutput schema / properties / endpoint / description
```
Added value: +"The MCP endpoint that was measured."
```

addedOutput schema / properties / establishes

Added value: +{
+  "description": "What this verdict establishes, as sentences.",
+  "type": "array"
+}

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 / gate_version

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

addedOutput schema / properties / measurement_note

Added value: +{
+  "description": "Present only when the gate's own relay failed, so that nothing here is read as a statement about the target.",
+  "type": "string"
+}

addedOutput schema / properties / number_safety

Added value: +{
+  "description": "Whether every number in this verdict survives a JSON round trip unchanged.",
+  "type": "object"
+}

removedOutput schema / properties / pass

Removed value: -{
-  "type": [
-    "boolean",
-    "null"
-  ]
-}

addedOutput schema / properties / probed_via

Added value: +{
+  "description": "The network path the probe took (relay or direct).",
+  "type": "string"
+}

addedOutput schema / properties / reachable / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```

addedOutput schema / properties / recompute_note / description

Added value: +"How to recompute record_sha256. Not part of the hashed bytes."

addedOutput schema / properties / scope_note

Added value: +{
+  "description": "What this measurement covers and what it does not.",
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "verified = every measured condition passed. pending = measured, not all passing. held = could not be reached, nothing established.",
+  "type": "string"
+}

addedOutput schema / properties / tools_called

Added value: +{
+  "description": "Whether a tool on the checked server was executed, in words.",
+  "type": "string"
+}

Changed1 schema field changedAug 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "conditions": {
+      "type": [
+        "array",
+        "object"
+      ]
+    },
+    "endpoint": {
+      "type": "string"
+    },
+    "pass": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "reachable": {
+      "description": "Three-valued on purpose (gate58). true = measured and answered. false = measured and did not answer. null = NOT MEASURED. null is never to be read as a failing endpoint; it means this gate has nothing to say."
+    },
+    "recompute_note": {
+      "type": "string"
+    },
+    "record_sha256": {
+      "description": "Hash of this verdict with record_sha256 and recompute_note removed. Recompute it yourself; verify_verdict does the same arithmetic.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedAug 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint=false, destructiveHint=false), it discloses cost and auth ('Free, no key'), the default side-effect posture on the target ('no tool on the checked server is called'), the consent mechanism that changes that, and what happens to the determinism result when unmeasured. This is exactly the extra behavioral context annotations cannot carry, and nothing contradicts them.

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 purpose and the five conditions are front-loaded, and each subsequent sentence carries a distinct constraint (cost, scope, side effects, consent). Some of the consent wording duplicates the allow_tool_call schema description, a minor 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?

An output schema exists, so return format need not be described. For a two-parameter, read-only checking tool the description covers purpose, scope limits, cost, side-effect default, and the consent precondition, leaving no obvious gap an agent would need to guess at.

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% and the schema already explains both parameters, so the baseline is 3. The description adds real value by explaining the consequence of the consent flag: determinism returns as 'not measured rather than guessed' unless the owner publishes /.well-known/mcp-conduct.json.

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 names a specific verb and resource ('Measure a public MCP endpoint') and enumerates the five conditions checked, which makes its function unmistakable. It never names or contrasts itself with the closest siblings (verify_verdict, preflight_agent), so an agent could still wonder which checking tool applies, keeping it short of a 5.

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 clear context for use (a public MCP endpoint, free, no key) and one explicit scope exclusion ('says nothing about whether any figure the checked server returns is correct'). It does not state when to prefer a sibling such as verify_verdict or is_verified instead, so routing guidance is incomplete.

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.