Analyzes Python docstrings for presence, completeness, freshness, and rendering compatibility to improve AI agent context.
Also known as Alberto-Codes/docvet
- Stars
- 10
- Tools
- —
- Downloads, 30 days
- 14,540
- Latest version
- 3.0.1
- Last commit
- Nov 1, 2026
- License
- MIT
What is docvet MCP?
docvet analyzes Python docstrings for presence, completeness, freshness, and rendering compatibility to improve AI agent context.
Summary generated from the project's README
About docvet MCP server
Python developers and AI coding agents can use docvet to ensure documentation remains accurate and complete. By analyzing docstrings through AST-based structural checks and Git history heuristics, the tool identifies missing sections, rendering issues, and documentation that has become stale due to code changes. It helps maintain high comment density, which is critical for improving the performance of LLMs during code generation tasks.
Users can run the tool via a CLI using commands like docvet check or docvet fix to scaffold missing sections. It integrates into professional workflows through pre-commit hooks, GitHub Actions, and an MCP server for direct AI agent interaction. For advanced rendering diagnostics, the docvet[griffe] extra can be installed to check for compatibility with tools like mkdocs. Configuration is managed through pyproject.toml, allowing teams to set specific failure thresholds for enrichment, freshness, coverage, and griffe checks.
What you can do with it
- 1Identify stale documentationAsk the AI to find docstrings that no longer match the current code signature using git history.
- 2Verify docstring completenessHave the agent check if all function arguments, return types, and exceptions are documented.
- 3Ensure rendering compatibilityCheck if docstrings will render correctly in documentation generators like mkdocs.
Written from the project's README. Every use case is checked against a quote from it.
How to install docvet MCP
Formats verified 10 Nov 2026Add to CursorAdd to GooseInstall docvet MCP in Claude Code
$ claude mcp add docvet -- uvx docvetInstall docvet MCP in Cursor
~/.cursor/mcp.json
{
"mcpServers": {
"docvet": {
"command": "uvx",
"args": [
"docvet"
]
}
}
}Install docvet MCP in VS Code
.vscode/mcp.json
{
"servers": {
"docvet": {
"type": "stdio",
"command": "uvx",
"args": [
"docvet"
]
}
}
}Install docvet MCP in VS Code CLI
$ code --add-mcp '{"name":"docvet","type":"stdio","command":"uvx","args":["docvet"]}'Install docvet MCP in Claude Desktop
claude_desktop_config.json
{
"mcpServers": {
"docvet": {
"command": "uvx",
"args": [
"docvet"
]
}
}
}Install docvet MCP in Codex
$ codex mcp add docvet -- uvx docvetInstall docvet MCP in Codex config.toml
~/.codex/config.toml
[mcp_servers.docvet] command = "uvx" args = ["docvet"]
Install docvet MCP in Gemini CLI
$ gemini mcp add -s user docvet uvx -- docvetInstall docvet MCP in Gemini settings.json
~/.gemini/settings.json
{
"mcpServers": {
"docvet": {
"command": "uvx",
"args": [
"docvet"
]
}
}
}Automated checks
Ran Nov 13, 2026Full report →Passed our automated checks. That is not a security audit: read the code and give the server the narrowest access it needs. How checks work
- Source repository linked and reachablealberto-codes/docvet is public and reachablegithub.com/alberto-codes/docvet ↗Pass
- Package names this repository as its sourcedocvet names alberto-codes/docvet as sourcepypi.org/project/docvet/ ↗Pass
- Build provenance (Sigstore attestation)No build attestation published for this releaseNot checked
- Open source license (OSI)MITspdx.org/licenses/MIT.html ↗Pass
- Commit or release in the last yearLast commit or release 2026-11-01github.com/alberto-codes/docvet ↗Pass
- OpenSSF ScorecardNot checked
- Package name not close to a popular packageNo popular package one edit away from docvetPass
- No critical advisory in the package or its dependencies13 resolved dependencies checked; no critical advisoryosv.dev ↗Pass
- No hidden instructions to the model0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersPass
- Destructive tools are labelledNot checked
- Remote endpoint answers the MCP handshakeNot checked
README
View on GitHubdocvet
Better docstrings, better AI.
Why docvet?
docvet combines docstring presence metrics, structural checks, history-based staleness signals, and renderer diagnostics in one CLI, with editor and agent interfaces. These checks help reviewers find documentation gaps; they do not prove that prose describes runtime behavior correctly.
| Layer | Check | ruff | interrogate | pydoclint | docvet |
|---|---|---|---|---|---|
| 1. Presence | "Does a docstring exist?" | Yes (D rules, opt-in) | Yes, with coverage metrics | Skips absent docstrings | Yes, with coverage metrics |
| 2. Style | "Is it formatted consistently?" | Yes (D rules, opt-in) | -- | Some parsing/style checks | Limited format checks |
| 3. Completeness | "Do sections and code structure agree?" | Partial (D rules; DOC rules in preview) | -- | Arguments, returns, yields, raises, attributes, type hints | AST-based section and agreement checks |
| 4. Accuracy | "What needs review for staleness?" | Structural checks above | -- | Structural checks above | Git diff/blame heuristics; no semantic proof |
| 5. Rendering | "Are there parser warnings?" | -- | -- | -- | Griffe diagnostics |
| 6. Visibility | "Is package discovery incomplete?" | -- | -- | -- | Missing __init__.py checks |
Comparison reviewed 2026-10-21 against primary documentation: Ruff's D103 presence rule and DOC501 exception completeness rule (requires --preview and rule selection), pydoclint's supported checks and styles, and interrogate's coverage documentation. Capabilities depend on enabled rules and configuration; -- means no corresponding check is described in these sources.
pydoclint checks arguments, returns, yields, raises, class attributes, and type hints across Google, NumPy, and Sphinx styles. docvet's enrichment alone has 21 rules, including Raises, Yields, Receives, Warns, Attributes, Examples, cross-references, parameter agreement, and more. Add presence (coverage metrics + threshold enforcement), freshness (git diff/blame staleness signals), griffe rendering compatibility, and mkdocs coverage: 32 rules across 5 checks. Rule totals measure catalog entries, not equivalent coverage between tools.
Structural agreement checks compare documented elements with code structure. Freshness uses change history to suggest review: code can change without invalidating prose, and simultaneous code/docstring edits can still leave incorrect prose. Neither establishes semantic correctness.
Quickstart | GitHub Action | Pre-commit | Configuration | AI Agent Integration | Docs
What It Checks
Presence (existence) -- 2 rules:
missing-docstring overload-has-docstring
Enrichment (completeness) -- 21 rules:
missing-raises missing-returns missing-yields missing-receives missing-warns missing-deprecation missing-param-in-docstring extra-param-in-docstring missing-other-parameters missing-attributes undocumented-init-params missing-typed-attributes missing-examples missing-cross-references extra-raises-in-docstring extra-yields-in-docstring extra-returns-in-docstring missing-return-type trivial-docstring prefer-fenced-code-blocks scaffold-incomplete
Freshness (staleness signals) -- 5 rules:
stale-signature stale-body stale-import stale-drift stale-age
Griffe (rendering) -- 3 rules:
griffe-unknown-param griffe-missing-type griffe-format-warning
Coverage (visibility) -- 1 rule:
missing-init
Quickstart
pip install docvet && docvet check --all
For optional griffe rendering checks:
pip install docvet[griffe]
Example output:
src/mypackage/helpers.py:1: missing-docstring Module has no docstring [required]
src/mypackage/utils.py:42: missing-raises Function 'parse_config' raises ValueError but has no Raises section [required]
src/mypackage/models.py:15: stale-signature Function 'process' signature changed but docstring not updated [required]
src/mypackage/api.py:1: missing-init Package directory missing __init__.py (invisible to mkdocs) [required]
Configuration
Configure via [tool.docvet] in your pyproject.toml. All checks run and print findings. Checks listed in fail-on cause a non-zero exit code; unlisted checks are treated as warnings.
A check in fail-on that cannot run — most often griffe without the docvet[griffe] extra — never certified the gate you configured, so docvet reports it on stderr and exits 1. With --format json the run object reports status: "unavailable" and an unavailable_checks array, which is what distinguishes it from a gate that found problems. Set fail-on-unavailable = false (or pass --no-fail-on-unavailable) to warn and exit 0 instead. Unavailable checks that nothing gates on stay a quiet skip — though fail-on membership is not the only thing that gates: a min-coverage floor gates presence without naming it there.
[tool.docvet]
exclude = ["tests", "scripts"]
fail-on = ["griffe", "coverage"]
[tool.docvet.freshness]
drift-threshold = 30
age-threshold = 90
Pre-commit
Add to your .pre-commit-config.yaml:
repos:
- repo: https://github.com/Alberto-Codes/docvet
rev: v3.0.0
hooks:
- id: docvet
For griffe rendering checks, add the optional dependency:
repos:
- repo: https://github.com/Alberto-Codes/docvet
rev: v3.0.0
hooks:
- id: docvet
additional_dependencies: [griffe]
GitHub Action
Add docvet to your GitHub Actions workflow — findings appear as inline annotations on your PR:
- uses: Alberto-Codes/docvet@v3.0.0
Select specific checks or pin a version:
- uses: Alberto-Codes/docvet@v3.0.0
with:
checks: 'enrichment,freshness'
docvet-version: '3.0.0'
python-version: '3.13'
The griffe rendering check needs no setup: the action installs docvet[griffe], pinned or not, so every check the checks input offers is available. Note that docvet releases before 1.7.0 declare that extra without an upper bound, so pinning one installs whatever griffe publishes at the time rather than a version docvet was released against.
Behavior change — this can turn a passing build red.
Earlier releases installed plain
docvet, so the griffe check was skipped and contributed zero findings. It now runs.determine_run_outcome(src/docvet/reporting.py) returns exit code 1 as soon as any check listed infail-onreports findings, so if yourpyproject.tomlhasgriffein[tool.docvet] fail-on, your build goes from green to failing with no change on your side. This repository's ownci.ymldocvet job is exactly such a consumer.These are not new problems — it is the check finally running on docstrings that were always broken. To get back to green, fix the griffe findings or remove
griffefromfail-on.
AI Agent Integration
For tool-specific integration snippets, see the full AI Agent Integration guide.
Add docvet to your AI coding workflow. Drop this into your CLAUDE.md, .cursorrules, or agent configuration:
## Docstring Quality
After modifying Python functions, classes, or modules, run `docvet check` and fix all findings before committing.
Recommended pyproject.toml configuration:
[tool.docvet]
fail-on = ["enrichment", "freshness", "coverage", "griffe"]
Subcommand Quick Reference
| Command | Description |
|---|---|
docvet check |
Run all enabled checks (default: git diff files) |
docvet check --all |
Run all checks on entire codebase |
docvet check --staged |
Run all checks on staged files only |
docvet presence |
Check for missing docstrings with coverage metrics |
docvet enrichment |
Check for missing docstring sections |
docvet freshness |
Flag potentially stale docstrings via git |
docvet freshness --mode drift |
Review potential staleness via git blame |
docvet coverage |
Find files invisible to mkdocs |
docvet griffe |
Check mkdocs rendering compatibility |
docvet fix |
Scaffold missing docstring sections |
docvet fix --dry-run |
Preview scaffolding changes without writing files |
docvet config |
Show effective configuration with source annotations |
docvet lsp |
Start LSP server for real-time editor diagnostics |
docvet mcp |
Start MCP server for AI agent integration |
Better Docstrings, Better AI
AI coding agents rely on docstrings as context when generating and modifying code. Agents modify code but often leave docstrings stale, and research shows stale or incorrect documentation is actively harmful, worse than no docs at all:
- Incorrect docs degrade LLM task success by 22.6 percentage points
- Comment density improves code generation by 40-54%
- Misleading comments reduce LLM fault localization accuracy to 24.55%
- Performance drops substantially without docstrings
As the 2025 DORA report puts it: "AI doesn't fix a team; it amplifies what's already there." The only signal correlating with AI productivity is code quality.
docvet's freshness heuristics flag potential staleness for review, and its enrichment rules check supported docstring sections against code structure. Run docvet check in your CI, pre-commit hooks, or agent toolchain.
Badge
Add a badge to your project to show your docs are vetted:
[](https://github.com/Alberto-Codes/docvet)
Used By
Are you using docvet? Open a pull request to add your project here.
License
MIT -- see LICENSE for details.
mcp-name: io.github.Alberto-Codes/docvet
docvet MCP questions
How do I add docvet MCP to Claude Code?
Run claude mcp add docvet -- uvx docvet in your terminal. Add --scope user to make it available in every project.
How do I add docvet MCP to Cursor?
Open ~/.cursor/mcp.json and add the server under mcpServers, using the Cursor config shown in the install section above.
What does docvet check for?
It performs checks for docstring presence, enrichment (completeness), freshness (staleness signals via git), rendering compatibility with Griffe, and package visibility.
Can docvet prove that my docstrings are semantically correct?
No, it provides structural and freshness heuristics but does not provide semantic proof that the prose describes runtime behavior correctly.
How can I use docvet with an AI agent?
You can start an MCP server specifically for AI agent integration using the command docvet mcp.