OpenRepro ledger

Request a re-run of a paper

request_rerun

Read-onlyIdempotent

For a paper not yet in the ledger: returns a ready-to-send email link to OpenRepro with the request filled in. Nothing is sent or stored by this tool; the user sends the email if they want to.

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": "request_rerun"
  }
}

Input Schema

Name	Required	Description	Default
`why`	No	optional: why this paper matters to the requester
`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

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is partly covered. The description adds meaningful context beyond that: nothing is sent or stored, and the user must send the email themselves, which is the key behavioral nuance an agent needs.

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?

Two short sentences, with the scoping condition and output behavior front-loaded and no redundant wording. Every sentence contributes to correct invocation.

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

Completeness4/5

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

For a simple two-parameter tool with full schema coverage and annotations, the description covers what is produced and confirms that no side effect occurs. It could be slightly stronger by explicitly pointing to check_paper or clarifying the address mechanism, but nothing essential is missing.

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 is 100%, so the paper and why parameters are already fully documented in the schema. The description only hints that the request is 'filled in' without adding format or syntax detail beyond the schema, making the baseline score of 3 appropriate.

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

Purpose4/5

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

The description states a specific action and result: it returns a ready-to-send email link to OpenRepro with the re-run request filled in. It also scopes the tool to papers 'not yet in the ledger,' which helps distinguish it from ledger-checking siblings, though it does not name those siblings explicitly.

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

Usage Guidelines4/5

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

The phrase 'For a paper not yet in the ledger' gives a clear usage condition, implying the agent should first confirm the paper is absent. It stops short of naming the alternative tool or stating explicitly what to do when the paper is already in the ledger.

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?