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

Look up an MCP server on this register

lookup_server

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedOct 7, 2026

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

Changed1 schema field changedAug 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "does_not_mean": {
+      "type": [
+        "string",
+        "object"
+      ]
+    },
+    "endpoint": {
+      "type": "string"
+    },
+    "latest": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "means": {
+      "type": [
+        "string",
+        "object"
+      ]
+    },
+    "on_register": {
+      "description": "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.",
+      "type": "boolean"
+    },
+    "register_size": {
+      "type": "number"
+    },
+    "standing": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

AddedAug 17, 2026

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.

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.