data-olympus MCP server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@data-olympus MCP serverfind all accepted decisions in tier T1"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
data-olympus
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 designed to be readable by Open Knowledge Format (OKF) 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. Formal conformance testing against the OKF reference tooling is not yet in place (tracked in issue #82). 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. Latest release: v0.4.1.
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, ortype: decisionwithout post-processing. Thesupersedeschain makes it possible to trace decision history across the graph.Designed to be OKF-readable. Built on OKF's directory structure, frontmatter conventions, reserved filenames, and link model; formal conformance testing against OKF reference tooling is tracked in issue #82, not yet implemented.
Related MCP server: md-graph
Quickstart
Requires Python 3.13+ and uv.
# Install
uv venv && uv pip install -e '.[dev]'
# Lint the example bundle
uv run data-olympus lint example-bundle
# ...or scaffold your own bundle instead of copying example-bundle/
uv run data-olympus init my-kb
# Start the MCP server against the example bundle
./scripts/run-local.shSee docs/quickstart.md for the full local-run walkthrough, including curl and kb CLI queries. 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), and the health/alerting model.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/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 indocs/comparison.md.SECURITY.md: supported versions and how to report a vulnerability.
License
Maintenance
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/knaisoma/data-olympus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server