erdos-renyi
erdos-renyi is a FastMCP 4 server connecting Erdos queries to Reyni-registered cohort exports. Agents inspect schema metadata and approved categorical vocabulary, then stage results locally in Arrow IPC for clinician review. MCP never returns patient rows. Counts and vocabulary require support from enough distinct patients; these suppression rules are not a general anonymization guarantee against arbitrary repeated queries.
Quickstart
# Install dependencies
uv sync --extra dev
# Run test suite
uv run pytest
# Run the MCP server over stdio
uv run er-mcp
Reyni Gateway Setup
Add erdos-renyi to ~/Library/Application Support/reyni/servers.toml (Windows: %APPDATA%\reyni\servers.toml):
[[server]]
name = "erdos"
launch = ["uv", "tool", "run", "--python", "3.12", "--from", "erdos-renyi", "er-mcp"]
phi_access = true
During local development, point --from to the local repository path:
[[server]]
name = "erdos"
launch = ["uv", "tool", "run", "--python", "3.12", "--from", "/path/to/erdos-renyi", "er-mcp"]
phi_access = true
Agent-visible Erdos tools: erdos__get_schema, erdos__stage_query, erdos__stage_dashboard_config, and erdos__get_dashboard_config_help. The help tool provides schema/example access through gateways that only forward tools. After staging, call the gateway's register_dashboard. The gateway must hide and restrict launch_dashboard; a direct connection to this server exposes it. Registered-path authorization is also the gateway's responsibility.
Operator privacy settings
Configure the following in the server's launch environment, after verifying the export's schema:
ERDOS_RENYI_ENTITY_ID_COLUMN=patient_id
ERDOS_RENYI_CATEGORICAL_COLUMNS='["sex", "icd10"]'
The identity must be a stable patient identifier, not an encounter/row ID. Categorical approval must exclude identifying and free-text fields, including fields with arbitrary names; a name-based denylist is only an additional safeguard. These settings cannot be changed by tool arguments. Defaults disclose no vocabulary and suppress patient-dependent counts. Missing/null identities do not contribute to support. Values longer than 64 characters are withheld rather than shortened into incorrect filter literals.
Query counts require an unchanged trusted identity in a direct SELECT ... FROM cohort. CTEs, joins, aggregates, absent/replaced identity projections, and other unproven transformations still stage for the clinician, but return matched_records: "not_established". Fewer than k distinct patients returns "below_threshold". Neither means zero. An exact matched_records is the staged row count, not the number of distinct patients or the total match count before LIMIT.
Agent Workflow
reyni__list_datasets: Obtain thesafe_pathfor the tokenized twin export.erdos__get_schema(safe_path): Inspect up to 50 columns per page; passnext_offsetasoffset, or selectcolumns. Type names omit Enum categories and nested field contents. Approved vocabulary and null/redaction counts require ≥ k distinct supporting patients (k=5 default).profile_status: "unavailable"means profiling failed, not that values are absent.- Rewrite SQL: Adapt the Erdos predictive query to target the local schema. The table name in Polars SQL is always
cohort. erdos__stage_query(safe_path, sql): Sanitize and execute one SELECT; useTRY_CASTfor redacted numeric text. The receipt includes column names/types. Failures returnisError: truewith safe error types and repair hints, without raw parser/engine/input dumps.truncatedis true only when the system row cap, not your LIMIT, cut the result; it is omitted with suppressed counts.erdos__stage_dashboard_config(session_id, config): Validate and atomically replace the session's declarative config. Get an example/schema throughget_dashboard_config_helpor the resources. Invalid operands, unknown keys, unsafe templates, oversized/deep configs return bounded field errors; correct them and retry the same session. At most 20 diagnostics are returned with an omitted count. Config success confirms staging, not clinical validity.reyni__register_dashboard(session_id): Reyni launches the static dashboard internally, reads a clinician-only sidecar (session_{id}.launch.json), and stores the URL encrypted — the agent receives only adashboard_ref.
Security Guarantees
- Restricted data egress: MCP returns schema metadata, explicitly approved vocabulary supported by distinct patients, and gated counts. Vocabulary is untrusted data, never instructions. Patient rows remain local. Errors do not include raw input values or engine/parser messages.
- SQL Sanitization: Enforces read-only
SELECTqueries, rejects external filesystem functions (read_csv,eval), and clampsLIMITto 1000 rows. - Localhost Enclave: Staging files use Arrow IPC written mode-
0600into a mode-0700staging directory; dashboards bind to127.0.0.1. Launch URLs are written to mode-0600sidecars, not returned over MCP. Launched dashboard sessions expire automatically; unlaunched staging files need operator cleanup. - CSV exports are read through a private Parquet twin: the first tool call on a CSV converts it once (full schema inference, so a late free-text cell cannot fail a query) into
staging_dir/cache/as a mode-0600file keyed by the export's path, size and mtime. Later calls are column-pruned Parquet reads. The twin is deleted when the server process exits; nothing persists across restarts. - Execution budget:
ERDOS_RENYI_QUERY_TIMEOUT(default 30 seconds) bounds the query wait, not CPU execution. A timed-out daemon worker may continue; it retains the single admission slot, and retries receiveResourceBusyuntil it exits. No session is staged on timeout. Structural guards reject cross joins, multiple joins per SELECT, and direct/subquery self-joins. Hard cancellation would require process isolation.
Real agent dogfood
.venv/bin/python scripts/mcp_agent_e2e.py --scenario all --output-dir /private/tmp/erdos-mcp-e2e
Requires an authenticated Codex CLI and access to gpt-5.6-terra; no model substitution is made. The runner creates isolated synthetic exports, uses only this server's tools/resources, and preapproves config writes only on the synthetic server. It saves prompts, CLI JSONL, diagnostics, and per-scenario reports. Checks use actual tool events plus independently inspected Arrow/config artifacts: happy path, missing-column repair, invalid-config repair, and policy refusal. This does not validate a deployed Reyni gateway or establish statistical agent reliability.
Metadata
Release files for erdos-renyi 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| erdos_renyi-0.2.0.tar.gz | 94.6 kB | With provenance | Details for erdos_renyi-0.2.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| erdos_renyi-0.2.0-py3-none-any.whl | Python 3 | none | any | Details for erdos_renyi-0.2.0-py3-none-any.whl |
Total release size: 169.8 kB
Release files / erdos_renyi-0.2.0.tar.gz
| Download URL | erdos_renyi-0.2.0.tar.gz |
|---|---|
| Size | 94.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f38d2fbb89e98c365edde09e8dbe2d8694f16d3ffcfcbcbf3c69021f8229c43d
|
|
BLAKE2b-256 checksum How to use checksums |
1734f27774735ad5382b0572cc30af6798b13035ddf0361b9f6bf34a67c734ff
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.
Transparency logRelease files / erdos_renyi-0.2.0-py3-none-any.whl
| Download URL | erdos_renyi-0.2.0-py3-none-any.whl |
|---|---|
| Size | 75.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
d443732eb38c1fce619c6052ad642b008afe746b4f4642980065c4e7b5300ad5
|
|
BLAKE2b-256 checksum How to use checksums |
f8ad8730cc9a145bbe0cea09c90ca38f76e72f72c016115e1d343efffc14624b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.
Transparency logSecurity for erdos-renyi 0.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for erdos_renyi-0.2.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 17, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.