OpenRepro ledger

How to verify a report's evidence

how_to_verify

Read-onlyIdempotent

The log's final hash, the downloadable evidence bundle, the report's SHA-256 from the release manifest, and the one command that checks the bundle with only Python. The verifier checks log and artifact integrity and that the report names the log's head hash; it does not check the report's contents against the log.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paper": "<paper>"
    },
    "name": "how_to_verify"
  }
}

Input Schema

Name	Required	Description	Default
`paper`	Yes	arXiv ID (1607.01759), DOI (10.1126/science.abb9789), an arXiv/doi.org/openrepro.org URL, the paper's title, or a name it is known by (fastText, PINNs, the Leiden algorithm)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds substantive verifier scope, including integrity checks, head-hash naming, and explicit exclusion of content checking, but it remains ambiguous whether the tool runs the verifier or only returns the command/instructions.

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

Conciseness3/5

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

The description is only two sentences, but the first is a verbless list that front-loads artifacts rather than the tool's purpose. The second sentence is clearer, but the overall structure is compact without being optimally front-loaded for tool selection.

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

Completeness3/5

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

For a simple one-parameter, read-only tool with no output schema, the description covers verifier scope and limitations. However, because there is no output schema, it should more clearly state what the tool returns and how that output is used; the action/return ambiguity leaves a meaningful gap.

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?

Schema description coverage for the single paper parameter is 100%, and the schema enumerates accepted identifier forms. The tool description adds no parameter-specific semantics, so the baseline of 3 is appropriate.

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

Purpose3/5

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

The title and name frame it as verification guidance, and the description names concrete artifacts (log final hash, evidence bundle, report SHA-256, Python command) and the verifier's checks. However, it never states the tool's action or return format, and the first sentence is a noun-phrase fragment, so an agent must infer whether the tool performs verification or explains how to do it.

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?

The description gives a useful scope boundary: the verifier checks log/artifact integrity and that the report names the log's head hash, but does not check report contents against the log. That implies when the tool is appropriate, but it gives no explicit when-to-use guidance or comparison to siblings such as check_paper.

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

All OpenRepro ledger 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.

Resources

Need Help?