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

Name: MCP Verification Gate: check an MCP server or an A2A agent before you connect or delegate
Author: ogasurfproject-jpg

by io.github.ogasurfproject-jpg

Overview Discussions Admin

Server Details

Check an A2A agent before you delegate, or an MCP server's measured conduct. Free, no key.

Ownership verified

Status: Healthy
Uptime: 100.0% over 52 days
Last Tested: 2026-10-08 15:29
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: ogasurfproject-jpg/horizon-shield
GitHub Stars: 2
Server Listing: HORIZON SHIELD KIRA

TDQS

A4.4/5.0

Scored 2026-10-07 08:05 across 6 tools

Disambiguation5/5

The tools separate cleanly along fresh-vs-stored and MCP-vs-A2A lines: check_conformance measures fresh, is_verified/lookup_server read stored register data, preflight_agent handles A2A cards, and verify_verdict recomputes hashes. The descriptions explicitly clarify these boundaries, including when to prefer check_conformance over stored reads, so an agent can select the right tool without confusion.

Naming Consistency4/5

All names use consistent snake_case and are readable, with mostly verb_noun forms like check_conformance, get_conditions, lookup_server, preflight_agent, and verify_verdict. The only minor deviation is is_verified, which uses a copula/adjective form rather than a clear action verb, but it remains understandable and predictable.

Tool Count5/5

Six tools is well-scoped for a verification gate: each tool covers a distinct step in checking, reading, or recomputing a verdict. There is no obvious bloat, and every tool appears to earn its place in the verification workflow.

Completeness4/5

The surface covers the core lifecycle: learn conditions, run a fresh MCP check, read stored trust/records, preflight an A2A agent, and independently verify a verdict. A minor gap is the absence of tools to browse the register or trigger/register a scheduled measurement, though agents can work around this via the existing fresh-check and lookup operations.

Available Tools

6 tools

check_conformanceCheck an MCP server for conformance and disclosure

Read-only

Inspect

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.

ParametersJSON 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

ParametersJSON 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.

get_conditionsGet the conformance conditionsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON 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.

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.

is_verifiedOne glance: is this MCP server verified, with proofA

Read-onlyIdempotent

Inspect

A single machine-first answer for an agent deciding whether to trust an MCP endpoint BEFORE it connects. Returns verified (true only when the latest scheduled measurement passed every measured condition; null otherwise, never false), a state enum saying which case it is, measured_at, and a record_sha256 with a recompute_url so you can check the verdict without trusting this gate. Reads the stored register only: it contacts nothing and measures nothing. Absent and pending are reported honestly and are NOT negative verdicts. For a fresh measurement rather than the stored one, use check_conformance.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	https URL of the MCP endpoint to look up, exactly as it appears on the register

Output Schema

ParametersJSON Schema

Name	Required	Description
`gate`	No	Name of this gate.
`state`	No	verified = passed all measured conditions. pending = measured but not passing every one (often only because determinism needs the owner's consent). held = could not be reached. watched = on the list, not yet measured. absent = no row here at all.
`reason`	No	One sentence saying why state has the value it has.
`endpoint`	No	The endpoint you asked about, echoed.
`verified`	No	true = latest measurement passed all measured conditions. null = not established here (see state). Never false: unmeasured or not-yet-passing is not a failure.
`conditions`	No	Per condition: true passed, false did not pass, null not measured. null as a whole when nothing was measured.
`record_url`	No	URL of the exact bytes that record_sha256 hashes, or null for a verdict stored before those bytes were kept.
`gate_commit`	No	Git commit of the deployed gate, or a sentence saying the deployment did not pin one.
`history_url`	No	URL of the stored measurements for this endpoint.
`measured_at`	No	Time of the latest stored measurement, or null when there is none.
`on_register`	No	true = the endpoint has a row here. false = the register was read and it has none.
`measurements`	No	Measured endpoints only: how many measurements are stored.
`how_to_appear`	No	Absent endpoint only: how anyone can add it to the register.
`recompute_url`	No	Where to fetch what record_sha256 can be checked against: record_url when it exists, otherwise the history.
`record_sha256`	No	Hash of the latest verdict. Recompute it via recompute_url; no trust in this gate required.
`recompute_note`	No	How to recompute record_sha256 from record_url, or why it cannot be recomputed.
`verified_meaning`	No	What verified true and null mean.
`absence_vs_failure`	No	Measured endpoints only: condition 06 from the latest measurement, disclosed and never a verdict.
`not_an_endorsement`	No	What a verified reading does not claim.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantive behavior beyond them: it reads the stored register only and 'contacts nothing and measures nothing', explains that verified is null-not-false and that absent/pending are honest non-verdicts, and exposes a recompute_url for independent verification. That is rich, non-redundant disclosure.

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?

Front-loads the core value ('A single machine-first answer... BEFORE it connects') and every sentence carries distinct information (return contract, read-only scope, null semantics, alternative tool). Slightly dense but no wasted sentences.

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?

Output schema exists so return-field explanation is not strictly required, yet the description voluntarily characterizes the return contract and edge cases (null vs false, pending). Combined with the schema and annotations, an agent has everything needed to call 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?

Single parameter with 100% schema description coverage, so the schema already explains the endpoint format ('exactly as it appears on the register'). The description adds no further syntax or format detail beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb+resource: returns a trust verdict ('verified', 'state enum', 'measured_at', 'record_sha256') for an MCP endpoint. It explicitly separates itself from check_conformance ('For a fresh measurement rather than the stored one'), so an agent can distinguish it from siblings without opening schemas.

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?

Gives a clear when-to-use frame ('BEFORE it connects') and names the alternative for the contrasting case (check_conformance for fresh measurement). Exclusions are explicit, leaving nothing to inference.

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

lookup_serverLook up an MCP server on this registerA

Read-onlyIdempotent

Inspect

Returns one record (not a list). Look up what this register already holds about an MCP endpoint: whether it is watched, how often it is re-measured, how many measurements exist, when the first and latest were taken, and the latest verdict with the record_sha256 you can recompute yourself. Reads stored measurements only. It contacts nothing and measures nothing, so use check_conformance for a fresh reading. An endpoint that is absent is reported as absent and that is NOT a negative verdict: it means nobody has measured it here, not that it failed.

ParametersJSON Schema

Name	Required	Description	Default
`endpoint`	Yes	https URL of the MCP endpoint to look up, exactly as it appears on the register

Output Schema

ParametersJSON Schema

Name	Required	Description
`tier`	No	On the register: free, paid or self. The verdict is the same for every tier.
`means`	No	What this answer means.
`latest`	No	On the register: the latest stored measurement as a summary with its record_sha256, or null if none.
`cadence`	No	On the register: how often it is re-measured (weekly or daily).
`history`	No	On the register: the most recent stored measurements, oldest first, at most 20.
`added_at`	No	On the register: when the row was added, or null if not recorded.
`endpoint`	No	The endpoint you asked about, echoed.
`standing`	No	On the register: measured, or a sentence saying it is watched and not yet measured.
`on_register`	No	true = this endpoint is on the register. false = the register was READ and this endpoint is not on it. If the register could not be read at all, this field is not returned: the call comes back as a tool error (isError), because absence and not-knowing are different answers.
`measurements`	No	On the register: how many measurements are stored for this endpoint.
`does_not_mean`	No	What this answer must not be read as.
`fresh_reading`	No	Absent endpoint only: how to measure it right now.
`how_to_appear`	No	Absent endpoint only: how anyone can add it to the register.
`register_size`	No	Absent endpoint only: how many endpoints are on the watchlist.
`full_history_url`	No	On the register: URL of the complete history for this endpoint.
`last_measured_at`	No	On the register: time of the latest stored measurement, or null.
`alerted_on_change`	No	On the register: whether someone asked to be notified when the row changes.
`first_measured_at`	No	On the register: time of the first stored measurement, or null.
`history_truncated`	No	On the register: true when history leaves out older measurements.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and not open-world, and the description adds substantive context on top: it reads stored measurements only, contacts nothing, and measures nothing. The absent-vs-failed distinction is exactly the kind of behavioral nuance annotations cannot 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?

Front-loads the most important structural fact ('one record (not a list)') and each subsequent sentence carries distinct information. It is slightly dense at four clauses, with the record_sha256 aside bordering on surplus given an output schema exists, but nothing is genuinely wasted.

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?

For a single-parameter read tool with a full output schema, the description covers what is needed: storage-only scope, the alternative for fresh data, and the critical absent-vs-failed interpretation. Return-value detail is correctly left to the output schema.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the https URL format and the 'exactly as it appears on the register' constraint. The description adds no syntax or format meaning beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource ('Look up what this register already holds about an MCP endpoint') and immediately scopes it by saying it returns one record, not a list. It also names the sibling it is not, so an agent can distinguish it from check_conformance without opening a 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?

Explicitly routes the agent: 'use check_conformance for a fresh reading' establishes the when-not condition against a named alternative. It further clarifies that an absent endpoint is a legitimate, non-negative result, which removes a likely misreading of the output.

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

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

Read-onlyIdempotent

Inspect

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.

ParametersJSON 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

ParametersJSON 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.

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.

verify_verdictRecompute a verdict hash without trusting the issuerA

Read-onlyIdempotent

Inspect

Take a verdict this gate issued and recompute its record_sha256 independently. Removes record_sha256 and recompute_note, serialises the remainder in key order, and hashes it. Returns whether the verdict was altered after it was issued. You do not have to trust the party that issued the verdict, including this one.

ParametersJSON Schema

Name	Required	Description	Default
`record`	Yes	The full verdict object as returned by check_conformance or GET /self

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	What a match or a mismatch does and does not prove.
`method`	No	The arithmetic used, so you can repeat it without this gate.
`reason`	No	Present instead of the hashes when the input could not be checked: not an object, or no record_sha256.
`verified`	No	true = the verdict hashes to its own record_sha256, so it was not altered after issue. false = it was altered, or it carries no record_sha256. This is a finding about the record, not an error.
`expected_sha256`	No	The record_sha256 found in the record you passed, echoed as given (a string in any verdict this gate issued). Absent when the record had none.
`recomputed_sha256`	No	SHA-256 this call computed from the record. Absent when there was nothing to compare it with.

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already confirm read-only and idempotent behavior, but the description adds crucial details: it removes record_sha256 and recompute_note, serialises the remainder in key order, and hashes it. This fully discloses the verification algorithm and the returned judgment, going well beyond 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?

Four tight sentences front-load the action and outcome, with no redundant clauses. The trust statement is the only flourish but reinforces the tool's purpose without waste.

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 the input schema is fully described, the description needs only to explain the verification process. It does so completely, leaving no essential behavioral gap for an agent to call it 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?

With 100% schema coverage for the single 'record' parameter, baseline is 3. The description adds meaning by specifying that record_sha256 and recompute_note are stripped before hashing, which tells the agent which fields the record must contain. This is useful but not a full replacement for schema documentation.

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 ('recompute its record_sha256 independently') and the outcome ('Returns whether the verdict was altered'), making the purpose clear. However, it does not name or differentiate from siblings like is_verified or check_conformance, leaving sibling routing implicit.

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?

Implies usage when you possess a verdict issued by this gate, but offers no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as is_verified. The trust rationale ('You do not have to trust the party that issued the verdict') provides context but not selection criteria.

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.

1 tool updateOct 8, 2026

Changedcheck_conformance2 fields changed

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

6 tool updatesOct 7, 2026

Changedcheck_conformance24 fields changed

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

Changedget_conditions22 fields changed

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

Changedis_verified16 fields changed

addedOutput schema / properties / absence_vs_failure

Added value: +{
+  "description": "Measured endpoints only: condition 06 from the latest measurement, disclosed and never a verdict.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / conditions / description

Added value: +"Per condition: true passed, false did not pass, null not measured. null as a whole when nothing was measured."

addedOutput schema / properties / endpoint / description

Added value: +"The endpoint you asked about, echoed."

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

Added value: +{
+  "description": "URL of the stored measurements for this endpoint.",
+  "type": "string"
+}

addedOutput schema / properties / how_to_appear

Added value: +{
+  "description": "Absent endpoint only: how anyone can add it to the register.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / measured_at / description

Added value: +"Time of the latest stored measurement, or null when there is none."

addedOutput schema / properties / measurements

Added value: +{
+  "description": "Measured endpoints only: how many measurements are stored.",
+  "type": "integer"
+}

addedOutput schema / properties / not_an_endorsement

Added value: +{
+  "description": "What a verified reading does not claim.",
+  "type": "string"
+}

addedOutput schema / properties / on_register / description

Added value: +"true = the endpoint has a row here. false = the register was read and it has none."

addedOutput schema / properties / reason

Added value: +{
+  "description": "One sentence saying why state has the value it has.",
+  "type": "string"
+}

addedOutput schema / properties / recompute_note

Added value: +{
+  "description": "How to recompute record_sha256 from record_url, or why it cannot be recomputed.",
+  "type": "string"
+}

addedOutput schema / properties / recompute_url / description

Added value: +"Where to fetch what record_sha256 can be checked against: record_url when it exists, otherwise the history."

addedOutput schema / properties / record_url

Added value: +{
+  "description": "URL of the exact bytes that record_sha256 hashes, or null for a verdict stored before those bytes were kept.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / verified_meaning

Added value: +{
+  "description": "What verified true and null mean.",
+  "type": "string"
+}

Changedlookup_server23 fields changed

addedOutput schema / description

Added value: +"Returns one record (not a list): what this register holds for the single endpoint you named. Fields after on_register depend on its value: an absent endpoint carries register_size, how_to_appear and fresh_reading; an endpoint on the register carries the rest."

addedOutput schema / properties / added_at

Added value: +{
+  "description": "On the register: when the row was added, or null if not recorded.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / alerted_on_change

Added value: +{
+  "description": "On the register: whether someone asked to be notified when the row changes.",
+  "type": "boolean"
+}

addedOutput schema / properties / cadence

Added value: +{
+  "description": "On the register: how often it is re-measured (weekly or daily).",
+  "type": "string"
+}

addedOutput schema / properties / does_not_mean / description
```
Added value: +"What this answer must not be read as."
```

changedOutput schema / properties / does_not_mean / type

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

addedOutput schema / properties / endpoint / description

Added value: +"The endpoint you asked about, echoed."

addedOutput schema / properties / first_measured_at

Added value: +{
+  "description": "On the register: time of the first stored measurement, or null.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / fresh_reading

Added value: +{
+  "description": "Absent endpoint only: how to measure it right now.",
+  "type": "string"
+}

addedOutput schema / properties / full_history_url

Added value: +{
+  "description": "On the register: URL of the complete history for this endpoint.",
+  "type": "string"
+}

addedOutput schema / properties / history

Added value: +{
+  "description": "On the register: the most recent stored measurements, oldest first, at most 20.",
+  "type": "array"
+}

addedOutput schema / properties / history_truncated

Added value: +{
+  "description": "On the register: true when history leaves out older measurements.",
+  "type": "boolean"
+}

addedOutput schema / properties / how_to_appear

Added value: +{
+  "description": "Absent endpoint only: how anyone can add it to the register.",
+  "type": "string"
+}

addedOutput schema / properties / last_measured_at

Added value: +{
+  "description": "On the register: time of the latest stored measurement, or null.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / latest / description

Added value: +"On the register: the latest stored measurement as a summary with its record_sha256, or null if none."

addedOutput schema / properties / means / description
```
Added value: +"What this answer means."
```

changedOutput schema / properties / means / type

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

addedOutput schema / properties / measurements

Added value: +{
+  "description": "On the register: how many measurements are stored for this endpoint.",
+  "type": "integer"
+}

addedOutput schema / properties / register_size / description

Added value: +"Absent endpoint only: how many endpoints are on the watchlist."

changedOutput schema / properties / register_size / type
```
Previous value: -"number"New value: +"integer"
```

addedOutput schema / properties / standing / description

Added value: +"On the register: measured, or a sentence saying it is watched and not yet measured."

changedOutput schema / properties / standing / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

addedOutput schema / properties / tier

Added value: +{
+  "description": "On the register: free, paid or self. The verdict is the same for every tier.",
+  "type": "string"
+}

Changedpreflight_agent1 field changed

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

Changedverify_verdict7 fields changed

addedOutput schema / properties / expected_sha256

Added value: +{
+  "description": "The record_sha256 found in the record you passed, echoed as given (a string in any verdict this gate issued). Absent when the record had none.",
+  "type": [
+    "string",
+    "number",
+    "boolean",
+    "object",
+    "array"
+  ]
+}

addedOutput schema / properties / method / description

Added value: +"The arithmetic used, so you can repeat it without this gate."

addedOutput schema / properties / note / description

Added value: +"What a match or a mismatch does and does not prove."

addedOutput schema / properties / reason

Added value: +{
+  "description": "Present instead of the hashes when the input could not be checked: not an object, or no record_sha256.",
+  "type": "string"
+}

addedOutput schema / properties / recomputed_sha256

Added value: +{
+  "description": "SHA-256 this call computed from the record. Absent when there was nothing to compare it with.",
+  "type": "string"
+}

changedOutput schema / properties / verified / description

Previous value: -"true = the verdict hashes to its own record_sha256, so it was not altered after issue. false = it was altered. This is a finding about the record, not an error."New value: +"true = the verdict hashes to its own record_sha256, so it was not altered after issue. false = it was altered, or it carries no record_sha256. This is a finding about the record, not an error."

changedOutput schema / properties / verified / type

Previous value: -[
-  "boolean",
-  "null"
-]New value: +"boolean"

1 tool updateSep 28, 2026
- Addedpreflight_agent

Publisher details

Operator: The HORIZONs Co., Ltd. · Publisher source
Operator website: https://shield.the-horizons-innovation.com
Vendor relationship: Independent · Publisher source
Documentation: https://gate.horizonshield.dev/spec
Trust center: https://gate.horizonshield.dev/self
Restrictions: None. Free, read only, no key. · Publisher source

Related MCP Connectors

Kadent Scan A
so.kadent
Free, read-only security scanner for remote MCP servers, before you connect them.
Security Penetration Testing
11
Dominion Observatory
com.dominionobservatory
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Security Observability
2
GAIP — evidence on AI agents before and after you call them A
io.github.tjcgraham-rgb
Check, watch, diagnose and verify AI agents and MCP servers; check shop prices before you buy.
Developer Tools
51
Axiom Relay B
io.github.Itr3k
Free agent-service discovery, OpenAPI document checks, and receipt verification. No API key needed.
API Testing Agent Orchestration Security
101

Related MCP Servers

MCP Scorecard
Developer Tools Testing & QA Tools CI/CD & DevOps
davidmosiah
A
license
A
quality
A
maintenance
Agent-readiness scorecard for any MCP server: protocol checks, 0-100 score and actionable findings.
Updated 8 hours ago (2026-10-08 14:28 UTC)
1
106 npm
MIT
gaip-broker
API Testing Testing & QA Tools Developer Tools
tjcgraham-rgb
A
license
Not graded
quality
A
maintenance
Enables free, read-only checks of AI agents and MCP servers for conformance, published changes, delivery evidence, and verifiable receipts without requiring an account or API key, using public or non-personal data only.
Updated 3 days ago (2026-10-05 13:50 UTC)
MIT
stillos-ratings-mcp
Security Developer Tools Open Data
stillmarcus24
A
license
Not graded
quality
B
maintenance
Enables checking an MCP server before installation by returning outside-in trust ratings, comparing candidates, and listing dated tool-surface findings for 7,000+ operators, with publisher and fleet concentration data and no key required.
Updated 4 days ago (2026-10-05 00:21 UTC)
MIT
Trooth Networkofficial
Developer Tools Open Data Security
troothllc
A
license
Not graded
quality
B
maintenance
Remote, read-only MCP connector to check any company's witnessed trust record on the Trooth Network, across identity, security, privacy, and AI practices. Also does a neutral read of a domain's public security surface and verifies signed Trust Ledger Tokens. No key, no account.
Updated 8 hours ago (2026-10-08 14:58 UTC)
MIT