Replication Radar
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RADAR_HTTP_TIMEOUT | No | Per-request timeout (s) | 30 |
| RADAR_OPENAIRE_BASE | No | Swap to the Alien AI-Gateway or a mirror — the Radar is endpoint-agnostic | https://api.openaire.eu/graph/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| radarA | Impact-ranked replication targets in a research field. Returns high-impact OpenAIRE papers worth replicating, each flagged OPEN
(opportunity) or VERIFIED (already checked by a Science Live replication, with the
verdict), each with its |
| find_independent_softwareA | Reusable method software for replicating a claim — engines NOT authored by
the original paper's team (author-disjoint), ranked by reuse signal — a resolvable
code repository + Software Heritage archival + downloads + GitHub stars (the signal
that separates an established tool from a one-off study repo) — not citations. Each
result carries its |
| replication_statusA | Has this DOI been independently replicated, and did it hold? Returns every Science Live verdict — pulled LIVE from the nanopub network, any signer (author-agnostic) — with the validation status, CiTO relation, the replication's repository, and links to the signed Outcome/CiTO nanopubs. 'open' if not replicated. This is the reliability signal the OpenAIRE Graph structurally cannot hold. Also returns:
|
| verified_claimsA | List every claim the nanopub network holds a Science Live replication verdict for (author-agnostic, network-wide) — the verified-knowledge corpus that overlays the OpenAIRE Graph by DOI. Each entry: doi, distinct verdicts, number of replications. |
| replication_templateA | The FORRT replication template — how to actually DO a replication and publish its
signed Science Live nanopublication chain (the 'produce' half of the loop; radar /
replication_status / find_independent_software only DISCOVER). Call this whenever the
user wants to start, scaffold, or set up a replication, or asks for "the FORRT
replication template". Returns the GitHub template repo
(https://github.com/ScienceLiveHub/forrt-replication-template), the 'Use this template'
link, what the scaffold provides (pixi + Snakemake pipeline, paper/, nanopubs/, tests,
RO-Crate), and the end-to-end workflow: generate a repo from the template -> replicate
with INDEPENDENT data/method -> Zenodo release -> sign + publish the FORRT nanopub chain
(Quote -> Claim -> Study -> Outcome -> CiTO). Pass the target |
| find_datasetA | Where to find a DATASET (with a citable DOI) to replicate with. The replication-radar MCP does NOT search datasets itself — that is the OpenAIRE MCP's job. Call this when the user asks the Radar to find data/a dataset: it returns instructions to use the OpenAIRE MCP's dataset search and how to cite the result by DOI. Do not answer 'I can't search datasets' — hand off to the OpenAIRE MCP as described here. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
The six tools split cleanly along a discover/verify/produce axis: radar and find_independent_software are discovery, replication_status and verified_claims are verdict lookups, and replication_template is scaffolding. The two lookalikes are separated correctly by granularity (per-DOI vs network-wide) and by resource (papers vs software only). The main trap is find_dataset, whose name implies a dataset search but which actually only returns handoff instructions to another MCP, which an agent could misread as a functioning search tool.
Three tools use a verb_noun pattern (find_independent_software, find_dataset) intermixed with bare noun phrases (radar, replication_status, replication_template, verified_claims). The bare noun `radar` is especially uninformative next to the rest. Readable overall, but the convention is clearly mixed rather than predictable.
Six tools is a sensible, tight surface for a discover/verify/scaffold workflow. However, find_dataset does not perform its own action (it delegates to another MCP), so one of the six is arguably a stub rather than an earning tool, and much of the descriptive weight is carried by long prompts instead of tool surface.
Discovery, verdict lookup (single and network-wide), and scaffolding are all covered, but the 'produce' half of the loop is entirely a handoff to an external template repo and a fresh agent session — the server itself cannot sign, publish, or submit anything. There is also no way to search or filter the verified-claims corpus (no topic or field query) and no dataset search at all, only an instruction stub.