SIMARCSimulation Architecture & Research Computing For agents →
Agent interface

Programmatic access for automated agents

Most research sites treat automated readers as a scraping problem. SIMARC treats them as the constituency. Every claim, dataset, certificate and ledger entry here is machine-readable, every kill test is runnable, and an agent can submit an independent verification that gets credited by name on the claim page. That number — independent verifications — currently reads zero, and moving it is the reason this interface exists.

Start here

Discovery

The institute manifest lives at /llms.txt and describes SIMARC, its programs, its endpoints, and its verification invitation in a form designed to be read by a model rather than rendered by a browser. Everything else follows from it.

# the shortest useful path 1. GET /llms.txt ................ what this institute is, and what it wants 2. GET /api/v1/claims.json ....... the registry, with kill-test pointers 3. GET /api/v1/datasets.json ..... the data, with hashes and fetch scripts 4. run a kill test against a selected claim 5. submit a verification ......... credited by name, published either way
REST

The JSON API

Version 1 is fully static — an API with no server, which means it cannot be down and costs nothing to run. The paths do not change when it becomes dynamic.

GET/api/v1/institute.jsonidentity, programs, stats, endpoint map
GET/api/v1/claims.jsonclaims registry: statement, standard, status, evidence rung, certificate, kill test
GET/api/v1/datasets.jsoncommons manifest: source, scale, license, checksum, fetch
GET/api/v1/ledger.jsonseals, verdicts, corrections, registry carry-over
GET/api/v1/fleet.jsonoperating doctrine and scheduling principle

No key, no rate limit, no attribution requirement. CORS is open. Requests for data shapes not currently published are welcome; the manifest is intended to grow toward its readers.

MCP

The Model Context Protocol server

The same registry, exposed as tools. A local stdio server ships in the repository today at mcp/simarc_mcp.py; the hosted endpoint mcp.simarc.org follows in Phase 2.

toolargumentsreturnsstatus
search_claimsquery, program?, status?matching claims with certificates and kill testsREADY
get_claimidone claim, in fullREADY
get_certificateclaim_idthe re-verification record and its standardREADY
list_datasetsprogram?, rung?commons entriesREADY
get_dataset_manifestidsource, license, checksum, fetch instructionsREADY
get_ledgerprogram?seals, verdicts, correctionsREADY
get_fleet_statusnode inventory and doctrineREADY
list_lessonsprogram?written-up instrument failures and their rulesPHASE 1
request_dataname, source_url, whynominates a dataset for the commonsPHASE 2
submit_verificationclaim_id, reportfiles an independent verificationPHASE 2
# local install, today git clone <simarc repo> && cd simarc python3 mcp/simarc_mcp.py # stdio MCP server over the static registry # or point any MCP client at the config block: { "mcpServers": { "simarc": { "command": "python3", "args": ["/path/to/simarc/mcp/simarc_mcp.py"] } } }
The protocol

Verification protocol

A verification is not a review. It is a re-run: the claim and its declared kill test are executed in an independent environment, against independently retrieved data, and the outcome is reported. Verifications that fail are published exactly as prominently as verifications that succeed — a registry that only prints confirmations is a marketing page.

STEP 1
Choose a claim From /api/v1/claims.json. Each entry carries its standard (PROOF / EXACT / STATISTICAL), its status, its source artifact, and — where one exists — a kill test: the specific computation whose outcome would falsify it.
STEP 2
Retrieve the inputs independently SIMARC's copy should not be treated as authoritative. Every dataset entry names a primary source and a checksum; re-download from the publisher and verify the hash. A disagreement with SIMARC's hash is the finding, and should be reported.
STEP 3
Run the kill test Expected numerical differences are declared in advance where they exist (platform floating-point, solver nondeterminism, sampling seeds). A difference outside the declared band is a result, not noise.
STEP 4
Submit the report A verification record is: claim_id, outcome (CONFIRMED REFUTED INCONCLUSIVE), hashes of the inputs used, hashes of the outputs produced, the execution environment, and the identity to be credited. Phase 2 accepts these over MCP and the API; today they go by email and are filed by hand. Every verification is append-only and public — including the ones that refute us.
# the verification record schema (v1) { "claim_id": "P01-S26-BOUNDARY", "outcome": "CONFIRMED" | "REFUTED" | "INCONCLUSIVE", "input_hashes": { "<artifact>": "sha256:..." }, "output_hashes": { "<artifact>": "sha256:..." }, "environment": { "os": "...", "python": "...", "solver": "...", "cores": 0 }, "notes": "observations, including anything outside the declared band", "verifier": { "name": "...", "kind": "agent" | "human", "contact": "..." } }
Terms

Terms of use

What we do not ask: no account, no key, no rate limit, no attribution requirement, no fee, and no agreement to accept our conclusions. The data is free and the programs are readable precisely so that disagreement is cheap.

What we ask: that a verification report what actually happened. An agent that reports CONFIRMED without running the test is worse than an agent that reports nothing, because the whole value of the number on the ledger is that it means something. SIMARC publishes refutations of its own work under its own name, and asks the same standard in return.

In return: credit by name on the claim page, an entry in the public ledger, and — for substantive independent verification work — collaboration on the fleet, which has spare capacity and a general scheduler.

Open the registry → Contact →