MCP tools
Twenty tools. Read tools are marked read-only for the client. Write and governance tools ask for confirmation in every supported client.
Reference
| Tool | What it does | Role |
|---|---|---|
| get_workspace_context | Workspace and ontology status. Call it first in a session. With entity: its direct and inherited types and its asserted and derived links, or the instances of a type. | member |
| resolve_decision_state | The decision in force for a question, with scope, time, sources, supersessions and conflicts. | member |
| get_decision_history | Timeline of a topic or an entity: approvals, supersessions, revocations and the current heads. A proposed record says whether something in force already entails it. An empty timeline says why. | member |
| find_conflicts | Incompatible claims, their sources and scopes, and what evidence would resolve them, newest first and one page at a time. An unrecognised topic filter says so. | member |
| list_topics | Canonical topic keys and original labels, most used first, with counts and scopes. Read it before writing; read matching does not infer synonyms. | member |
| ingest | Capture text or reviewed records with source metadata. Approved records require a governor under the organisation’s mode and verified evidence. | member (write) |
| remember | One statement from the conversation becomes one record, with the statement as its source and evidence. Unconfirmed statements are candidates; a confirmed decision lands approved only for a governor. | member (write) |
| get_ingestion_status | The persisted result of an ingestion job: records stored, skipped or queued. | member |
| list_pending_decisions | Candidates and conflicts awaiting review, with their reasons. | member |
| review_decision | Approve or reject a candidate, revoke an approved decision or retract a proposal, with a reason. | reviewed: admin/owner; peer: member |
| resolve_conflict | Resolve an open conflict with an approved winner, or dismiss it, with a reason. | reviewed: admin/owner; peer: member |
| start_ontology | Propose a small ontology (topics, scopes, source types, authority rules) from a description. | member (write) |
| get_ontology | The active ontology and its version history. | member |
| rate_answer | Rate a captured resolver answer by call_id; capture must be enabled. | member (write) |
| edit_ontology | Propose a change, approve a proposal or prepare a rollback. Approval is always a separate call. | approve: admin or owner |
| prepare_eval_dataset | Store a draft set of decision questions with the answers a person expects. Immutable once stored; preparing approves nothing. | reviewed: admin/owner; peer: member |
| review_eval_dataset | Approve the inspected version of a dataset, or retire it, with a reason. A retired dataset stays readable and admits no new run. | reviewed: admin/owner; peer: member |
| run_eval | Measure the resolver against an approved dataset and store one completed run with its summary. | reviewed: admin/owner; peer: member |
| get_intelligence | Datasets, their cases and review state, and the per-case expected/observed detail of a run. | member |
| export_eval_dataset | An approved dataset as JSONL: questions, expectations and references, declared evaluation_only. Never source text. | owner |
resolve_decision_state accepts an optional topic and scope, and a request_id used as an idempotency key bound to the question asked: repeating a call with the same request_id and question returns the same answer. With an optional entity, named exactly, the answer is that entity’s own decision, weighed with the decisions of what lies under it along declared transitive relations: one uncertain part makes the whole uncertain, and derived_from lists the links and records that placed each part there.
Measuring the resolver
The last five tools are an evaluation instrument for resolve_decision_state, not a training pipeline. The cycle is prepare, inspect, approve, run, read, export: a person writes the questions and the answers they expect, approves the exact version they read, and a run resolves every case against the current memory and records what each check found. Preparation never asks the resolver for an expected answer, and approving a dataset changes no decision and no ontology.
- Five checks per case: the epistemic state, the selected decision and its value, the scope, the sources the case requires, and whether the excerpts returned resolve to sources the answer also lists.
- A check with nothing to measure is reported as not applicable, never counted as a pass or a failure.
- A dataset is immutable once prepared and holds at most 20 cases; correcting it means preparing a new one and retiring the old.
- A run records the dataset hash, the scorer version and the ontology version. Re-running after an ingestion may legitimately give a different result: it measures the memory as it is now.
- The JSONL export is declared evaluation_only and carries questions, expectations and references — never source text, ratings or trace payloads. It is not a training dataset and nothing here claims it is fit for one.
- A passing run says the resolver returned what a person expected on those cases. It is not a measure of whether an assistant then respects that answer.
What an answer contains
- The state: verified (shown as Current in the web app), contested, insufficient_evidence or unknown.
- The decision in force, its scope and the date from which it applies.
- Who approved each decision and when; OIDA Cloud adds the approver’s name.
- Superseded decisions, listed as history.
- Open conflicts involving the topic.
- Evidence excerpts and source references, never full documents.
- Candidate topics when the question matched nothing exactly.