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

Before delegating: check an A2A agent's card, who pays it, and its register reading

preflight_agent

Read-onlyIdempotent

Call this before handing work to an A2A agent you have not used before. Fetches the agent's public card (https:///.well-known/agent-card.json, one request), reports whether it declares the A2A Conduct Extension, who it says pays it (the compensation declaration, as declared and not verified), whether the card carries a signature, the endpoints it asks to be measured on, and this register's stored reading for each (verified is true only when the latest scheduled measurement passed; null otherwise, never false), plus where to file your own witness walk. Measures nothing new and returns counts and pointers, never a score. An agent that does not declare the extension is reported as such, which is not a negative verdict.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent`	Yes	https origin of the agent (https://agent.example) or the full URL of its agent card

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No	Always true in this object: the card was fetched and read.
`agent`	No	The agent's https origin.
`schema`	No	Format name of this object: gate-preflight-v1.
`card_url`	No	The agent card URL that was fetched.
`register`	No	This register's stored reading for each of those endpoints: state, verified (true or null, never false), record_sha256.
`card_status`	No	HTTP status the card URL answered with.
`how_to_file`	No	How to walk the agent yourself and file your own record.
`compensation`	No	Who the agent says pays it, as declared and not verified, or null when it says nothing.
`declared_uri`	No	The extension URI the card declared, or null.
`conduct_record`	No	Where the card says its conduct record is published, or null.
`witness_intake`	No	Where the card says witness records can be filed, or null.
`does_not_establish`	No	What this reading does not establish, as sentences.
`extension_declared`	No	true = the card declares the A2A Conduct Extension. false is not a negative verdict.
`measured_endpoints`	No	The https endpoints the card asks to be measured on, at most 5.
`compensation_source`	No	Where the compensation declaration was read: extension params or card top-level.
`card_signature_present`	No	Whether the card carries a signature. Presence only; the signature is not verified here.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "What the agent's public card declares and what this register holds for the endpoints it names. Counts and pointers, never a score. A card that could not be fetched or read comes back as a tool error (isError), not as this object.",
+  "properties": {
+    "agent": {
+      "description": "The agent's https origin.",
+      "type": "string"
+    },
+    "card_signature_present": {
+      "description": "Whether the card carries a signature. Presence only; the signature is not verified here.",
+      "type": "boolean"
+    },
+    "card_status": {
+      "description": "HTTP status the card URL answered with.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "card_url": {
+      "description": "The agent card URL that was fetched.",
+      "type": "string"
+    },
+    "compensation": {
+      "description": "Who the agent says pays it, as declared and not verified, or null when it says nothing.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "compensation_source": {
+      "description": "Where the compensation declaration was read: extension params or card top-level.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "conduct_record": {
+      "description": "Where the card says its conduct record is published, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "declared_uri": {
+      "description": "The extension URI the card declared, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "does_not_establish": {
+      "description": "What this reading does not establish, as sentences.",
+      "type": "array"
+    },
+    "extension_declared": {
+      "description": "true = the card declares the A2A Conduct Extension. false is not a negative verdict.",
+      "type": "boolean"
+    },
+    "how_to_file": {
+      "description": "How to walk the agent yourself and file your own record.",
+      "type": "string"
+    },
+    "measured_endpoints": {
+      "description": "The https endpoints the card asks to be measured on, at most 5.",
+      "type": "array"
+    },
+    "ok": {
+      "description": "Always true in this object: the card was fetched and read.",
+      "type": "boolean"
+    },
+    "register": {
+      "description": "This register's stored reading for each of those endpoints: state, verified (true or null, never false), record_sha256.",
+      "type": "array"
+    },
+    "schema": {
+      "description": "Format name of this object: gate-preflight-v1.",
+      "type": "string"
+    },
+    "witness_intake": {
+      "description": "Where the card says witness records can be filed, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

AddedSep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses the request cost (one request), that compensation data is 'as declared and not verified', the precise null-vs-false semantics of the register reading, that it returns counts/pointers and never a score, and that a missing extension is not a negative verdict. That is unusually rich behavioral context that annotations alone do not convey.

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?

It is front-loaded with the imperative and the fetch action, and every clause carries information, but the second sentence is a very long run-on packing six distinct facts. It is dense rather than wasteful, though bullet-style structure would aid scanning.

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 values are covered structurally, yet the description still orients the agent on what comes back (counts and pointers, never a score) and on the null/true/false semantics of the reading. Nothing an agent needs 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.

Parameters4/5

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

With one parameter at 100% schema coverage, the baseline is 3, but the description adds value by showing how the identifier resolves (https://<agent>/.well-known/agent-card.json) and framing it as a single request. It stops short of restating the origin-vs-full-URL duality, but the added resolution detail lifts it above baseline.

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 names a specific verb and resource (fetch the agent's public card) and enumerates exactly what it reports: extension declaration, compensation declaration, signature presence, measured endpoints, and register readings. It is difficult to confuse with siblings like is_verified or verify_verdict, which adjudicate rather than preflight.

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 triggering condition: 'Call this before handing work to an A2A agent you have not used before.' It also implicitly carves out behavior ('Measures nothing new'), but it never names an alternative tool or an explicit when-not-to-use case, so it stops short of the top band.

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.