MCP Verification Gate: conformance and disclosure checker for MCP servers

Look up an MCP server on this register

lookup_server

Read-onlyIdempotent

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
`means`	No
`latest`	No
`endpoint`	No
`standing`	No
`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.
`does_not_mean`	No
`register_size`	No

Schema Changelog

Changes observed during successful MCP inspections.

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.7/5.0

Behavior5/5

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

The description clearly discloses read-only behavior ('Reads stored measurements only', 'contacts nothing and measures nothing'), which aligns with annotations (readOnlyHint, idempotentHint). It goes beyond annotations by explaining absence semantics and that record_sha256 is recomputable, adding valuable context. No contradiction with 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?

The description is three sentences, each serving a purpose: enumerating returned data, stating read-only nature, and clarifying absence semantics. It is concise, front-loaded, and wastes no words.

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 a single parameter, high schema coverage, an output schema, and clear annotations, the description fully covers what the tool does, when to use it, and interprets potential results. It also explains the fallback to check_conformance, making it complete for an agent to select and invoke 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?

The only parameter 'endpoint' is fully described in the schema (100% coverage), including format and matching requirement. The description does not add additional parameter information beyond the schema, 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?

The description explicitly states the tool's purpose: to look up what the register already holds about an MCP endpoint, listing specific fields (watched status, re-measure frequency, measurement count, time range, latest verdict, record_sha256). It clearly distinguishes from sibling check_conformance by stating it does not contact or measure anything, and points to check_conformance for fresh readings.

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?

The description provides clear when-to-use guidance: use this tool for existing stored data, and explicitly directs to check_conformance for a fresh reading. It also clarifies the meaning of absent endpoints (absence is not a negative verdict), which helps the agent interpret results and decide if further action is needed.

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: conformance and disclosure checker for MCP servers tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.