A self-hostable, reproducible tool server for exercising AI agents. It exposes the same set of capabilities over two faces from one shared registry, so they never drift:
Model Context Protocol over Streamable HTTP. One tool per capability. Point an agent / AgentCore remote MCP server at it.
A REST operation per capability plus an OpenAPI 3.1 document for gateways (e.g. AgentCore Gateway) and codegen.
A capability is a single tool/operation (e.g.
insurance_get_policy), exposed identically on MCP and REST. The
three domains below (insurance, financial, healthcare) are
industry areas that group related capabilities.
member · policy · claim · quote · coverage
Lookups, search, claims aggregation, and a file-claim write stub. VIN-bearing auto quotes.
account · transaction · balance · statement
Account/balance/statement lookups, transaction search, spending summary, transfer write stub. IBAN-bearing accounts.
patient · encounter · provider · appointment · prescription
Patient/provider/prescription lookups, encounter & appointment search/aggregation, schedule write stub. NPI-bearing providers.
~30 capabilities total across the three domains, plus a
cross-domain session_reset. Each domain includes read tools and a
non-persisting write stub.
| Surface | URL |
|---|---|
| MCP (Streamable HTTP) | https://secured.harness.dataio.dev/mcp |
| REST capability | POST https://secured.harness.dataio.dev/capabilities/<tool_name> |
| OpenAPI 3.1 schema | https://secured.harness.dataio.dev/openapi.json |
| Health (health check) | https://secured.harness.dataio.dev/healthz |
The Health endpoint is an ops liveness probe (is the service up), not a data domain.
Auth posture: open no token required TLS at the edge
The service is IdP-agnostic and can enforce JWT (OAuth scopes per domain,
e.g. insurance.read / insurance.write) when run
under the enforce posture. It validates tokens against any OIDC
issuer's JWKS but never issues tokens. Currently running open
(no auth) since the data is synthetic.
Tool names use underscores: insurance_get_policy,
financial_get_account, healthcare_get_patient.
Entities are addressed as {domain}/{type}/{ordinal} (slashes),
e.g. insurance/policy/0, financial/account/0.
Ordinals start at 0 and a handful always exist; use a
search_* / list_* tool to discover valid ids.
All data is a pure function of an opaque seed string — the same seed always yields the same universe, regardless of call order. This is what makes test runs reproducible. There is no database; nothing is stored.
| Where | How to set the seed |
|---|---|
| Any client / agent — per call | "seed": "my-seed" in the tool arguments / JSON body (works everywhere, incl. clients that can't set headers and through gateways) |
| REST — session | X-Seed: my-seed request header (header-capable clients / curl) |
| MCP — connection | X-Seed: my-seed header on the connection (header-capable clients only) |
| If omitted | a seed is auto-generated and echoed back (X-Seed response header + seed in the body) so you can replay it |
The seed argument is the universal way to pin a run: an agent
simply passes seed in each tool call, so it works in every
client (including ones whose UI can't set custom headers). The
X-Seed header is a set-and-forget alternative for
header-capable clients and curl.
# Pin a seed so results are identical every time:
curl -s -X POST https://secured.harness.dataio.dev/capabilities/insurance_get_policy \
-H 'Content-Type: application/json' -H 'X-Seed: demo-123' \
-d '{"policy_id": "insurance/policy/0"}'
The cross-domain session_reset tool installs a new seed (or
auto-generates one) and clears any session overlay — use it to start a clean,
reproducible run on demand. It echoes the seed now in effect but does
not persist server-side in v1, so pin the per-call
seed argument (or the X-Seed header) on each call
to actually fix the data.
# Reseed to a known universe:
curl -s -X POST https://secured.harness.dataio.dev/capabilities/session_reset \
-H 'Content-Type: application/json' \
-d '{"seed": "demo-123"}'
# Or omit the seed to get a fresh auto-generated one (returned in the response):
curl -s -X POST https://secured.harness.dataio.dev/capabilities/session_reset \
-H 'Content-Type: application/json' -d '{}'
The write tools (insurance_file_claim,
financial_transfer_funds,
healthcare_schedule_appointment) validate input and return a
realistic, seed-derived success response marked
_mock: "not_persisted" — but they do not store
anything. "Write then read it back" is intentionally inconsistent in this
version.