Skip to main content
Glama
data-olympus MCP server

data-olympus MCP server

data-olympus

knaisoma/data-olympus MCP server MCP Marketplace

New here? Start with WHY.md. It is the story behind the project: the problem we kept hitting with coding agents, what data-olympus does differently, how it relates to Google's Open Knowledge Format, and where our benchmarks say it is strong and where it is not. The rest of this README is the technical reference.

data-olympus is a governance-grade knowledge-base format and server for agent workforces. It is readable by Open Knowledge Format (OKF) v0.2 consumers: it inherits OKF's directory structure, frontmatter conventions, reserved filenames, and link model, then layers governance extensions on top (stable id, controlled type/status/tier fields, supersedes chains) plus a single-writer MCP server and a CLI. CI proves two concrete directions against official Google OKF v0.2 commit ad30107c31c06aec8a7d5636e0d1058118604e6f: its reference visualization consumer reads every concept in example-bundle, and data-olympus imports, lints, indexes, searches, and retrieves the pinned official Bitcoin sample. This is fixture-scoped interoperability evidence, not a blanket guarantee for every OKF bundle or future upstream revision. The result is a git-native, version-controlled document graph of engineering standards, architectural decisions, and project knowledge that agents and humans can read, search, and extend without any proprietary service.

It governs decisions, not code. When an agent is about to make a choice (a library, a pattern, a migration), data-olympus surfaces the established standard or decision that should govern that choice. It is deliberately not a code-search, reference-finding, or "where is X used" tool: LSP, grep, and Sourcegraph already do that well. The retrieval task it targets is coding-intent to governing-rule, and it helps where current model interaction during vibe-coding is weakest: keeping the model aligned to patterns the team has already established as correct.

Status: pre-1.0 beta. Stable releases are distributed through PyPI and GHCR.

Why

  • Portable, no lock-in. The entire KB is a directory of markdown files in git. No database, no proprietary schema, no vendor.

  • Git-native diffs and review. Every change is a commit. Proposed edits go through a pending queue before commit; history is plain git log.

  • Agent and human readable. Plain markdown with YAML frontmatter. No SDK required to read or author a document.

  • Governed multi-agent writes. The single-writer MCP pipeline (advisory locks, per-session worktrees, durable push queue) prevents concurrent write races without requiring distributed locking infrastructure.

  • Queryable by status, tier, and type. Filter by status: accepted, tier: T1, or type: decision without post-processing. The supersedes chain makes it possible to trace decision history across the graph.

  • Tested with official OKF tooling. CI pins an exact Google OKF revision and proves both consumption directions over committed fixtures. The pin, fixture checksum, and Apache 2.0 license provenance live in tests/okf/reference.json.

Related MCP server: Knowledge MCP

Quickstart

Requires Python 3.13+ and uv. Run the stable CLI directly from PyPI:

uvx --from data-olympus data-olympus --help

Install it persistently when you are ready to create a bundle and run the server:

uv tool install data-olympus
data-olympus init my-kb
data-olympus-mcp --help

An announced candidate remains opt in through its exact PyPI version. Replace X.Y.ZrcN with the candidate named on the releases page, if any:

uvx --from 'data-olympus==X.Y.ZrcN' data-olympus --help

See release channels for what each channel means, how to verify a candidate before adopting it, and how to roll back.

See docs/quickstart.md for bundle initialization, server startup, readiness, agent registration, and the contributor source installation.

See docs/adoption.md for the full bundle authoring guide.

Documentation

  • SPEC.md: format specification (bundle layout, frontmatter schema, serving contracts).

  • docs/quickstart.md: verified local-run procedure.

  • docs/adoption.md: bring-your-own-KB guide (author, lint, index, serve, wire an agent).

  • docs/serving.md: single-replica serving model, read-only replicas, git pull loop, health/readiness/liveness split, proxy headers, audit-log rotation.

  • docs/operations.md: production runbook: backup, upgrade, recovery playbooks (degraded/fetch-failed, history rewrite, frozen/demoted push entries, orphaned locks), the health/alerting model, and release channels (stable and candidate, verification, rollback).

  • docs/comparison.md: how data-olympus relates to OKF, enterprise catalogs, markdown KB tools, agent-context conventions, RAG, and ADR tooling.

  • docs/okf-profile.md: field-by-field OKF profile: which governance extensions are stable, which are runtime-only serving fields, and which are experimental candidates.

  • docs/glama.md: Glama registry claim, release, and score-maintenance notes.

  • docs/mcp-registry.md: official MCP Registry notes, what server.json declares, and the checklist for publishing.

  • docs/enforcement.md: turning the KB into a mandatory consultation gate (hooks, kb enforce).

  • benchmarks/README.md: retrieval benchmark methodology and how to reproduce the numbers in docs/comparison.md.

  • SECURITY.md: supported versions and how to report a vulnerability.

License

Apache 2.0. See LICENSE and NOTICE.

Available Tools

9 tools
call_toolA

Call a tool by name with the given arguments.

Use this to execute tools discovered via search_tools.

Inputs: name (required), arguments.

kb_consultKB ConsultA

Record a consultation for (source_session, workspace) and return the governing rules for the intent. Call before code/architectural work. trigger is 'explicit' (default: a deliberate consult, clears the gate) or 'prompt_hook' (an installer auto-consult: audited, never clears).

Retrieval is hard-filtered to the in-force class (active/accepted/ approved, within its validity window, and never a memory-inbox doc): an unreviewed proposed memory, a retired/superseded decision, an expired doc, or a legacy/forged inbox file is never returned as a governing rule.

pending_actions, when present, lists open maintenance items (missing status fields, recently-expired/expiring-soon docs); omitted when the corpus is clean. Surface it to the operator and act on it only with operator confirmation.

Inputs: intent (required), workspace (required), agent_identity (required), source_session (required), +1 more. Returns: object

kb_gate_checkKB Gate CheckA

Return a verdict (allow | consult_required) for a pending code action. Governed actions require a fresh consultation on record. Records each check to the audit log (non-destructive; readOnlyHint=false is intentional). Use this in a PreToolUse hook to verify a specific pending action before execution; use kb_consult instead when proactively reading governing rules at the start of a session rather than checking individual actions.

Inputs: tool_name (required), workspace (required), session_id (required), action_diff, +1 more. Returns: object

kb_getKB Get DocumentA
Read-onlyIdempotent

Retrieve a document by id (STD-U-001, ADR-002, T-NNN, etc.). Returns the full content markdown plus metadata. Use this when you have a specific id (from kb_search results or session memory); use kb_search instead when you need to find a document by topic.

Always resolves regardless of expiry (ids never dangle): an expired document is still returned, with its full validity object and a computed freshness indicator (stale/expired/upcoming).

Derivation cues (ids only, for a person to review; nothing is filtered or demoted because of them): derived_from lists the documents this one draws from; derived_from_retired lists those that have left force, only while this document is itself in force; and dependents_to_review lists the in-force documents that derive from this one, only while this document is retired.

verbose: False (default) returns the full content_markdown body (kb_get exists to read the doc) with a trimmed envelope: path, git_remote_url, and last_modified_source are dropped and empty status/type/applies_when/description/validity/freshness are omitted; source_commit and last_modified provenance are kept, and in_force: false is emitted when the computed in-force predicate says the doc does NOT currently govern (deviation-only; an in-force doc omits the key). verbose=True returns the full legacy envelope with every field plus the computed in_force: bool (the single-sourced status + validity-window + not-inbox predicate; never stored in frontmatter).

Inputs: id (required), verbose. Returns: object

kb_healthKB HealthA
Read-onlyIdempotent

Return service health: kb_commit, index_built_at, staleness, degraded flag, and write-side state (pending_count, push_queue_size, last_index_*).

verbose: False (default) returns a token-compact shape that keeps the core snapshot and OMITS diagnostic fields that are null/empty (e.g. last_index_error, remote_head_sha when unset). verbose=True returns every field including the nulls.

pending_actions, when present, lists open maintenance items (missing status fields, recently-expired/expiring-soon docs) computed at the last index build; it is omitted when the corpus is clean. Surface it to the operator and act on it only with operator confirmation.

Inputs: verbose. Returns: object

kb_record_eventKB Record EventA

Append a durable, non-destructive audit entry for a client-reported enforcement event. Requires write capability (not a read-only tool).

event_type is gate_bypass (agent proceeded despite a gate block) or gate_degraded (kb_gate_check was unavailable; last-known state used). workspace, agent_identity, source_session are required; reason is optional but recommended for gate_bypass entries.

Use this when an enforce hook bypassed or degraded the gate and the fallback must be recorded. To check gate status use kb_gate_check; to consult use kb_consult; to read back events use kb_audit or kb_compliance.

Inputs: workspace (required), event_type (required), agent_identity (required), source_session (required), +1 more. Returns: object

kb_session_recapKB Session RecapA
Read-onlyIdempotent

Read-only per-session write summary (issue #112 feedback loop): N committed, M demoted-to-pending, K rejected for source_session. Call this (or kb pending) whenever a write response indicated a demotion, to confirm the current tally before informing the operator.

Inputs: source_session (required). Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4/5.0

    Scored across 9 tools

    Disambiguation4/5

    Each tool has a fairly distinct role and the descriptions explicitly contrast the closest pairs (kb_get vs kb_search by id vs topic; kb_consult vs kb_gate_check for proactive reading vs per-action verdict; tool_search discovers, call_tool executes). The only mild overlap is consult/gate_check, both of which concern governing-rule compliance, but the guidance for when to use each is explicit.

    Naming Consistency4/5

    Seven tools share a clean kb_ prefix with predictable verb/verb_noun forms (kb_get, kb_search, kb_consult, kb_gate_check, kb_health, kb_record_event, kb_session_recap). The two meta-tools (call_tool, tool_search) break the prefix scheme and call_tool is a notably generic name, but overall style is consistent snake_case.

    Tool Count5/5

    Nine tools is well within a healthy scope for a knowledge-base/governance server, and each named tool maps to a distinct operation (retrieve, search, consult, gate, health, audit-write, recap, plus dynamic discovery/execution). No tool feels like filler.

    Completeness2/5

    Several tools explicitly point to operations that are absent from the surface: kb_record_event tells agents to read events back via kb_audit or kb_compliance, kb_search references kb_curate, and kb_session_recap references 'kb pending' — none of which exist here. There is also no document write/curation or status-remediation tool, so the pending_actions maintenance loop the server advertises cannot actually be closed.

    Maintenance

    ActivityActive
    ResponsivenessSyncing

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      A
      quality
      D
      maintenance
      Automatically organizes and merges learned CS knowledge into a graph structure using Claude for entity/relation extraction and SQLite for storage, with tools for ingestion, querying, merging, and managing nodes and edges.
      6
      -
    • A
      license
      Not graded
      quality
      B
      maintenance
      A local OKF-compatible knowledge engine for AI agents. Enables capturing agent conversations, hybrid semantic+keyword search, MCP serving to agents, interactive graph visualization, and OKF bundle export.
      Apache 2.0