Datalox Gated Runtime
БесплатноНе проверенThis MCP server provides a stateful, resettable, verifiable API runtime that gates every tool call, enabling agents to run long workflows against provider-shape
Описание
This MCP server provides a stateful, resettable, verifiable API runtime that gates every tool call, enabling agents to run long workflows against provider-shaped environments without live provider write access. It records decisions, side effects, and outcome evidence for replayable, verifiable benchmark runs.
README
Datalox Gated Runtime
Stateful, resettable, verifiable API worlds for tool-using agents
Run long agent workflows against provider-shaped systems without giving the evaluated agent live provider write access.
Product thesis · Provider packs · Behavior grounding · Behavior harvest · Portable packages · World admission
Datalox sits between an agent and its tools. It decides what every call does, mutates resettable local state, records the execution, and verifies the final workflow.
Most tool benchmarks ask whether a model can answer a question or complete one API call. Real work is longer. It crosses roles and systems, creates related objects, waits for asynchronous jobs, encounters conflicts, and leaves durable state behind. A plausible final message does not prove that the workflow was correct.
Datalox provides the execution substrate for testing that work.
task
-> agent calls HTTP or MCP tools normally
-> Datalox gates every call
-> replayed reads and local writes change resettable world state
-> the ledger records decisions, responses, and side effects
-> hidden verifiers judge the final state and workflow evidence
-> the run becomes replayable evidence
What Datalox is—and is not
| Datalox is | Datalox is not |
|---|---|
| An open runtime for provider-shaped, stateful API environments | A proxy for unrestricted production API access |
| A way to compose reusable API building blocks into resettable worlds | A directory of disconnected mocked endpoints |
| A verifier and evidence layer for complete agent workflows | An agent framework, planner, memory system, or model router |
| A sandbox-first path for learning provider behavior | A claim that documentation examples reproduce production behavior |
| Infrastructure that benchmarks can run on | One benchmark or one vertical application |
The vocabulary is deliberate:
- Fuel is a reusable gated provider/API building block: operation contracts, behavior recipes, transitions, verifier atoms, provenance, and known gaps.
- A world composes fuel into a stateful environment with roles, tasks, reset, dynamics, and hidden verification.
- A benchmark consumes worlds to evaluate agents.
Fuel is not a benchmark. A provider pack is not automatically a complete world. World admission is not automatically proof of provider equivalence.
Provider-shaped surfaces already represented
The current inventory spans infrastructure, business operations, healthcare, science, and other specialized systems. Every tile below links to a public probe declaration or grounding contract that can be inspected in this repository.
Infrastructure and observability
Kubernetes Probe surface |
Docker Probe surface |
OpenSearch Probe surface |
Grafana Probe surface |
Datadog Probe surface |
Sentry Probe surface |
Business operations
Stripe Regression only |
Shopify Probe surface |
HubSpot Probe surface |
Jira Probe surface |
Google Workspace Probe surface |
Microsoft Graph Probe surface |
Healthcare, science, and specialized operations
HAPI FHIR Healthcare |
openFDA Regulatory data |
ClinicalTrials.gov Clinical research |
RCSB PDB Structural biology |
Opentrons Lab automation |
NASA CMR Earth science |
Presence in this grid means that a provider or project is represented by a probe, connector, capture path, pack, or world input. It does not mean that every core operation is implemented, provider writes were observed, provider data is publicly redistributed, or a local world is production-equivalent. Those are separate, checked claims described in Provider Core Completeness and Provider Behavior Grounding.
Provider names and logos belong to their respective owners and do not imply affiliation or endorsement. Brand icons are served by Simple Icons; neutral specialized-domain tiles in docs/assets/provider-tiles/ are self-authored and are not official provider logos.
What is open source
The Apache-2.0 release contains:
- the HTTP and MCP gating runtime;
- policy, replay, shadow-state, denial, ledger, and audit primitives;
- versioned provider-pack, behavior-recipe, and world-bundle contracts;
- validators, compilers, admission checks, and verifier composition;
- public probe declarations and capture utilities;
- a fully synthetic, stateful commerce reference world; and
- a deterministic public-source builder and release gate.
Raw provider responses, credentials, tenant identifiers, sandbox transcripts, and compiled provider behavior programs are not automatically open data. They remain excluded unless each artifact has an explicit redistribution basis and passes the public-data gate. Open source users can capture and compile their own authorized provider packs without publishing those payloads.
See Data Release Policy for the exact boundary.
What happens on every tool call
The runtime makes one explicit decision:
| Decision | Observable behavior |
|---|---|
replay |
Return a declared captured or synthetic response case. |
shadow_read |
Read provider-shaped data from resettable local state. |
shadow_write |
Apply a deterministic local transition and record its side effects. |
live_capture |
Perform an explicitly approved live GET and capture its response. |
deny |
Reject an unsafe or unsupported call with an agent-readable error. |
miss |
Record an unknown call so the environment can be extended deliberately. |
Live provider writes are intentionally inexpressible in the runtime. Approved sandbox writes belong to a separate, manually authorized behavior-authoring process against an exact test account.
Try a complete world offline
Requirements: Python 3.11 or newer. No provider account, API key, network connection, or model is required.
git clone https://github.com/Oshawott324/datalox-gated-runtime.git
cd datalox-gated-runtime
python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
python scripts/demo/offline-world-smoke.py
The demo does more than ping an endpoint. It:
- creates a fresh commerce-operations world;
- discovers role-scoped provider-shaped tools;
- reads initial state;
- performs a multi-step workflow containing real local mutations;
- verifies the final state and workflow evidence;
- destroys and resets the world;
- proves equivalent capabilities, observations, and initial state; and
- replays the workflow and proves an equivalent final export.
It exits nonzero if mutation, verification, functional reset, or replay equivalence fails.
Build a provider-grounded world
The default workflow is sandbox-first:
audit official sandbox or disposable reference system
-> declare the smallest complete operation-family scope
-> execute reviewed behavior recipes outside the runtime
-> capture before / write / duplicate / failure / after evidence
-> compile the evidenced slice into reusable fuel
-> compose fuel into a resettable world
-> verify state, failures, reset, and known gaps
Do not rebuild a provider sandbox merely to increase a provider count. Local reimplementation is justified when a concrete requirement needs offline scale, deterministic reset, parallelism, missing sandbox behavior, controllable failures, lower cost, or a distributable partner environment.
Start with Provider Packs, then read Provider Behavior Grounding and World Admission Rubric.
The portable construction path is provider-neutral. Current depth work applies the same authoring, compilation, differential, reset, admission, OCI, HUD, and Harbor contracts to specialized operational systems instead of treating one well-built commercial sandbox as the product. The checked provider-by-provider status and exact claim boundaries are summarized in Provider Behavior Grounding.
Repository map
| Path | Purpose |
|---|---|
| src/datalox_gated_runtime/ | Gating, replay, state, ledger, audit, MCP, and world runtime |
| src/datalox_gated_runtime/behavior_harvest/ | Authoring-only provider behavior capture and compilation contracts |
| envs/commerce_support_ops_v0/ | Public synthetic stateful reference world |
| probes/ | Public provider probe declarations |
| scripts/demo/offline-world-smoke.py | Credential-free end-to-end proof |
| scripts/providers/ | Manually approved provider/reference authoring and evidence checks |
| docs/world-packages.md | Provider-neutral OCI package, gated endpoint, controller, HUD, and Harbor contract |
| scripts/public_release.py | Deterministic public-source builder and verifier |
| docs/ | Product, grounding, admission, security, and data contracts |
Develop and verify
With the locked uv environment:
uv sync --frozen --extra dev
uv run pytest -q
uv run ruff check . --select E4,E7,E9,F
Build and verify the exact public tree:
uv run python scripts/public_release.py check
uv run python scripts/public_release.py build --out .tmp/public-source
uv run python scripts/public_release.py verify-built --source .tmp/public-source
The release gate fails closed on unclassified data, missing or changed digests, private machine paths, unresolved public documentation links, unexpected files, test failures, formatting failures, or package-build failures.
Current status
Datalox currently proves deterministic gated execution, stateful local worlds, functional reset, replayable evidence, and verifier-driven evaluation. It does not claim that every represented provider is core-complete or behaviorally equivalent to production.
The project is early. The most valuable contributions are complete behavior programs, stronger reset and failure evidence, reusable verifier atoms, and well-scoped worlds—not raw endpoint count.
Contributing, security, and governance
Read CONTRIBUTING.md before submitting code or provider material. Do not put credentials, tenant data, provider payloads, or sandbox write transcripts in a public issue or pull request.
Security reports follow SECURITY.md. Project decisions and release authority are described in GOVERNANCE.md, and support channels are described in SUPPORT.md.
Licensed under the Apache License 2.0.
Установка Datalox Gated Runtime
У этого сервера нет опубликованного пакета — он собирается из исходников. Открой репозиторий и следуй инструкции в README.
▸ github.com/Oshawott324/datalox-gated-runtimeFAQ
Datalox Gated Runtime MCP бесплатный?
Да, Datalox Gated Runtime MCP бесплатный — установка в пару кликов через Unyly без оплаты.
Нужен ли API-ключ для Datalox Gated Runtime?
Нет, Datalox Gated Runtime работает без API-ключей и переменных окружения.
Datalox Gated Runtime — hosted или self-hosted?
Доступен hosted-вариант: Unyly запускает сервер в облаке, локальная установка не обязательна.
Как установить Datalox Gated Runtime в Claude Desktop, Claude Code или Cursor?
Открой Datalox Gated Runtime на unyly.org, выбери вкладку своего клиента (Claude Desktop, Claude Code, Cursor) и нажми Install — конфиг сгенерируется автоматически, без правки JSON.
Похожие MCP
GitHub
PRs, issues, code search, CI status
автор: GitHubFilesystem
Secure file operations with configurable access controls.
Memory
Knowledge graph-based persistent memory system.
Template MCP Server
A CLI tool to create a new Model Context Protocol server project with TypeScript support, dual transport options, and an extensible structure
автор: mcpdotdirectCompare Datalox Gated Runtime with
Не уверен что выбрать?
Найди свой стек за 60 секунд
Автор?
Embed-бейдж для README
Похожее
Все в категории development
