# Ontology Atlas (mcpb · ontology-atlas-mcp-0.13.0.mcpb)

Read and write one codebase ontology kept as Markdown in the repository.

- Trust score: 47/100 (low)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- mcpb · `ontology-atlas-mcp-0.13.0.mcpb`: 47/100 (this document), [markdown](https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m.md), [page](https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m)

## Channel facts

- Registry: `mcpb`
- Package: `https://github.com/wlsdks/ontology-atlas/releases/download/v1.2.0/ontology-atlas-mcp-0.13.0.mcpb`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 13/100
  - Malware scan not yet available for this package.
  - Known CVEs could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.
  - No install/post-install scripts declared.
  - Dependency health could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 10 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 60/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 19463 tokens (~512/item across 38 items; 38 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 33/100
  - Stability observed for 10 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 95% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 39 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

- Download bundle: `https://github.com/wlsdks/ontology-atlas/releases/download/v1.2.0/ontology-atlas-mcp-0.13.0.mcpb`

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-21 (score 47, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-19 (score 46, +4)

- [functional improvement] Stability: unverified → 0.27

### 2026-09-11 (score 42)

First indexed and scored.

## MCP tools (38)

### `connection_info` (~54 tokens)

Return the exact active vault root and code-repository root used by this MCP process, including how each root was resolved. Call first when a client may have stale configuration or multiple workspaces. Root changes require restarting the MCP process.

Output parameters:

- `repoResolution` (string)
- `repoRoot` (string)
- `restartRequiredForRootChange` (boolean)
- `sameRoot` (boolean)
- `server` (object)
- `vaultResolution` (string)
- `vaultRoot` (string)

### `git_status` (~58 tokens)

Inspect local Git state for the active vault only. Returns HEAD/branch, vault files, outside-vault change counts, staged-outside-vault warnings, and in-progress operation risk. Read-only; never initializes, stages, commits, or pushes.

Output parameters:

- `branch` (string|null)
- `commitHash` (string)
- `commitSummary` (string)
- `committed` (boolean)
- `counts` (object)
- `detachedHead` (boolean)
- `dryRun` (boolean)
- `expectedHead` (string|null)
- `files` (array)
- `head` (string|null)
- `ok` (boolean)
- `operation` (string)
- `operationInProgress` (string|null)
- `previousHead` (string)
- `pushReason` (string)
- `pushSupported` (boolean)
- `reason` (string)
- `repoRoot` (string)
- `risk` (object)
- `stagedOutsideVault` (array)
- `subject` (string)
- `validation` (object)
- `vaultPathspec` (string)
- `vaultRoot` (string)

### `git_history` (~109 tokens)

Read commit history scoped to the active vault path only. Returns bounded newest-first hashes, subjects, and authored timestamps plus limited/hasMore, shallow-repository state, and historyComplete so agents do not mistake a truncated or shallow view for complete evidence. Commits that touched only files outside the vault are excluded. Read-only; never initializes, fetches, pulls, commits, or pushes.

Input parameters:

- `limit` (integer): Maximum newest-first vault commits to return. Defaults to 20; maximum 100.

Output parameters:

- `branch` (string|null)
- `commits` (array)
- `count` (integer)
- `hasMore` (boolean)
- `head` (string|null)
- `historyComplete` (boolean)
- `limit` (integer)
- `limited` (boolean)
- `ok` (boolean)
- `operation` (string)
- `reason` (string)
- `repoRoot` (string)
- `shallow` (boolean)
- `vaultPathspec` (string)
- `vaultRoot` (string)

### `git_snapshot` (~172 tokens)

Create a local, vault-scoped Git checkpoint. Dry-run by default and returns exact expectedHead, files, validation, risk, and the shared previewReady/canConfirm/wouldChange/blockedReasons safety contract. confirm:true requires that expectedHead, blocks validator errors and Git operations in progress, commits only the vault pathspec, leaves outside files untouched, and never pushes.

Input parameters:

- `confirm` (boolean): Default false. Set true only after reviewing the dry-run preview and its risk/validation fields.
- `expectedHead` (string): Required with confirm:true. Copy the exact expectedHead returned by the immediately preceding dry-run; this prevents committing after a concurrent HEAD change.
- `message` (string): Optional local commit subject, one line and at most 200 characters. A deterministic ontology snapshot subject is generated when omitted.

Output parameters:

- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `branch` (string|null)
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `commitHash` (string)
- `commitSummary` (string)
- `committed` (boolean)
- `counts` (object)
- `detachedHead` (boolean)
- `dryRun` (boolean)
- `expectedHead` (string|null)
- `files` (array)
- `head` (string|null)
- `ok` (boolean)
- `operation` (string)
- `operationInProgress` (string|null)
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `previousHead` (string)
- `pushReason` (string)
- `pushSupported` (boolean)
- `reason` (string)
- `repoRoot` (string)
- `risk` (object)
- `stagedOutsideVault` (array)
- `subject` (string)
- `validation` (object)
- `vaultPathspec` (string)
- `vaultRoot` (string)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `list_concepts` (~426 tokens)

List every ontology node in the vault (each .md file with a frontmatter `kind:`). Filter by `kind`, `domain`, and/or `since` (mtime-based incremental sync). Large vaults are resumable with `offset` + `limit`; always follow `pagination.nextOffset` while `hasMore` is true. AI agents call this first to grasp the codebase's mental model.

Input parameters:

- `domain` (string): Filter to nodes whose frontmatter `domain:` matches this slug (e.g. "auth"). Combine with `kind` for "all capabilities under auth" in one call. Use the domain *slug*, not the title.
- `kind` (string): Filter to one canonical ontology kind (project, domain, capability, element, document, vault-readme). Omit to return all. Invalid kind typos fail closed with nearest-value hints instead of returning…
- `limit` (integer): Positive integer max rows to return. Defaults to 100, max 500.
- `offset` (integer): Zero-based page offset applied after kind/domain/since filters. Resume at pagination.nextOffset until hasMore is false; ordering is deterministic by canonical slug.
- `since` (number): Non-negative mtime threshold. Filter to nodes with `mtime > since` (ms). Pair with the `mtime` returned in earlier `list_concepts` / `get_concept` responses for incremental sync — "what changed since…
- `summary` (boolean): When true, each node row includes a `summary` (max 200 chars, prose-only — heading / table / code block / image / divider / list / quote are skipped and only the first paragraph is kept, same `extrac…

Output parameters:

- `limited` (boolean): True when this page does not contain every matching row.
- `nodes` (array)
- `pagination` (object)
- `returned` (integer): Number of rows returned in this page.
- `summaryHint` (string): Only present when at least one row carries a partial summary — names the follow-up call that returns the full bodies.
- `total` (integer): Total number of matching ontology nodes before the limit is applied.
- `vaultRoot` (string): Resolved vault root path used for the listing.
- `vaultWarnings` (object)

### `get_concept` (~356 tokens)

Fetch one node by exactly one selector: `slug` (canonical slug or unique alias) or immutable `uid`. Successful responses always carry both the permanent `uid` and current canonical `slug`; graph relations and graph-operation inputs remain slug-based. Returns frontmatter, body, direct graph neighbors, outgoingEdges (each `{to, via, rationale?}`, the rationale being the stored `relation_notes` sentence when one exists), and mtime. **By default you get `excerpt` — the first prose paragraph only. The node body is where the construction rules put definition, evidence, confidence, and in-scope/out-of-scope, so pass `body: "full"` whenever you are reading a node to answer a question rather than just to identify it.** `bodyInfo` always reports `totalChars` / `returnedChars` / `truncated`, so a partial read is never silent. **For K specific selectors in one call use `get_concepts({slugs: [...]})` or `get_concepts({uids: [...]})`.** When a slug does not resolve, structured growth guidance remains available.

Input parameters:

- `body` (string): `excerpt` (default) returns the first prose paragraph as `excerpt`. `full` returns the entire markdown body as `body` and omits `excerpt`. Use `full` when the answer depends on what the node actually…
- `slug` (string): Vault-relative slug (e.g. projects/auth-platform), unique tail slug, or frontmatter `slug` alias. Omit the .md extension.
- `uid` (string): Exact permanent node UID. Use instead of `slug`, never together with it.

Output parameters:

- `body` (string): Entire markdown body. Present only when the caller passed `body: "full"`.
- `bodyInfo` (object): How much of the body this response carries — always present, so truncation is never silent.
- `excerpt` (string): First prose paragraph. Present only when `body` is `excerpt` (the default).
- `frontmatter` (object): Resolved markdown frontmatter.
- `mtime` (number)
- `neighbors` (object): Direct graph neighbor buckets.
- `outgoingEdges` (array)
- `slug` (string)
- `uid` (string): Permanent immutable node identity.
- `warnings` (array)

### `get_concepts` (~270 tokens)

Fetch multiple nodes by exactly one selector array: `slugs` (canonical slugs or unique aliases) or immutable `uids`. Same per-row shape as `get_concept`; successful rows always return permanent `uid` plus current canonical `slug`. Order matches the selected input array. Missing or invalid slug rows return partial `{slug, ok:false, error, ...repairFields}` rows, so later valid slugs still resolve; UID misses likewise return `{uid, ok:false, error, ...repairFields}` without aborting the batch. Graph relations and graph-operation inputs remain slug-based.

Input parameters:

- `body` (string): Applies to every row. `excerpt` (default) returns the first prose paragraph per row; `full` returns the entire markdown body per row and caps the batch at 20 slugs.
- `slugs` (array): Vault-relative slugs, unique tail slugs, or frontmatter `slug` aliases (e.g. ["capabilities/x", "elements/y"]). Omit the .md extension. Max 50 per call (max 20 when body is `full`).
- `uids` (array): Exact permanent node UIDs. Use instead of `slugs`, never together with it. Max 50 (max 20 with body `full`).

Output parameters:

- `concepts` (array)

### `find_evidence` (~323 tokens)

Find vault docs that mention a given concept by title. Useful when an AI agent asks where a capability is realized in code or docs. Each match includes a prose `excerpt` (max 200 chars, headings/tables/code skipped) so agents see *what the matching doc says* without an extra get_concept call. Matches are RANKED by a deterministic relevance `score` (title match > frontmatter ref > body, plus a title token-overlap tiebreaker), then by whether the doc is a graph node, then slug — best-first. **A vault holds ordinary markdown too** (meeting notes, memos, drafts have no `kind:` and are not graph nodes); every row says which it is via `isNode`, non-nodes rank below nodes of equal relevance, and `nodesOnly: true` filters them out. Do not cite a non-node as graph evidence without saying so. Pass `limit` for the top-N. When zero docs mention the title, the response includes a `growthHint` — near-titled vault nodes to check first, or an add_concept scaffold if the concept looks genuinely new.

Input parameters:

- `limit` (integer): Return only the top-N highest-scoring matches. Omit for all matches (still ranked).
- `nodesOnly` (boolean): Return only graph nodes (docs with a `kind:`). Default false — ordinary markdown in the same folder is included and marked `isNode: false`.
- `title` (string, required): Concept title to search for (case-insensitive substring match).

Output parameters:

- `bodyHint` (string): Only present when at least one match returned a partial excerpt — names the get_concepts({ body: "full" }) call that returns the rest.
- `growthHint` (object): Only present when matches is empty — near-titled vault node(s) to check, or an add_concept scaffold, derived from the real vault title set.
- `matches` (array)
- `nonNodeHint` (string)
- `query` (string)

### `finalize_project_meaning` (~199 tokens)

Finalize the current project competency Markdown after concept/relation writes, vault validation, and a complete project compile. The server derives the current body digest, project graph hash, source fingerprint, and witness inventory itself; callers cannot submit or restamp those values. This writes only a small provenance receipt to `.ontology-atlas/project-meaning.json`. It never stores raw answers, witness text, absolute source roots, or remote coordinates. `ok: true` means the receipt was written, not that source currentness is verified; read `meaningAssessment` or a fresh `agent_brief` for the fail-closed categorical result.

Input parameters:

- `expected_mtime` (number, required): Required conflict guard. Pass the project node mtime from get_concept; any intervening human or agent edit blocks finalization.
- `projectSlug` (string, required): Exact project node slug (or an unambiguous vault alias) whose current Competency answers section should be finalized.

Output parameters:

- `bodyDigest` (string)
- `changed` (boolean)
- `contract` (string)
- `graphHash` (string)
- `meaningAssessment` (object)
- `measuredAt` (string)
- `ok` (boolean)
- `projectSlug` (string)
- `sourceFingerprint` (string)

### `connect_project_source` (~280 tokens)

Bind a project node to the local code folder it describes, measure it, and write the source receipt. This is what `nextAction: connect_source` (and `repair_source_binding` / `measure_source` / `remeasure_source`) asks for. Omit `rootPath` and the server infers it: the git repository enclosing the vault wins, otherwise the nearest ancestor folder carrying a project manifest. Without `confirm: true` nothing is written — you get the proposed folder, how many declared `path:` claims actually land in it, and the exact confirming call. Re-running with a different `rootPath` replaces the binding; `disconnect_project_source` removes it. The absolute root stays in the local gitignored sidecar `.ontology-atlas/project-sources.json` and never enters the receipt, the graph markdown, or any handoff.

Input parameters:

- `confirm` (boolean): Required to write. Default false returns the proposal and changes nothing.
- `projectSlug` (string, required): Exact project node slug (or an unambiguous vault alias) to bind.
- `repair` (boolean): Discard a malformed .ontology-atlas/project-sources.json instead of refusing to write over it.
- `rootPath` (string): Absolute local folder holding the code. Omit to auto-infer, or to re-measure an existing binding.

Output parameters:

- `binding` (object)
- `changed` (boolean)
- `confirmed` (boolean)
- `contract` (string)
- `inference` (object|null)
- `mode` (string)
- `nextCall` (object)
- `ok` (boolean)
- `previewReceipt` (object)
- `previousBindingCount` (number)
- `projectSlug` (string)
- `projectSource` (object)
- `remedy` (object)
- `undo` (object|null)

### `disconnect_project_source` (~107 tokens)

Remove a project node's local source binding and its receipt. The reversal of connect_project_source — use it when the wrong folder was bound, or to stop measuring. Without `confirm: true` it only reports what would be removed. Other projects' bindings are never touched, and no ontology markdown changes.

Input parameters:

- `confirm` (boolean): Required to write. Default false lists the binding that would be removed.
- `projectSlug` (string, required): Project node slug whose source binding should be removed.

Output parameters:

- `bindings` (array)
- `changed` (boolean)
- `confirmed` (boolean)
- `contract` (string)
- `nextCall` (object)
- `ok` (boolean)
- `projectSlug` (string)
- `projectSource` (object)
- `remedy` (object)
- `removed` (number)

### `add_concept` (~764 tokens)

Create a new ontology node (.md file). Call when an AI agent finds a new capability / element / project from code analysis. Throws if the slug already exists — use patch_concept in that case. The frontmatter is normalized per kind (project gets `domains/capabilities/elements` empty arrays; capability gets `elements: []`; capability/element should also set `domain:` so the tree has a parent — missing extras come back as `warnings` in the response, not as an error. If another node already has the same title, a near-duplicate `warning` is included too — prefer patch_concept on the existing node over forking a duplicate. Successful writes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers so agents can immediately see graph cleanup / relation suggestions after the new node lands. **For bulk creation (e.g. bootstrap flow with 5+ nodes) use `add_concepts({concepts: [...]})` (batch, max 50, partial result) — saves K-1 round-trips.** When `kind` is `element`: an element names a CONCEPT a capability uses (e.g. "jwt-token"), not a file. If your `title` is a bare path or ends in a source extension, you are describing evidence, not the concept — rename `title` to the role and put the path in `path:`, or if 3+ siblings under the same parent already look like this, call `get_concept` on the parent and consider `patch_concept` on an existing sibling instead of adding another file-mirror node. The same rule binds the `slug`: flat under the kind folder (`elements/<role-name>`), never a code path (`elements/src/views/home` is rejected) — path-style slugs collide the moment two files share a basename and the graph silently merges distinct nodes.

Input parameters:

- `body` (string): Markdown body (optional). When omitted a kind-specific starter body is written so the file is self-explanatory in the editor.
- `capabilities` (array): Capability slugs this node owns (project / domain).
- `domain` (string): Parent domain slug. Strongly expected for kind=capability and kind=element — without it the node floats orphaned in the tree.
- `elements` (array): Element slugs this node uses (project / capability).
- `kind` (string, required): project / domain / capability / element / document. (vault-readme is reserved for the auto-generated README.md and should not be set by agents.)
- `labels` (object): Per-locale display names, e.g. { "ko": "결제", "en": "Payments" }. Written as `display_ko` / `display_en` frontmatter keys; `title` stays the single source for search/matching. Fill BOTH locales the va…
- `path` (string): One canonical implementation entrypoint for a capability or element (repo-relative file or directory). Preserved as evidence and checked by validate_vault path drift.
- `slug` (string, required): Vault-relative slug (omit the .md extension), flat under the kind folder — e.g. "elements/jwt-token", "capabilities/token-issue". A slug is the node's name, never a code path: "elements/src/views/hom…
- `title` (string, required): Display title for the node.

Output parameters:

- `changed` (boolean)
- `filePath` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `slug` (string)
- `warnings` (array)

### `add_concepts` (~465 tokens)

Batch-create multiple nodes in one call — same per-row shape as `add_concept`. Use after `analyze_repo_structure` or another reviewed proposal flow when the agent has K accepted candidates from the user — replaces K×`add_concept` round-trips. Each row is processed independently: existing-slug / invalid-kind / missing-required-fields / non-object row shape / unknown row fields surface as `{ slug, ok: false, error }` rows whose errors include a `concepts[n]` row label, single unknown-field rows include `receivedField` plus one-row `unknownFields`, multi unknown-field rows report every unknown field with nearest hints and `Received fields: ...`, and duplicate input slugs report the later `concepts[n]` row plus first-seen `concepts[m]` with structured `rowName` / `firstSeenAt`; the rest still land. A row whose normalized title matches an earlier landed row in the same batch still lands but carries a near-duplicate `warning` — `patch_concept` the earlier node instead of forking the same concept (duplicates are the #1 growing-vault failure mode). `concepts[]` order in the response matches the input. Cap = 50 per call (split into multiple batches for larger sets). NO atomic rollback — if you need all-or-nothing semantics use single `add_concept` calls. Invalid-only batches return no row-level write metadata and no top-level `postWriteMaintenance`. When at least one row changes the vault, the response includes one compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers for the final graph. Rows whose `title` is a bare file path follow the same rule as `add_concept` above. Prefer one capability node covering a directory plus a short `elements:` list over one row per file, unless each file's role differs in a stated sentence.

Input parameters:

- `concepts` (array, required): Array of concept specs (max 50). Each row uses the same shape as `add_concept` input.

Output parameters:

- `concepts` (array)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.

### `add_relation` (~435 tokens)

Add a semantic relation between two nodes. Appends to the matching frontmatter graph key (domains / capabilities / elements / dependencies / relates / contains / describes); `domain` sets the source node's inline parent domain. The relation type picks which key receives the entry. A new `depends_on` relation requires a nonblank `why`; an already-existing edge remains an idempotent read even if legacy data has no rationale. **R11**: optional `expected_mtime` — pass the source-side `mtime` from a prior get_concept so concurrent external edits throw VaultConflictError. Invalid relation `type` is rejected before endpoint slug resolution with a closest-value hint and structured `valueName` / `receivedValue` / `suggestion` / `allowedValues` repair fields in `structuredContent`, with no `changed`, `alreadyExists`, or `postWriteMaintenance` write metadata. Changed writes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers so agents can immediately see graph cleanup / relation suggestions after the edge lands. **For multiple already-approved semantic edges use `add_relations({relations: [...]})` (batch, idempotent, max 50). `infer_imports.moduleEdges` require exact-evidence review, a semantic rationale, and human approval first.**

Input parameters:

- `expected_mtime` (number): Optional conflict guard for the source slug. If the source mtimeMs differs at write time, the call throws.
- `from` (string, required): Source slug.
- `to` (string, required): Target slug.
- `type` (string, required): Relation type.
- `why` (string): One-line rationale for this relation ("A leans on B because ..."). Stored in the SAME frontmatter write as the ref (relation_notes map) — write it whenever you know the reason; a graph edge without a…

Output parameters:

- `alreadyExists` (boolean)
- `changed` (boolean)
- `from` (string)
- `key` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `to` (string)
- `type` (string)

### `add_relations` (~432 tokens)

Batch-add multiple relations in one call — same per-row shape as `add_relation`. Use after `analyze_repo_structure` or another review flow when the agent has K semantic edges accepted by the user — replaces K×`add_relation` round-trips. Inferred module edges are not accepted merely because imports exist; review exact evidence and include the required nonblank `why` for every new `depends_on`. Each row is processed independently and idempotently: existing edges return `{ok: true, alreadyExists: true}`; missing source/target slugs / unknown type / non-object row shape / unknown row fields surface as `{ok: false, error}` with a `relations[n]` row label and structured `rowName`; unknown type rows include a closest-value hint with structured `valueName` / `receivedValue` / `suggestion` / `allowedValues`; single unknown-field rows include `receivedField` plus one-row `unknownFields`; multi unknown-field rows report every unknown field with nearest hints, `allowedFields`, `receivedFields`, and `Received fields: ...`. `relations[]` order in the response matches the input. Cap = 50 per call. NO atomic rollback — for all-or-nothing semantics use single `add_relation` calls. Tip: avoid `expected_mtime` in batch when multiple rows share the same `from` slug — the first row mutates that file so the second would see a stale mtime. Invalid-only batches return no row-level `changed` / `alreadyExists` write metadata and no top-level `postWriteMaintenance`. When at least one row changes the vault, the response includes one compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers for the final graph.

Input parameters:

- `relations` (array, required): Array of relation specs (max 50). Each row uses the same shape as `add_relation` input.

Output parameters:

- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `relations` (array)

### `remove_relation` (~110 tokens)

Safely remove one exact typed relation and its `relation_notes` rationale from a source node. Defaults to dry-run; pass confirm:true to write. Supports expected_mtime conflict protection. Use this instead of replacing a whole frontmatter array with patch_concept.

Input parameters:

- `confirm` (boolean): Actually remove when true; default is dry-run.
- `expected_mtime` (number)
- `from` (string, required): Source slug.
- `to` (string, required): Target slug.
- `type` (string, required)

Output parameters:

- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `changed` (boolean)
- `dryRun` (boolean)
- `exists` (boolean)
- `from` (string)
- `key` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `removedRationale` (string)
- `to` (string)
- `type` (string)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `replace_relation` (~120 tokens)

Atomically replace one exact relation with a new target and/or type, moving or replacing its rationale in the same frontmatter write. Defaults to dry-run; pass confirm:true to write. Supports expected_mtime.

Input parameters:

- `confirm` (boolean)
- `expected_mtime` (number)
- `from` (string, required): Source slug.
- `newTo` (string, required): Replacement target slug.
- `newType` (string, required)
- `oldTo` (string, required): Current target slug.
- `oldType` (string, required)
- `why` (string)

Output parameters:

- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `changed` (boolean)
- `dryRun` (boolean)
- `from` (string)
- `newRelation` (object)
- `ok` (boolean)
- `oldRelation` (object)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `patch_concept` (~330 tokens)

Update the frontmatter and/or body of an existing ontology node. Use when an AI agent revises, deepens, or reclassifies a node. Frontmatter patches are key-by-key — null deletes a key, omission preserves it. Body is fully replaced when provided, otherwise preserved. Pass `expected_mtime` (from the previous get_concept response) to detect concurrent external edits — throws VaultConflictError if the file has changed on disk since you read it. Changed writes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers so agents can immediately continue graph cleanup.

Input parameters:

- `body` (string): Full replacement markdown body (optional). Preserved when omitted.
- `expected_mtime` (number): Optional conflict guard. If the file mtimeMs differs at write time, the call throws so the caller can re-read and retry. Pass the `mtime` field from the most recent get_concept response.
- `frontmatter` (object): Frontmatter key/value patches (e.g. { kind: "capability", domain: "views" }). null removes the key. Per-locale display names go here as `display_ko` / `display_en` — fill every locale the vault serve…
- `slug` (string, required): Vault-relative slug (omit the .md extension).

Output parameters:

- `changed` (boolean)
- `filePath` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `slug` (string)

### `find_backlinks` (~86 tokens)

Return every node that points to the target slug. Scans both frontmatter array keys (capabilities / elements / dependencies / relates / contains / describes etc.) and the wikilinks / markdown links in the body. Used by AI agents to walk the graph from a node to its dependents.

Input parameters:

- `slug` (string, required): Target vault-relative slug (omit the .md extension).

Output parameters:

- `matches` (array)
- `target` (string)
- `total` (integer)

### `find_neighbors` (~177 tokens)

Return the one-hop graph neighborhood around a node. Unlike find_backlinks, this is graph-frontmatter only and can include outgoing, incoming, or both directions. Returns canonical edges plus neighbor node summaries so agents can inspect a local subgraph in one call.

Input parameters:

- `direction` (string): Edge direction to include. Defaults to both.
- `includeNodes` (boolean): When true (default), include neighbor node summaries for resolved edges.
- `limit` (integer): Positive integer max edges to return. Defaults to 100, max 500.
- `slug` (string, required): Center node slug, unique tail slug, or frontmatter `slug` alias.
- `types` (array): Optional relation types/frontmatter keys to include, e.g. ["domain", "depends_on", "contains"]. Public add_relation types are normalized to stored graph keys.

Output parameters:

- `center` (string)
- `direction` (string)
- `edges` (array)
- `limited` (boolean)
- `nodes` (array)
- `requested` (string)
- `totalEdges` (integer)
- `types` (array)

### `find_path` (~282 tokens)

Shortest path between two nodes (undirected BFS). Returns `{ from, to, hops: [slug...], nodes: [{uid, slug, kind, title, domain?}], edges: [{from, to, via, rationale?}] }` where each `via` is the frontmatter key (`domains` / `domain` / `capabilities` / `elements` / `dependencies` / `relates` / `contains` / `describes`) that linked the two slugs and `rationale` is the one-line `relation_notes` sentence the declaring document stores for that pair (present only when one is stored) — so the agent sees not just *that* A and B are connected but by which key and, when someone wrote it down, *why*. Returns `{ found: false }` when no path is found within maxHops, plus a `growthHint` — a concrete add_relation (both endpoints exist) or add_concept (an endpoint is missing) example so the unanswered question becomes a vault-growth signal instead of a dead end. maxHops defaults to 5 and is capped at 20.

Input parameters:

- `from` (string, required): Source slug.
- `maxHops` (integer): Non-negative integer maximum hop count (default 5, max 20).
- `to` (string, required): Target slug.

Output parameters:

- `edges` (array)
- `found` (boolean)
- `from` (string)
- `growthHint` (object): Only present when found=false — a candidate add_relation (both endpoints exist) or add_concept (an endpoint is missing) suggestion, derived from the real vault, not invented.
- `hopCount` (integer)
- `hops` (array)
- `nodes` (array)
- `reason` (string)
- `to` (string)

### `list_kinds` (~45 tokens)

Vault kind distribution — { total, byKind: { capability: N, ... } }. A quick census so AI agents can size up the vault without paging through list_concepts.

Output parameters:

- `byKind` (object): Node counts keyed by frontmatter kind.
- `total` (integer): Total number of vault docs that declare a kind.

### `find_orphans` (~132 tokens)

List orphan nodes — docs that no other node references via any frontmatter array key. Useful as a cleanup starting point or to answer "which nodes are unused?". Same matching policy as find_backlinks (full slug or final segment). Root/sentinel kinds like project and vault-readme are excluded by default.

Input parameters:

- `excludeKinds` (array): Kinds to exclude from results. Defaults to ['project', 'vault-readme']. Pass [] to include every kind. Typos fail with nearest-value hints.
- `kind` (string): Restrict to one kind (e.g. capability). Omit for all kinds.

Output parameters:

- `orphans` (array)
- `total` (integer)

### `query_concepts` (~278 tokens)

Typed filter DSL — search vault nodes by predicate. Built for saved-filter / smart-list cases that find_path (BFS) cannot answer, such as "which capabilities have zero elements?", "stub-only nodes in domain=auth", or "has(depends_on) excluding vault-readme".

Grammar (case-insensitive keywords, whitespace-tolerant):
  filter    := atom (AND|OR atom)*
  atom      := NOT? predicate
  predicate := key=value | key!=value | has(key)

Keys: kind / domain / slug / title for equality, plus any graph frontmatter array key for has(...). kind and has(...) keys are enum-validated with nearest-value hints.
Example: `kind=capability AND domain=auth AND NOT has(elements)` — capabilities under domain auth that have zero elements (= unfinished caps). When total=0, the response includes a `growthHint` — it names any referenced kind/domain that has 0 nodes in this vault, or nudges you to loosen the filter.

Input parameters:

- `filter` (string, required): Filter expression. Example: kind=capability AND has(elements). Supports NOT / AND / OR. Wrap values containing whitespace or special characters with "..." or '...'.
- `limit` (integer): Positive integer max rows to return. Defaults to 100, max 500.

Output parameters:

- `filter` (string)
- `growthHint` (object): Only present when total=0 — flags a referenced kind/domain with 0 nodes in this vault census, or a generic loosen-the-filter nudge otherwise.
- `limited` (boolean)
- `matches` (array)
- `parsedAs` (string)
- `total` (integer)

### `compile_ontology` (~449 tokens)

Compile the whole markdown vault into a deterministic graph artifact: canonical nodes, edges, aliases, graph issues, graph-array canonicalization actions, and optional adjacency indexes. This is the compiler-style read path for graph-database-like use: call it before advanced reasoning, indexing, export, or non-developer-friendly graph views. Includes a stable semantic graphHash and maxMtime for cache invalidation. side effect 0. Large vaults (100+ nodes) can exceed the MCP token cap with the default full payload — use `summary: true` for cheap polling (counts + graphHash, no arrays), or `nodesLimit/nodesOffset` / `edgesLimit/edgesOffset` to slice arrays. The response includes `nodesPagination` / `edgesPagination` meta with `{offset, limit, total, returned, hasMore, nextOffset}` when sliced.

Input parameters:

- `edgesLimit` (integer): Positive integer max edges to return. Pair with `edgesOffset` to paginate. Max 500.
- `edgesOffset` (integer): Non-negative integer starting index in the sorted edges array. Defaults 0.
- `includeIndexes` (boolean): When true, include indexes `{out, in, byKind, byDomain, edgeById, aliasToSlug, uidToSlug, slugToUid, mergedUidToSlug}`. Graph traversal remains slug-based; UID indexes provide exact identity resoluti…
- `nodesLimit` (integer): Positive integer max nodes to return. Pair with `nodesOffset` to paginate. Omit for unlimited (backward compat), max 500 when provided.
- `nodesOffset` (integer): Non-negative integer starting index in the sorted nodes array. Defaults 0.
- `summary` (boolean): When true, omit `nodes` / `edges` / `aliases` / `ambiguousAliases` / `canonicalizationActions` / `indexes` arrays — return only `graphHash`, `maxMtime`, counts (`nodeCount`/`edgeCount`/`aliasCount`/.…

Output parameters:

- `aliasCount` (integer)
- `aliases` (array)
- `ambiguousAliasCount` (integer)
- `ambiguousAliases` (array)
- `byDomain` (object)
- `byKind` (object)
- `canonicalizationActionCount` (integer)
- `canonicalizationActions` (array)
- `edgeCount` (integer)
- `edges` (array)
- `edgesPagination` (object)
- `externalEdgeCount` (integer)
- `graphHash` (string)
- `indexes` (object)
- `issueCount` (integer)
- `issues` (array)
- `maxMtime` (number)
- `nodeCount` (integer)
- `nodes` (array)
- `nodesPagination` (object)
- `resolvedEdgeCount` (integer)
- `summary` (object)
- `unresolvedEdgeCount` (integer)
- `version` (integer)

### `query_ontology` (~3503 tokens)

Analysis archive: `analysis_history` reads immutable diagnostic Markdown summaries without compiling the graph; use analysisMode, project, limit (1–100 scanned files, default 30), and analysisCursor. `analysis_record` reads one exact run or review with recordId (UUID). Records retain raw answers, full-body evidence when available, request scope and uncertainty. They are not approved ontology facts; stored qualification describes captured evidence, never current source validity. Reviews are joined to their exact run/finding id. Follow pagination even if a filtered page is empty. These archive operations do not support query_plan. Run graph-engine queries over the freshly compiled ontology artifact. Operations: `neighbors` (local graph neighborhood), `path` (one compiled-edge route between two nodes with aligned `nodes[]` summaries), `all_paths` (bounded simple paths between two nodes with per-path `nodes[]` summaries plus limit/searchBudget/exhaustive/truncatedByBudget/totalPathsExact metadata and evidence guidance), `query_plan` (EXPLAIN-style side-effect-free cost/index estimate plus execution advice before a target operation, filter-preserving suggestedQuery, and filter-aware estimate.totalMatches for match_nodes/match_edges), `centrality` (PageRank-style core-node ranking plus bridge/authority/hub lists), `communities` (label-propagation clusters inside the graph), `similar_nodes` (duplicate/overlap candidates before writes), `explain_relation` (direct edges, shortest path, and shared-neighbor explanation between two nodes), `reachability` (transitive graph closure from a start node), `pattern_walk` (explicit relation-sequence paths such as project → domains → capabilities), `impact` (incoming by default: what depends on this node), `blast_radius` (impact grouped by kind/domain with cross-domain edge risk), `subgraph` (bounded N-hop graph slice for UI/agent views), `builder_context` (persisted Workshop focus, layout positions, direct graph slice, and safe write…

Input parameters:

- `afterActionId` (string): maintenance_plan only: stable action id cursor; return actions after this id. Without afterActionId the ready page reports cursor.found=true and cursor.reason=null; cursor.nextAfterActionId matches t…
- `analysisCursor` (string): analysis_history only: nextCursor from the preceding scanned-file page.
- `analysisMode` (string): analysis_history only: optional analysis subject filter.
- `candidateSlug` (string): similar_nodes only: proposed slug for a not-yet-written concept candidate.
- `componentLimit` (integer): health/workspace_brief/agent_brief only: positive integer max connected components to inspect. Defaults to 5, capped at 500.
- `componentTypes` (array): health/workspace_brief/agent_brief only: relation types used for connected-component checks. Defaults to the full graph relation set.
- `cursor` (string): meaning_repair_review only: opaque stateless cursor returned as pagination.nextCursor. Omit for the first page.
- `cycleLimit` (integer): health/workspace_brief/agent_brief only: positive integer max dependency cycles to inspect. Defaults to 5, capped at 500.
- `dependencyTypes` (array): health/workspace_brief/agent_brief only: dependency relation types used for cycle and topological-order checks. Defaults to ["dependencies"].
- `depth` (integer): reachability/impact/blast_radius/subgraph/lineage/containment_tree traversal depth. Defaults to 3 for reachability, 2 for impact/blast_radius/subgraph, and 20 for lineage/containment_tree; capped at…
- `detail` (string): agent_brief only: compact v2 returns a task-scoped, selected-project handoff capped at 12000 UTF-8 JSON bytes, including exact reviewed taskNavigation only when the bound source is current; full retu…
- `direction` (string): neighbors/reachability/impact/blast_radius/subgraph/builder_context: incoming, outgoing, or both. path/all_paths/explain_relation/reachability also accepts undirected.
- `domain` (string): match_nodes: optional exact domain filter. domain_profile: domain root slug or unique alias.
- `executableOnly` (boolean): maintenance_plan only: when true, return only actions with a proposed tool call.
- `expectedGraphHash` (string): meaning_repair_review first page: exact graphHash from meaningRepair:v2 provenance. Later nextCall values are revision-bound and omit it.
- `expectedSourceFingerprint` (string): meaning_repair_review first page: exact current sourceFingerprint from meaningRepair:v2 provenance. Later nextCall values are revision-bound and omit it.
- `from` (string): Source node slug or unique alias. Required for path, all_paths, and explain_relation.
- `fromKind` (string): match_edges only: optional source node kind filter (project, domain, capability, element, document, vault-readme). Source must be a real ontology node, not external/unresolved.
- `hasIncoming` (boolean): match_nodes only: require presence or absence of incoming graph edges.
- `hasOutgoing` (boolean): match_nodes only: require presence or absence of outgoing graph edges.
- `includeExternal` (boolean): neighbors only: include external path-like element refs. Defaults false.
- `includeIsolated` (boolean): topological_order only: include nodes that are not connected by the selected relation types. Defaults false.
- `includeOrphans` (boolean): containment_tree only: include ancestorless nodes not reached from project roots. Defaults false.
- `includeUnresolved` (boolean): neighbors only: include dangling unresolved refs. Defaults false.
- `itemLimit` (integer): project_map only: positive integer max capability/element/hotspot summaries per domain. Defaults to 20, capped at 500.
- `iterations` (integer): centrality/communities only: positive integer PageRank or label-propagation iteration count. Defaults to 20, max 100.
- `kind` (string): match_nodes: optional node kind filter (project, domain, capability, element, document, vault-readme). recommend_relations currently supports capability or element.
- `kinds` (array): maintenance_plan only: optional action-kind filter, e.g. ["add_missing_relation", "canonicalize_graph_arrays"].
- `limit` (integer): Positive integer max rows/components/order entries to return. Defaults to 100, capped at 500.
- `maxDegree` (integer): match_nodes only: non-negative integer maximum total graph degree.
- `maxHops` (integer): path/all_paths/explain_relation traversal hop cap or cycles max depth. Defaults to 5 for path/all_paths/explain_relation and 8 for cycles; capped at 20.
- `minDegree` (integer): match_nodes only: non-negative integer minimum total graph degree.
- `minInDegree` (integer): match_nodes only: non-negative integer minimum incoming graph degree.
- `minOutDegree` (integer): match_nodes only: non-negative integer minimum outgoing graph degree.
- `nodeLimit` (integer): components/communities/health/workspace_brief/agent_brief only: positive integer max node summaries per component/community group. Defaults to 25 for components/communities and 10 for health, capped…
- `operation` (string, required): Query operation to run.
- `orderLimit` (integer): health/workspace_brief/agent_brief only: positive integer max topological-order rows to inspect. Defaults to 20, capped at 500.
- `pattern` (array): pattern_walk only: required relation sequence to follow, e.g. ["domains", "capabilities", "elements"]. depends_on is normalized to dependencies.
- `phases` (array): maintenance_plan only: optional phase filter, e.g. ["repair", "link", "materialize"].
- `project` (string): domain_matrix/project_scope/project_map/agent_brief/meaning_repair_review: project root slug or unique alias. Required for meaning_repair_review; optional when exactly one kind: project node exists f…
- `recommendationLimit` (integer): health/workspace_brief/agent_brief only: positive integer max relation recommendations to inspect. Defaults to 20, capped at 500.
- `recordId` (string): analysis_record only: immutable analysis or diagnostic-review UUID.
- `relation` (string): Alias for type when operation is relation_check.
- `reviewRevision` (string): meaning_repair_review only: sha256 revision from meaningRepair:v2, binding graph/source/typed rows/target mtimes.
- `searchBudget` (integer): all_paths, query_plan(all_paths), and cycles: maximum DFS states to expand before returning partial results. Defaults to 5000. For cycles this is the only bound that fires on an ACYCLIC graph — when…
- `seed` (string): Alias for slug when operation is subgraph or builder_context.
- `severities` (array): maintenance_plan only: optional severity filter, e.g. ["fail", "warn"].
- `slug` (string): Center/root node slug or unique alias. builder_context also accepts its own canonical Workshop focusParam (for example domain:auth). Required for neighbors, reachability, pattern_walk, impact, blast_…
- `slugContains` (string): match_nodes only: optional case-insensitive substring filter on canonical slug.
- `sort` (string): match_nodes only: sort rows by degree, inDegree, outDegree, or slug. Defaults to degree.
- `targetOperation` (string): query_plan only: read-only graph operation to explain before execution. Excludes query_plan, meaning_repair_review, analysis_history and analysis_record.
- `task` (string): agent_brief detail:"compact" only: request-local coding task used to select persisted capability, element, and reviewed navigation evidence after Definition/Includes/Excludes compatibility. Conflicti…
- `title` (string): similar_nodes only: proposed title for a not-yet-written concept candidate.
- `to` (string): Target node slug or unique alias. Required for path, all_paths, and explain_relation.
- `toKind` (string): match_edges only: optional target kind filter (project, domain, capability, element, document, vault-readme, external, unresolved). Use external or unresolved for non-node refs.
- `type` (string): Relation type for relation_check/match_edges, e.g. depends_on, relates, contains, describes, domains, capabilities, elements, or domain.
- `types` (array): Optional relation types to include, e.g. ["dependencies"] or ["depends_on"].

Output parameters:

- `compiledSummary` (object)
- `operation` (string)

### `validate_vault` (~370 tokens)

R+ (cycle 46) — validate every doc in the vault, return per-doc + per-code aggregate. Replaces the K-round-trip pattern of `list_concepts` then per-doc `get_concept` (whose `warnings: [...]` is per-file). 8 issue codes — `unclosed-frontmatter`, `parse-zero-keys`, `malformed-frontmatter-line`, `malformed-quoted-scalar`, `missing-kind`, `empty-kind`, `unknown-kind`, `missing-uid`, `invalid-uid`, `invalid-merged-uids`, `non-canonical-merged-uids`, `missing-expected-field`, `non-canonical-graph-array`, `dangling-graph-reference`, `duplicate-slug`, `duplicate-uid`. Returns `{ scanned, problems: [{slug, issues: [{code, severity, message}]}], summary: { problemFiles, errorFiles, warningFiles, byCode: { code: { severity, count, files } } } }`. Also returns `pathDrift`: frontmatter `path:` / `elements:` source paths that no longer exist on disk (vault→code drift), resolved against `repoRoot` (default: the active resolved repository root from connection_info). Ontology-slug references are never flagged. Fix via `patch_concept` or remove the stale entry. side effect 0. Use when an agent needs the *whole-vault* health view: first-contact before writes, before / after a batch write, or surfacing issues to the user.

Input parameters:

- `repoRoot` (string): Repository root that frontmatter source paths resolve against, for the pathDrift check. Defaults to the active resolved repository root from connection_info. Pass this if the vault lives apart from t…

Output parameters:

- `pathDrift` (object): Vault→code path drift: frontmatter source paths missing on disk, resolved against repoRoot.
- `problems` (array)
- `scanned` (integer): Number of vault markdown files scanned.
- `summary` (object)

### `validate_wiki` (~388 tokens)

Judge the pages under `wiki/` against the wiki page contract (`docs/ONTOLOGY-ATLAS-SPEC.md` §11): no `kind:`, the seven required frontmatter fields, the five sections in order, a citation on every bullet under `## Facts`, and a cited path that is both declared in `sources:` and present in the folder. A wiki page is **not** an ontology node — it carries no `kind:` by contract, which is what keeps it out of the graph — so `validate_vault` says nothing about whether one fits its own shape. This is that answer. Problem codes: kind-present, missing-field:<key>, section-order, uncited-fact, bad-citation, bad-truncation-record, citation-target-missing, describes-needs-approval. The optional `sources_truncated:` key lists which paths in `sources:` the run read only part of; it is what lets a reader tell a document written up whole from one written up in part. Returns `{ pageCount, failingCount, pages: [{path, problems: [{code, message, line?}]}] }` — the same shape `ontology-atlas wiki-validate --json` prints, so a person and an agent read one report. side effect 0. Use it after writing or editing a page, and before claiming a compile finished.

Input parameters:

- `paths` (array): Vault-relative page paths to judge (`wiki/quarter-plan.md`). Omit to judge every page under `wiki/`, which has no cap because the folder decides how many there are. Max 50 when naming them, the same…

Output parameters:

- `failingCount` (integer): Pages with at least one problem. Zero means every page judged fits.
- `pageCount` (integer): Pages judged.
- `pages` (array)

### `read_source` (~379 tokens)

Read the text of one raw source under `sources/`, cut into the units a wiki citation names (`docs/ONTOLOGY-ATLAS-SPEC.md` §11): a DOCX by heading (`h:<slug>`; paragraphs before the first heading are `p1`), an XLSX by sheet and row (`s<n>r<m>`), a CSV by row (`r<n>`), a text or HTML file by line (`l<n>`). Each unit carries the exact anchor to write into `[[src:sources/<file>#<anchor>]]`, so a page cites what it quotes. A PDF returns no text: the agent runtime reads PDFs natively, page by page, and cites `#p<n>`. Nothing is converted and kept — the file is read on request and the text returned once. Paging: `from` (1-based unit index) and `limit` (default 200, max 1000); when `truncated` is true, `next` is the `from` to continue with. `sheet` narrows a workbook to one sheet number. Returns `{ path, format, unitCount, from, units: [{anchor, text, kind, heading?, sheet?}], truncated, next?, sha256, note? }`. side effect 0. Use it in place of a shell command when a Compile, Check or ask turn needs what a DOCX or XLSX says.

Input parameters:

- `from` (integer): 1-based index of the first unit to return. Default 1.
- `limit` (integer): Units to return at most. Default 200.
- `path` (string, required): Vault-relative path under `sources/` (`sources/plan.docx`).
- `sheet` (integer): XLSX only: return one sheet, by its number in workbook order.

Output parameters:

- `format` (string)
- `from` (integer)
- `next` (integer)
- `note` (string)
- `path` (string)
- `sha256` (string)
- `truncated` (boolean)
- `unitCount` (integer)
- `units` (array)

### `inspect_architecture` (~193 tokens)

Read one reviewed architecture-profile/v1 document from the active vault, scan the connected repository with the existing bounded static import analyzer, and return an architectureBrief:v1 for humans and coding agents. The profile declares scoped roles, intended dependency rules, and which known import usages those rules govern; source imports remain observed evidence with usage-qualified receipts. The result distinguishes conforms, violated, and unknown, and never treats unsupported languages, unclassified import usage, empty role mappings, or unmapped edges as compliance. Pattern labels are human/document declarations, not folder-name inference. side effect 0.

Input parameters:

- `maxFiles` (integer): Positive source-file scan cap (default 5000, max 50000).
- `profileSlug` (string): Architecture profile_slug. Optional only when the vault contains exactly one architecture profile.
- `rootPath` (string): Repository root to inspect. Defaults to the active resolved repository root from connection_info.

Output parameters:

- `agentPlanContract` (object)
- `conformance` (object)
- `contract` (string)
- `nextActions` (array)
- `profile` (object)
- `sideEffect` (integer)

### `infer_imports` (~1310 tokens)

R17 (autonomous ingest deeper) — walk TS/JS files in a code repo and infer file-level + module-level import edges. It also walks bounded root Python packages, bounded src/source-layout Python packages, and deterministic Rust use/file-module/literal-include dependencies. A valid root Go module additionally exposes typed local package-import evidence; it stays separate from legacy file edges and never self-approves a semantic relation. Structured `coverage` names the supported languages; Rust support is bounded static text evidence and does not expand macros, evaluate cfg, resolve symbols, or prove runtime impact. side effect 0 (vault frontmatter NOT modified). `moduleEdges` are source-backed review candidates, never self-approving semantic `depends_on` relations. When you know an implementation file, set `focusPath` (or `reviewMode:"focus"`) before considering `full`: Atlas returns bounded exact incoming/outgoing static import receipts, counts, and a cursor without requiring a vault. This focused source boundary is not runtime impact or a semantic relation. Omit `reviewMode` for size-safe automatic delivery: scans whose estimated full MCP result is at most 128 KiB keep the complete response; larger reconciled scans return exactly one compact, non-writing `nextRelationReview:v1` packet plus a delivery receipt and stateless cursor. Use `reviewMode:"next"` to request that bounded packet explicitly. `reviewMode:"full"` preserves the complete shape, but a result over 128 KiB additionally requires `allowLargeResponse:true`; this second confirmation prevents coding agents from accidentally opting into a multi-megabyte response. Oversized raw scans without a loadable reconciliation vault fail with an actionable error instead of emitting an unbounded default response. Every compact candidate carries `absentEndpoints`. If an endpoint is missing, `nextCalls` is empty and `endpointModelling` separates an evidence-only analysis call from the complete `rootPath + proposal` valida…

Input parameters:

- `afterReviewId` (string): `reviewMode:"next"` only. Pass the prior packet cursor.nextAfterReviewId to advance deterministically; omit to start at the first current candidate.
- `allowLargeResponse` (boolean): Confirmation for reviewMode:"full" only. Required when the estimated complete MCP result exceeds 128 KiB. It never changes scan contents or writes the vault.
- `focusAfterEdgeId` (string): Focus mode only. Pass the prior focusReview.cursor.nextAfterEdgeId to advance deterministically; omit to start at the first current edge.
- `focusDirection` (string): Focus mode only. Which exact file-level import direction to page (default both).
- `focusLimit` (integer): Focus mode only. Maximum exact import receipts returned in one page (default 50, max 100).
- `focusPath` (string): Repository-relative implementation file to inspect. Supplying focusPath with omitted reviewMode selects focus mode automatically. Returns bounded incoming/outgoing supported static import receipts; i…
- `ignore` (array): Extra folder names to skip (added to defaults: node_modules, dist, build, …).
- `maxFiles` (integer): Positive integer cap on files walked (default 5000, max 50000). Hard stop to avoid pathological monorepos.
- `reconcile` (boolean): Default true. When true, diff the inferred module edges against the vault's compiled depends_on edges and include `reconciliation` + `reconciliationSummary`. Set false to skip (raw scan only / no vau…
- `reviewMode` (string): Omit for automatic delivery unless focusPath is present. `focus` returns a bounded exact file-level import neighborhood for focusPath. Otherwise responses estimated at or below 128 KiB keep the compl…
- `rootPath` (string): Repository root to analyze. Defaults to the active resolved repository root from connection_info.
- `sourceFolders` (array): Source folders to walk (default: ['src','source','lib','app','apps','packages']). Nested scopes preserve repository-relative ontology endpoints. If none exist, falls back to rootPath.

Output parameters:

- `contract` (string)
- `coverage` (object)
- `delivery` (object): Present only when omitted reviewMode was automatically compacted because the estimated full MCP result exceeded the safe delivery boundary.
- `edges` (array)
- `externalImports` (array)
- `filesScanned` (integer)
- `focusReview` (object)
- `moduleEdges` (array)
- `nextReview` (object|null)
- `packageImportEvidence` (object): Root Go module-only, bounded package import evidence. It is observed static source evidence, never a runtime claim or semantic relation approval.
- `packageImportEvidenceSummary` (object): Bounded Go package-import census. Call fullEvidenceCall to retrieve the complete typed receipt; focusReview itself contains legacy file edges only.
- `reconciliation` (object|null): Module edges diffed against the vault's compiled depends_on edges (alias-normalized). null when no vault is loadable (e.g. scanning a foreign repo). Absent when reconcile:false.
- `reconciliationSummary` (object)
- `reviewQueue` (object)
- `rootPath` (string)
- `scanSummary` (object)
- `staleEdgeFollowUp` (object)
- `unresolved` (array)

### `index_project` (~283 tokens)

Project ontology indexing plan — run analyze_repo_structure + infer_imports + validate_vault in one read-only call. Use for large or already-existing projects where the agent needs a resumable ontology indexing checkpoint before writing. Its extractionContract treats source facts as observed evidence, README/folder meanings as proposals, and only persisted ontology meanings as shared; it also returns competency questions, uncertainty, approval gates, and whether active-vault validation actually applies to the analyzed project. The plan distinguishes raw candidates into existing, ambiguous-alias review, and genuinely new buckets, then returns exact reviewCalls for retrieving full rows. side effect 0: this tool never writes markdown. CLI `index --apply` may write analyzer-proposed concepts and containment, but inferred imports remain review-only and are never auto-promoted to depends_on.

Input parameters:

- `maxDepth` (integer): Folder walk depth forwarded to analyze_repo_structure (default 2, max 10).
- `maxFiles` (integer): File cap forwarded to infer_imports (default 5000, max 50000).
- `rootPath` (string): Repository root to index. Defaults to the active resolved repository root from connection_info.
- `skipImports` (boolean): When true, skip infer_imports and return an analyze + validate plan only.
- `threshold` (integer): Optional module-edge count threshold for the returned import relation plan.

Output parameters:

- `analyze` (object)
- `configurationEvidence` (object)
- `extractionContract` (object)
- `imports` (object|null)
- `meaningGate` (object)
- `mode` (string)
- `next` (object)
- `plan` (object)
- `rootPath` (string)
- `semanticEvidence` (array)
- `sideEffect` (integer)
- `validation` (object)
- `vaultRoot` (string)

### `analyze_repo_structure` (~1027 tokens)

R16 (autonomous ingest base) — analyze a code repository and propose ontology node candidates. side effect 0 (vault frontmatter NOT modified). Returns deterministic candidates the agent must turn into an evidence-backed proposal and move through the construction lifecycle before any exact batch-writer rows are released. Repository structure is implementation evidence, not automatic business meaning: extractionContract and proposedBusinessOntology make that uncertainty explicit. Detects:
  \- package.json `name` → project candidate
  \- README.md first H1 → project title fallback
  \- README.md H2 sections (skipping generic "Usage"/"Installation"/etc) → domain candidates
  \- src/features|entities|widgets|views/* (FSD) → capability/element candidates
  \- src/* depth-1 folders (generic) → capability candidates + index entry → element
  \- apps/* and packages/* members with package.json → implementation element candidates

  \- README.rst + bounded static setup.py → Python project/package evidence without execution
  \- mixed current and future/negated/deprecated README prose → exact current candidate excerpt plus bounded line-scoped `reviewRequiredEvidence`; review units stay visible but cannot support a proposal claim
  \- selected safe README sections share the existing 1,200-character budget deterministically; no document, heading, or excerpt cap grows
  \- root Python packages plus at most 12 import-connected implementation boundaries → direct modules plus up to 2 exact security/policy/risk file anchors; unused files are not mirrored and no capability is inferred from imports
  \- bounded root Cargo package or repo-contained literal direct workspace members → typed feature declaration + literal cfg/cfg_attr source provenance; predicates are not evaluated and no runtime/import/semantic dependency is inferred
  \- a complete proposal may select at most 4 additional exact TypeScript, JavaScript, Python, or Rust file endpoints already observed by infer_imports for distinct navi…

Input parameters:

- `ignore` (array): Extra folder names to skip (added to defaults: node_modules, .git, dist, build, …).
- `maxDepth` (integer): Non-negative integer folder walk depth (default 2, max 10). Higher → more elements.
- `proposal` (object): Optional business ontology proposal to validate against repository evidence before any write call. Python proposals may select at most 4 exact observed import endpoints beyond the analyzer candidates.
- `qualification` (object): Optional independent evaluation and declared human acceptance bound to the exact planDigest, planRevision, and sourceDigest returned for this proposal. Omit it on the first review call.
- `rootPath` (string): Repository root to analyze. Defaults to the MCP server cwd.

Output parameters:

- `capabilities` (array)
- `configurationEvidence` (object)
- `domains` (array)
- `elements` (array)
- `extractionContract` (object)
- `framework` (string)
- `meaningGate` (object)
- `project` (object)
- `proposalValidation` (object)
- `rootPath` (string)
- `semanticEvidence` (array)
- `skipped` (array)
- `suggestedRelations` (array)

### `rename_concept` (~436 tokens)

⚠ MULTI-FILE WRITE — change a slug and update every backlink in one atomic graph-level operation. The node UID is preserved; only its current human-readable slug changes. Renames the .md file (oldSlug → newSlug, directory move OK), updates the moved file's frontmatter `slug:` key, and rewrites every backlink — frontmatter array entries (capabilities / elements / dependencies / relates / contains / describes), inline-string keys, and body links `[[oldSlug]]` / `(oldSlug.md)`. Tail-only references (`mcp-server` for `capabilities/mcp-server`) are also redirected to the new tail. Two-stage safety:
  1\. Without confirm: true the call is a dry-run — returns `updates` (each affected file with before/after array keys + bodyChanged flag) without writing.
  2\. With confirm: true the file is moved and all backlinks are rewritten in one pass.
Throws if oldSlug missing or newSlug already taken (unless overwrite: true). Use this instead of patch_concept + N find_backlinks + N patch_concept loops. Confirmed writes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers for the final graph.

Input parameters:

- `confirm` (boolean): Actually perform the rename when true. Omit or false for a dry-run preview.
- `expected_mtime` (number): Optional conflict guard for oldSlug. Pass the `mtime` from get_concept; throws VaultConflictError if the source has been modified externally since you read it.
- `newSlug` (string, required): Target vault-relative slug (omit the .md extension). Directories are created if needed.
- `oldSlug` (string, required): Current vault-relative slug (omit the .md extension).
- `overwrite` (boolean): Allow overwriting an existing file at newSlug. Defaults to false (throws if newSlug exists).

Output parameters:

- `backlinkUpdates` (object)
- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `changed` (boolean)
- `dryRun` (boolean)
- `message` (string)
- `moved` (boolean)
- `newSlug` (string)
- `ok` (boolean)
- `oldSlug` (string)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `sourcePath` (string)
- `targetPath` (string)
- `uid` (string)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `reclassify_concept` (~142 tokens)

⚠ MULTI-FILE WRITE — change a concept kind and optionally its canonical slug/domain in one previewable transaction. The permanent UID is preserved. Redirects backlinks like rename_concept and replaces a generated starter body with the new kind template while preserving custom prose. Defaults to dry-run.

Input parameters:

- `body` (string): Optional explicit replacement body.
- `confirm` (boolean)
- `domain` (string|null): New domain; required for capability/element.
- `expected_mtime` (number)
- `newKind` (string, required)
- `newSlug` (string): Optional new canonical slug.
- `slug` (string, required): Current canonical slug.

Output parameters:

- `backlinkUpdates` (object)
- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `bodyAction` (string)
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `changed` (boolean)
- `dryRun` (boolean)
- `newKind` (string)
- `newSlug` (string)
- `ok` (boolean)
- `oldKind` (string)
- `oldSlug` (string)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `sourcePath` (string)
- `targetPath` (string)
- `uid` (string)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `merge_concepts` (~352 tokens)

⚠ DESTRUCTIVE MULTI-FILE WRITE — fold one node into another. Every backlink to fromSlug is redirected to intoSlug (frontmatter array entries + body links), then fromSlug is deleted. The survivor keeps its UID while the source UID/history is recorded in canonical `merged_uids`. The intoSlug prose and non-identity frontmatter are preserved as-is — they are not merged automatically (use patch_concept after if you want to combine descriptions). Tail-only references are also redirected. Two-stage safety:
  1\. Without confirm: true the call is a dry-run — returns the redirect plan + list of deletions without writing.
  2\. With confirm: true the rewrites and the delete happen in one pass.
Throws if either slug is missing. Confirmed writes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers for the final graph.

Input parameters:

- `confirm` (boolean): Actually perform the merge when true. Omit or false for a dry-run.
- `expected_into_mtime` (number): Optional conflict guard for intoSlug. Pass the survivor mtime from get_concept so a concurrent edit or identity-history change is never overwritten.
- `expected_mtime` (number): Optional conflict guard for fromSlug. Throws if the source has been modified externally.
- `fromSlug` (string, required): Slug to dissolve. Its file is deleted after backlinks redirect.
- `intoSlug` (string, required): Slug to keep. Receives every redirected backlink.

Output parameters:

- `absorbedUids` (array)
- `backlinkUpdates` (object)
- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `capturedFrom` (object)
- `changed` (boolean)
- `deleted` (boolean)
- `dryRun` (boolean)
- `fromPath` (string)
- `fromSlug` (string)
- `fromUid` (string)
- `intoSlug` (string)
- `intoUid` (string)
- `message` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `delete_concept` (~318 tokens)

⚠ DESTRUCTIVE — permanently deletes the vault .md file. Two-stage safety:
Both preview and confirmed responses identify the node by permanent `uid` plus current `slug`.   1. Without confirm: true the call is a dry-run — returns a backlinks preview without deleting.
  2\. If any backlinks exist the call throws — refuses while other nodes still reference this slug. Pass force: true to delete anyway (the referrers become dangling).
Successful deletion returns the frontmatter + body so a user who deleted by mistake can recreate the node via add_concept. Directories are left untouched. Pass `expected_mtime` to guard against concurrent external edits — throws if the file changed on disk since you read it. Confirmed deletes return compact `postWriteMaintenance` (maintenance_plan) with count-safe `byPhase` / `bySeverity` / `byKind` queue buckets, action `score`, executable `proposedAction`, and current-page `nextExecutableAction` / `nextReviewAction` pointers for the final graph.

Input parameters:

- `confirm` (boolean): Actually delete when true. Omit or false for a dry-run (backlinks preview, no delete).
- `expected_mtime` (number): Optional conflict guard — file mtimeMs at read time. If it differs at delete time, the call throws.
- `force` (boolean): Delete even when backlinks exist (referrers become dangling). Defaults to false.
- `slug` (string, required): Vault-relative slug (omit the .md extension).

Output parameters:

- `backlinks` (array)
- `backlinksAtDelete` (array)
- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `captured` (object)
- `changed` (boolean)
- `dryRun` (boolean)
- `filePath` (string)
- `forced` (boolean)
- `message` (string)
- `ok` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `slug` (string)
- `uid` (string)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.

### `absorb_document` (~440 tokens)

Slice 0 (PRODUCT-PLAN-2026-07.md §4/§9) — the "absorption tool". Converts a CLAUDE.md/AGENTS.md-style markdown file into typed vault nodes so a tech lead's existing agent-instruction file stops needing dual maintenance. Splits the file by `##` sections and classifies each:
  \- rule/policy/decision sections → `kind: document` nodes with a `role: policy` frontmatter extra.
  \- architecture/component sections → element/capability SUGGESTIONS only — never auto-written; review and land with add_concept if useful.
  \- sections matching an injection-suspect pattern (Tier 1 — imperative instruction-hijack phrasing, shell/SQL fragments) are excluded from absorption regardless of category and reported for human review. The file body is always treated as untrusted data; parsing never executes or evaluates its content.
Two-stage safety, same shape as delete_concept:
  1\. Without confirm: true the call is a dry-run — returns the classification plan per section, no writes.
  2\. With confirm: true, absorbed sections are written as document nodes, the source file is backed up to `<file>.pre-absorb.bak`, then rewritten into a "slim pointer" that reproduces every non-absorbed section (suggested, unclassified, or injection-suspect) verbatim — content is never destroyed. Throws instead of overwriting an existing backup file. The canonical source path must be inside repoRoot; outside paths (including symlink escapes) require an reviewed dry-run plus explicit allowOutsideRepo:true.

Input parameters:

- `allowOutsideRepo` (boolean): Explicit destructive opt-in required only when filePath resolves outside repoRoot. Dry-run reports outsideRepo and keeps canConfirm:false without it.
- `confirm` (boolean): Actually write when true. Omit or false for a dry-run (plan only, no writes).
- `filePath` (string, required): Path to the CLAUDE.md/AGENTS.md-style markdown file to absorb (absolute, or relative to the MCP server cwd).

Output parameters:

- `backupPath` (string)
- `blockedReasons` (array): Machine-readable human explanations for every condition currently blocking confirmation.
- `canConfirm` (boolean): True only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
- `changed` (boolean)
- `dryRun` (boolean)
- `filePath` (string)
- `message` (string)
- `ok` (boolean)
- `outsideRepo` (boolean)
- `postWriteMaintenance` (object): Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.
- `previewReady` (boolean): True only when this response is a complete dry-run preview that an agent can review.
- `sections` (array)
- `sourceLabel` (string)
- `summary` (object)
- `title` (string|null)
- `wouldChange` (boolean): True only when the dry-run predicts a disk or Git change.
- `written` (array)

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m#diagnostics

## Score history

- 2026-09-21: 47
- 2026-09-20: 46
- 2026-09-19: 46
- 2026-09-18: 42
- 2026-09-17: 42
- 2026-09-16: 42
- 2026-09-15: 42
- 2026-09-14: 42
- 2026-09-13: 42
- 2026-09-12: 42
- 2026-09-11: 42

## Common questions

### What is the Ontology Atlas MCP server?

Ontology Atlas is an MCP server listed in the public MCP registry as io.github.wlsdks/ontology-atlas. Read and write one codebase ontology kept as Markdown in the repository. This page covers its MCPB bundle (https://github.com/wlsdks/ontology-atlas/releases/download/v1.2.0/ontology-atlas-mcp-0.13.0.mcpb).

### Is the Ontology Atlas MCP server safe to use?

Ontology Atlas scores 47 out of 100 on VerifyMCP. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Ontology Atlas MCP server expose?

Ontology Atlas exposes 38 tools: connection_info, git_status, git_history, git_snapshot, list_concepts, and 33 more. Their descriptions and schemas cost roughly 15,600 tokens of context every time the server is loaded.

### What licence is the Ontology Atlas MCP server under?

Ontology Atlas declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- Repository: https://github.com/wlsdks/ontology-atlas
- Website: https://ontologyatlas.com/
- Changelog RSS feed: https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m.xml
- Changelog JSON feed: https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m.json
- HTML version of this page: https://verifymcp.io/servers/wlsdks-ontology-atlas/https-github-com-wlsdks-ontology-atlas-releases-download-v1-2-0-ontology-atlas-m