Does Moxie Docs replace Sphinx or pdoc?

No. Sphinx, mkdocstrings, and pdoc build per-symbol API reference from docstrings, and they are good at it. Moxie Docs writes and maintains architecture, conventions, API surface, and setup docs from the repository, and checks them for drift on every merge. Keep your reference site if you publish a library.

Which Python frameworks does it detect routes for?

FastAPI and Flask decorators on any app, router, or blueprint variable, with an APIRouter prefix or Blueprint url_prefix applied when it is set in the same file. Django path() and re_path() in urlpatterns, DRF router.register, and Starlette Route and WebSocketRoute. Prefixes added in another file with include_router or include() are not applied yet.

Which package managers and tools does it understand?

Dependencies are read from pyproject.toml (PEP 621, optional dependencies, dependency groups, and Poetry tables), requirements*.txt, setup.cfg, setup.py list form, and Pipfile. Check commands are detected for pytest, ruff, flake8, black, mypy, pyright, tox, nox, and Makefile targets, run through uv, Poetry, PDM, Hatch, or Pipenv when the repo uses them.

Does it work with Django and monorepos?

Yes. Django URL configs are read for routes, and imports resolve from any package root or src/ layout. On a monorepo, docs are matched to the paths they cite. Check commands are currently detected from root-level manifests only.

Will it edit our existing docs?

Existing Markdown and reStructuredText are indexed and checked for drift, not overwritten. Changes to files in your repository only arrive as pull requests your team reviews and merges.

Python repositories

Documentation for Python codebases, kept current from the code

Sphinx and pdoc turn docstrings into API reference. Moxie Docs covers the rest: how the project is laid out, which routes it serves, what it depends on, how to run its checks, and the conventions a new engineer or coding agent should follow - re-checked every time the code merges.

Quick Answer: Moxie Docs reads Python repositories structurally, not just as text. It captures top-level and decorated functions and classes per module (honoring __all__), resolves relative and package imports (including src layouts), extracts FastAPI, Flask, Django, DRF, and Starlette route paths, reads dependencies from pyproject.toml, requirements files, setup.cfg, and Pipfile, and detects the project's real check commands such as uv run pytest or poetry run ruff check. It uses that to write architecture and convention docs and keep them current on every merge.

Structure, not just text. Functions, classes, and imports are read per module and linked into an import graph.
Your stack, detected. uv, Poetry, PDM, Hatch, pytest, ruff, mypy, tox, and nox are picked up from the repo.
Checked on merge. Docs that cite a changed module are re-checked before they drift.

Connect a Python repo See a live demo

What you get

What Moxie Docs reads in a Python repo

API routes

FastAPI and Flask decorators on any router or blueprint (with same-file prefixes), Django path() and re_path(), DRF router.register, and Starlette Route.

Import graph

Relative imports, dotted package imports, __init__.py packages, and src/ layouts resolve to real files, so PR checks know which modules depend on a change.

Dependencies and conventions

Libraries come from pyproject.toml (PEP 621, Poetry, uv groups), requirements*.txt, setup.cfg, and Pipfile, matched to imports like yaml to PyYAML.

Real check commands

Agents get the commands your repo actually uses - uv run pytest, poetry run ruff check ., tox, nox, or Makefile targets - instead of a guess.

Tests recognized

test_*.py, *_test.py, tests/ folders, and conftest.py count as tests, not as undocumented source.

Symbols with context

Top-level and decorated functions and classes are captured per module, and __all__ decides what counts as public.

How it works

From a Python repo to current docs

01
Connect GitHub
Install the app on the Python repositories you want covered. Virtualenvs, site-packages, __pycache__, and egg-info folders are skipped.
02
First index
Moxie Docs reads the source, resolves imports, reads manifests and tool config, and writes the architecture, conventions, API surface, and setup pages.
03
Agents read it
Cursor, Claude Code, and Codex get the same docs, conventions, and check commands over MCP before they edit.
04
Merges keep it true
Every merge re-checks the pages that cite changed files. Fixes arrive as docs-only PRs your team reviews.

Scope

Where Moxie Docs fits next to Sphinx, MkDocs, and pdoc

Python already has good tools for API reference. Moxie Docs does not replace them, and it is honest about the overlap.

Sphinx with autodoc, mkdocstrings, and pdoc render a page per module from your docstrings. That is the right tool for a public library's reference. What they do not do is explain how an application fits together, notice when a merged change made a guide wrong, or tell a coding agent how your team writes code.

Moxie Docs writes that descriptive layer from the repository and keeps it current. Many teams run both: a docstring reference site for the public API, and Moxie Docs for architecture, conventions, setup, and agent context. Existing .rst and Markdown docs are indexed and checked for drift, never overwritten.

Docstring generators: per-symbol API reference, rebuilt when you run the build.
Moxie Docs: architecture, flows, routes, conventions, and setup, re-checked on every merge.
Not covered: rendering a full per-method API reference site. Keep Sphinx or pdoc for that.

At a glance

Python docs tools at a glance

Written from

Sphinx / pdoc

Docstrings

Wiki or README

Whoever last edited it

Moxie Docs

Source, manifests, and tool config

Architecture and flows

Sphinx / pdoc

Hand-written pages

Wiki or README

Hand-written pages

Moxie Docs

Generated and cited to source

Notices stale docs

Sphinx / pdoc

Wiki or README

Moxie Docs

On every merge

Per-symbol API reference

Sphinx / pdoc

Yes

Wiki or README

Moxie Docs

No - summaries, not a reference site

Readable by coding agents

Sphinx / pdoc

As HTML

Wiki or README

Copy and paste

Moxie Docs

Served over MCP

	Sphinx / pdoc	Wiki or README	Moxie Docs
Written from	Docstrings	Whoever last edited it	Source, manifests, and tool config
Architecture and flows	Hand-written pages	Hand-written pages	Generated and cited to source
Notices stale docs	No	No	On every merge
Per-symbol API reference	Yes	No	No - summaries, not a reference site
Readable by coding agents	As HTML	Copy and paste	Served over MCP

FAQ

Frequently asked questions

Get started

Point Moxie Docs at a Python repository

The first index reads your routes, dependencies, and tooling and writes the architecture, conventions, and setup docs. Free on one repo, no card required.

Connect GitHub Everything Moxie Docs generates

Documentation for Python codebases, kept current from the code

What Moxie Docs reads in a Python repo

API routes

Import graph

Dependencies and conventions

Real check commands

Tests recognized

Symbols with context

From a Python repo to current docs

Connect GitHub

First index

Agents read it

Merges keep it true

Where Moxie Docs fits next to Sphinx, MkDocs, and pdoc

Python docs tools at a glance

Written from

Architecture and flows

Notices stale docs

Per-symbol API reference

Readable by coding agents

Frequently asked questions

Does Moxie Docs replace Sphinx or pdoc?+

Which Python frameworks does it detect routes for?+

Which package managers and tools does it understand?+

Does it work with Django and monorepos?+

Will it edit our existing docs?+

Point Moxie Docs at a Python repository