Back to Browse

Mitos MCP Server

Developer ToolsUse Caution4.2MCP RegistryLocal
Free

Server data from the Official MCP Registry

Architectural decision memory for LLM-native workflows — markdown for humans, a graph for agents.

About

Architectural decision memory for LLM-native workflows — markdown for humans, a graph for agents.

Security Report

4.2
Use Caution4.2High Risk

Mitos is a well-structured architectural decision recording system with reasonable security posture for its category. The codebase demonstrates good engineering practices with proper error handling and auth awareness. However, there are several moderate concerns: API keys are stored in environment variables with some potential logging exposure, the code makes extensive external API calls to Gemini and Anthropic without comprehensive input validation, and there is some handling of user-supplied text that could benefit from stricter sanitization. Permissions align appropriately with the server's purpose as a developer tool requiring network and file I/O access. Supply chain analysis found 10 known vulnerabilities in dependencies (0 critical, 3 high severity). Package verification found 1 issue.

3 files analyzed · 17 issues found

Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.

Permissions Required

This plugin requests these system permissions. Most are normal for its category.

File System Read

Reads files on your machine. Normal for tools that analyze or process local data.

File System Write

Writes or modifies files on your machine. Check that this is expected for the tool.

HTTP Network Access

Connects to external APIs or services over the internet.

env_vars

Check that this permission is expected for this type of plugin.

database

Check that this permission is expected for this type of plugin.

Shell Command Execution

Runs commands on your machine. Be cautious — only use if you trust this plugin.

How to Install

Add this to your MCP configuration file:

{
  "mcpServers": {
    "io-github-dovahkiin-v-mitos": {
      "args": [
        "mitos-adr"
      ],
      "command": "uvx"
    }
  }
}

Documentation

View on GitHub

From the project's GitHub README.

Mitos

Status: Alpha PyPI Python 3.13+ License: Apache-2.0 MCP Registry

🔧 Early release — actively developed

When you build software with AI assistants over months, the reasoning behind your decisions gets lost. The assistant forgets why you chose one approach, re-suggests options you already rejected, and your design notes drift out of sync with what was actually decided. Mitos is a memory layer for those decisions: it records each decision, the alternatives you ruled out, and how later decisions replace earlier ones — then feeds that history back to your AI assistant in a compact, trustworthy form.

The result: your AI collaborator stays consistent with the calls you've actually made — it stops contradicting a past decision or re-opening a settled question, and your decision record never silently rots.

Under the hood: markdown for humans (decisions.md is the source of truth you can always read and grep), a typed graph for the agents (SQLite + a local Qdrant for semantic recall), and an MCP server so agents check precedent before deciding and record decisions as they make them.

Available on PyPI and the MCP Registry.


Fastest install: hand it to your agent

If you work with an AI coding agent (Claude Code, Cursor, Gemini CLI, …), the easiest path is to let it do the setup. In the project you want mitos in, give your agent:

Read https://github.com/dovahkiin-v/mitos/blob/main/SETUP.md and set up mitos
for this project. When done, run `mitos status .` from the project directory
and report the result.

What your agent will end up doing — the same steps a human follows, all in SETUP.md where you can read them first:

  • install the mitos CLI via pipx (from PyPI or this repository);
  • start a local Qdrant container (qdrant/qdrant on port 7333, isolated from any Qdrant you already run);
  • register the MCP server once for the whole machine, if it isn't registered already;
  • initialize the project workspace, which also registers the project by name;
  • ask you to set your API keys yourself (mitos set-key) — a Gemini key (required), and an Anthropic key for the conflict-audit layer (strongly recommended); the setup guide tells agents not to handle key values.

How much your agent asks along the way is governed by your own agent's settings, not by this prompt.

Manual setup

The same steps by hand — full detail in SETUP.md:

  1. Install (once per machine): pipx install mitos-adr
  2. Start Qdrant (once per machine, shared by all projects): docker compose up -d from this repo — mitos runs its own instance on :7333, so it never touches a Qdrant you use for other work.
  3. Register the MCP server (once per machine, recommended for agents): claude mcp add --scope user mitos -- mitos serve. One registration serves every project — see SETUP.md for what it costs, for other harnesses, and for why a leftover per-project .mcp.json entry has to go.
  4. Per project: mitos init from the project root, then mitos set-key --global <your-Gemini-key> (one key covers everything; get it at https://aistudio.google.com/app/apikey). Gemini is the tested embedding provider today; a multi-provider abstraction is on the roadmap.
  5. Verify: mitos status .READY ✓.

mitos status . is the compass throughout: it says exactly what's done, what's missing, and what to do next for that project. With no project named, mitos status answers the other question — what does this machine have — listing every registered project and checking Qdrant.

Every command names its project. There is no default target: mitos init registers the project by name, and from then on each verb takes -p <name>, -p <absolute path>, or -p . from the project root (agents pass the same thing as a project argument). mitos projects lists what's registered. That is what lets one install and one MCP server serve every project on the machine without a call ever landing in the wrong corpus.

How it runs

Mitos is per-project — each project gets its own decision graph and its own Qdrant collection. Day to day, three verbs carry the loop (as MCP tools for agents, with identical CLI twins):

VerbWhen
surface_decisions (mitos surface)Before deciding — is there precedent? Every hit carries the alternatives that were already rejected and why.
record_decision (mitos record)The moment something is settled — the decision, the rejected paths, and how it relates to prior decisions (supersedes, amends, …).
query_decisions (mitos query)Looking something up — by meaning or by exact handle.

A few properties worth knowing:

  • The markdown is the source of truth. Every decision lands in decisions.md, human-readable and greppable; the graph and the search index are derived from it and can always be rebuilt (mitos rebuild).
  • Decisions are never edited or deleted — they're superseded. State (active / superseded / amended) is computed from typed relations between decisions, so the history of why always survives.
  • It fails safe. If the search index or the embedding API is down, recording still works and search degrades to an honest text-match over the markdown — nothing blocks, nothing is lost, and degraded output says it's degraded.
  • It audits itself. The corpus sweep (mitos check -p .) finds decisions that silently contradict each other, and --staged gates new entries as a pre-commit or CI step — see SETUP.md for the hook, CI and cron recipes, which name their project three different ways.

Explore the rest with mitos --help — the help text doubles as the API reference.

Why it exists

Building software through intensive LLM design reviews produces architectural decisions faster than a person can track. One month of that working style produced close to 900 decision records in a single markdown file — no longer greppable, readable, or manageable by hand. Existing ADR tools are built for human teams logging the occasional decision; mitos is built for a solo developer whose AI assistants generate and consume decisions continuously.

If that's your way of working, project size doesn't matter much — the higher the decision volume, the faster mitos moves from comfort to necessity.

Development

pip install -e '.[test]'
MITOS_NO_LIVE_TESTS=1 pytest -m "not packaging" -n auto   # offline suite, parallel (~50s)
pytest -m "not packaging"                                 # adds the live tier — serial only
pytest -m packaging                                       # real-install check: fresh venv + pip install

-n auto is safe for the offline suite and not for the live tier: the test-collection sweep is session-scoped, so parallel workers delete each other's Qdrant collections and the affected tests degrade to skips rather than failures.

The *_live.py suites and golden Layer B make real Gemini and Anthropic API calls against your own keys, and need Qdrant on :7333. They skip when no key is resolvable, so a fresh clone runs the fast path by default.

Keys resolve from the environment, a repo-root .env, or ~/.config/mitos/.env — so if you already use mitos, a test run can pick up your personal key and spend against it. Opt out explicitly:

MITOS_NO_LIVE_TESTS=1 PYTHONPATH=. pytest -m "not packaging"

The canonical decision format lives in mitos/format-spec.md. License: Apache 2.0.

Reviews

No reviews yet

Be the first to review this server!