Yakumo Verification Gate: conformance and disclosure checker for MCP servers

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

With no annotations, the description carries the full burden and delivers. It discloses the default non-invasive behavior ('By default no tool on the checked server is called'), the consequence for the determinism measure ('so determinism comes back as not measured rather than guessed'), and a safety warning for the opt-in tool execution. It also clarifies the scope (conformance/disclosure only) and the fact that no correctness validation is performed.

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 moderately detailed, but every sentence contributes meaningful information: the five conditions, the scope limitation, the default behavior, and the usage warning. It is well-structured and front-loaded with the core purpose, though it could be slightly tightened without losing value.

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?

Despite the absence of annotations and output schema, the description provides sufficient context for an agent to decide when to use the tool and what to expect. It covers what the tool measures, what it does not measure, the default execution safety, and the specific condition for enabling the optional parameter. This is complete for a two-parameter tool with no output schema.

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 input schema already covers both parameters with 100% description coverage, providing a baseline of 3. The description adds meaning beyond the schema by explaining the behavioral impact of allow_tool_call (executing one tool twice) and emphasizing the safety condition ('only set this for a server you own'). This extra context justifies 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 opens with a specific verb and resource: 'Measure a public MCP endpoint against five conditions,' and enumerates those conditions clearly. This distinguishes the tool from siblings like get_conditions and verify_verdict by focusing on the conformance check across multiple dimensions.

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 explains when to use the tool ('Free, no key') and provides an important exclusion ('this says nothing about whether any figure the checked server returns is correct'). It also gives clear safety guidance for the optional parameter ('Set allow_tool_call true only for a server you control'). However, it does not explicitly mention alternatives or contrast with sibling tools, so a small deduction is appropriate.

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?

With no annotations provided, the description carries the full transparency burden. It discloses that the tool takes no arguments, returns identical output every time (deterministic), and describes exactly what content it returns, including the crucial 'what it explicitly does not verify' limitation. This gives the agent a complete behavioral picture.

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 two sentences: the first front-loads the exact return contents, the second gives a concise usage directive. Every sentence earns its place with no filler or redundancy.

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?

For a no-argument, no-output-schema informational tool, the description covers return content, determinism, and the recommended usage point relative to other tools. This is fully sufficient for an agent to select and invoke it 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 tool has zero parameters and the schema is an empty object, so the description adds value by explicitly stating 'Takes no arguments.' The baseline for 0 params is 4, and the description confirms this without any ambiguity, though it doesn't go beyond that.

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 specifies an exact verb and resource: 'Return the five conditions this gate measures, what it explicitly does not verify, and the tier definitions.' This clearly distinguishes get_conditions from its siblings check_conformance and verify_verdict, which would execute checks or validate verdicts rather than provide static reference information.

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 tells the agent to 'Read this before running a check' so it understands what a verdict does and does not claim. This provides clear context for when to use the tool, though it does not explicitly name alternative tools or state when not to use it.

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?

With no annotations provided, the description carries the full burden, and it delivers. It openly discloses the exact algorithm: 'Removes record_sha256 and recompute_note, serialises the remainder in key order, and hashes it.' It also states the return value ('Returns whether the verdict was altered') and the trust implication, making behavior fully transparent.

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 earning its place. It front-loads the core purpose, describes the method compactly, and gives the outcome. No wasted words or irrelevant details.

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 is complete for this simple tool: it has one parameter well-described in schema, clearly explains the output (boolean indicating alteration), and adds trust context. There is no output schema, but the return is straightforward. The absence of error handling details is not a concern given the tool's simplicity and the schema coverage.

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 schema already provides 100% coverage for the single parameter (record: 'The full verdict object...'). The description adds context about how the record is processed (removing fields and hashing) but does not add new meaning about the parameter itself beyond the schema. Thus, baseline 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 clearly states the specific action: 'Take a verdict this gate issued and recompute its record_sha256 independently.' It names the resource (verdict) and the process (recomputing the hash), and it differentiates from siblings by explaining a unique verification capability rather than listing or checking conditions.

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 whether a verdict was altered after issuance. It also clarifies the contexts ('verdict this gate issued', 'You do not have to trust the party that issued the verdict'). However, it does not explicitly contrast with sibling tools (check_conformance, get_conditions) or state when not to use it, so it falls short of full guidance.

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