DataShield Ontology

Capabilities — One-Page Cheat Sheet

Every capability in the DataShield Library with its MCP tool name inline, and the live surfaces that stay correct when this page does not.

Capabilities

v0.22.202 · 45 tools · 469 commands Audience: an agent orienting before it calls anything, or a human checking what already exists before building it again.

Read this first: how a call is shaped

Tools are umbrellas. You name the tool and the operation goes in command:

mdm         { command: 'match_explain', … }
dataset_catalog { command: 'search', … }

There are no flat per-operation tools. If you were told to call datasets_search, dataset_load, get_analysis or analysis_queue_submit, that vocabulary is gone — those are commands on dataset_catalog, dataset_data and dataset_analysis now.

Three conventions apply to every tool:

  • session_label — a short run label, accepted on any call, consumed before the tool's own parameters are validated. Carry it on every call when several chats share one connector, because they share one transport session.
  • Refusals are typed. Branch on the code, never the message. A refusal may carry a fix object; read fix.kind first — replayable is executable as sent, skeleton is a draft you must check, note has no args at all.
  • Destructive commands are confirm-gated. They refuse with confirm_required until you re-send the identical call with confirm: true.

The live surfaces beat this page

This page is a scan. These answer from the running build and cannot go stale:

| Ask | Call | |---|---| | What is this, and what version? | _hello | | Full orientation / action menu | ux { command: 'session_start' } | | Which tool does X? | ux { command: 'help', query: 'X' } | | One tool's or command's reference | ux { command: 'docs_get', topic: 'mdm.battery_run' } | | I don't know which umbrella owns it | search { command: 'query' } | | A ready-made multi-step recipe | workflow { command: 'list' } | | What changed in a release | ux { command: 'docs_get', topic: 'release_notes' } |

Pass intent to _hello in plain language and it returns a workflow plan with a step chain and a confidence score.

The 45 tools

Start here — _hello · ux · search · workflow

Getting data in — dataset_ingest (CSV/JSON/TSV, inline or by URL) · connection (systems you already run) · crawler and crawler_run (open data portals, on a schedule) · watch_source (sources that change) · file_repo (drop files, get them catalogued) · rest (bind an API endpoint)

Catalog and discovery — dataset_catalog (search datasets and fields) · data_catalog (the estate map of objects inside connected providers: discover, profile in place, bind into mastering) · domain · topic · edges (typed asset-to-asset relationships, depth-1 through bounded multi-hop, drawable as a layered graph) · fingerprint (source-system identification) · timeline · story

Analysis — dataset_analysis (automated multi-section profiling, PII detection) · analytics_config · classification (compliance codes) · generalization (masking and k-anonymity strategies)

Working with the data — dataset_data (SQL with cost guardrails, through masking views) · dataset_snapshot · dataset_transform · dataset_lifecycle · dataset_admin

Mastering and stewardship — mdm (entity resolution, golden records, match_explain for a per-field decision decomposition, golden_explain for which source won each attribute) · mdm_project (the interview engine: stand up a mastering model through conversation) · stewardship (the supervised-proposal front door — patterns with evidence, one human touch per pattern, a trust ladder that earns auto-disposition and audits itself) · evidence (hashed, re-verifiable claims with the determinations behind them)

Retrieval — rag (document corpora, hybrid vector plus keyword search, hits carry citations, served through the corpus masking view)

Output — report (auto-generated, with lineage and refresh triggers) · artifact

Platform and operations — admin · account · job (async lifecycle across both queues) · health_check · mcp_log · sessions · tokens · vault · workspace_info · git

Two analysis engines

Profiling and diffing run on Postgres by default and on DuckDB above the configured row threshold or when you ask for it:

engine: 'duckdb'            # force the columnar path
diff_config.pg_max_rows     # the threshold that decides by default

A dataset over the threshold is refused with the reason and the ways out. It is never silently truncated or sampled.

The admission gate

agent_ready is a gate, not a label. A record reaches an agent only if it clears the quality bar on every axis and no consent fact vetoes it. It fails closed, and it is applied so that neither the scores nor the consent facts leak to the caller. Governance mutations are trailed append-only.

Ending a substantive run

For multi-minute or multi-turn work, submit one report at the end:

ux { command: 'run_report', metrics: {…}, narrative: {…} }

narrative is strict — an unknown key is refused rather than dropped. Quote the payload field you judged in evidence rather than summarising it. The server reconciles your self-report against your logged calls and echoes the deltas.

Send Feedback