MCP Verification Gate: conformance and disclosure checker for MCP servers

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds important behavioral context: the tool does not call tools on the checked server by default, determinism is reported as 'not measured' rather than guessed, and allow_tool_call has specific consent implications. It also clarifies the scope (conformance/disclosure only) and that correctness of returned figures is out of scope, which goes beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and information-dense: four sentences each carry distinct content—what is measured, what is not measured, default behavior, and the explicit warning about allow_tool_call. No filler or redundancy, and critical safety information is placed at the end as a natural call-to-action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 params, one boolean), the description is nearly complete: it explains the five conditions, the safety model, and the default behavior. The presence of an output schema means return-value details are already covered elsewhere, so the description doesn't need to explain them. Minor gap: it does not explicitly state what happens if the endpoint is not reachable or how the verdict is returned, but these are acceptable given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%: both endpoint and allow_tool_call have descriptions in the schema. The tool description adds semantic value by explaining the default behavior of allow_tool_call (default false) and the safety condition ('only set this for a server you own'), which complements rather than merely repeats the schema. It does not add format details for endpoint beyond the schema's 'https URL', so a 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Measure') and resource ('a public MCP endpoint') and enumerates five concrete conditions, which clearly differentiates it from sibling tools like lookup_server or verify_verdict. The title is also specific about checking conformance and disclosure, so an agent can immediately know what this tool accomplishes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains what the tool does not do ('says nothing about whether any figure the checked server returns is correct'), provides a clear safety rule ('Set allow_tool_call true only for a server you control'), and notes that by default no tool is called. This gives the agent clear when-to-use and when-not-to-use guidance, though it does not name sibling alternatives directly.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds that it 'Takes no arguments and returns identical output every time,' reinforcing idempotency. It also reveals the return content includes what the gate 'explicitly does not verify,' which goes beyond the safety profile into semantic content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences; the first front-loads the core content, the second gives temporal usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is static and parameterless, with a rich output schema. The description covers what is returned, invariant behavior, and when to read it, making it complete for an AI agent's selection and invocation needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

There are zero parameters, and the description explicitly states 'Takes no arguments,' aligning with the schema. Per the baseline for parameterless tools, this is fully sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and names the exact resource: 'the five conditions this gate measures, what it explicitly does not verify, and the tier definitions.' This clearly distinguishes from siblings like check_conformance or verify_verdict, making the tool's scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to 'Read this before running a check so you know what a verdict does and does not claim,' providing clear when-to-use guidance. It does not mention alternatives or when-not to use it, but the context is sufficient for selecting this tool.

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

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

The description fully discloses that the tool 'Reads the stored register: it contacts nothing and measures nothing.' It also honestly explains that 'absent and pending are reported honestly and are NOT negative verdicts' and clarifies that 'verified' can never be false, ensuring the agent understands the reliability and side-effect-free nature of the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but includes essential details about the return fields, trust implications, and the read-only nature. It is structured as a coherent paragraph with clear sentences, though slightly verbose due to repeated emphasis on what the tool does not do.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description outlines the return values (verified, state enum, measured_at, record_sha256, recompute_url) and explains how to verify the verdict without trusting the gate. It also mentions the alternative for fresh measurements. It lacks explicit error handling details but is sufficiently complete for an agent to decide on usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The only parameter 'endpoint' is already well-described in the input schema as an 'https URL... exactly as it appears on the register.' The description does not add extra semantics beyond the schema, but since the schema covers 100% of the parameter, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely states the tool's purpose: 'A single machine-first answer for an agent deciding whether to trust an MCP endpoint BEFORE it connects.' It also explicitly differentiates from the sibling tool check_conformance, making its unique role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool ('BEFORE it connects') and provides an explicit alternative for fresh measurements ('use check_conformance'). This gives clear contextual guidance on when to employ this tool versus a sibling.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds precise details: it removes record_sha256 and recompute_note, serialises the remainder, and hashes it. This fully discloses the operation and its result, leaving no ambiguity about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using two sentences to convey the algorithm and outcome. Every word is purposeful, with no redundancy or filler. It is well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, usage, methodology, and return value. It explains the independent verification aspect and the trust premise. Even without an explicit output schema, the return behavior is clearly stated, making it complete for an agent to decide and use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The only parameter 'record' is fully described in the schema as 'The full verdict object as returned by check_conformance or GET /self'. Since schema coverage is 100%, the baseline is 3, but the additional context about the expected source of the object adds value, making it a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to independently recompute the record_sha256 of a verdict and determine if it was altered. It distinguishes itself from sibling tools like check_conformance and lookup_server by focusing on hash verification and trust independence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when you need to verify a verdict without trusting the issuer. It explains the process (removing fields, hashing) and indicates independent verification. However, it does not explicitly mention when not to use it or alternative approaches, though the context is clear enough.

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