Docvet

io.github.Alberto-CodesPublished by GitHub account Alberto-Codesv3.0.1Updated Oct 29, 2026

Docstring quality vetting for Python -- enrichment, freshness, coverage, and presence checks

VerifiedSTDIODesktop onlyDeveloper ToolsAI & ML

Overview

AI-generated overview

Docvet vets Python docstring quality — presence, completeness, staleness, rendering and coverage — and exposes it to AI agents via an MCP server.

What you can do
  • Run all docstring checks on the whole codebase, on git diff files, or on staged files only
  • Check docstring presence with coverage metrics and flag missing docstrings
  • Check completeness: missing Raises, Returns, Yields, Attributes, Examples and parameter agreement
  • Flag potentially stale docstrings using git diff and blame heuristics
  • Check mkdocs rendering compatibility via Griffe and find files invisible to mkdocs
  • Scaffold missing docstring sections, with a dry-run preview, and show the effective configuration
When to use it
Useful when an assistant edits Python code and should keep docstrings in sync, or when you want docstring quality gated in CI, pre-commit hooks or an agent workflow. It reports structural and history-based signals for review rather than proving that prose is correct.
Requirements
Runs as a local process, installed from PyPI (pip install docvet); the optional Griffe rendering checks need the docvet[griffe] extra. Configuration lives in [tool.docvet] in pyproject.toml. No authentication, environment variables or headers are declared.
Before you install
The fix command writes docstring scaffolding into source files unless run with the dry-run flag. Checks listed in fail-on cause a non-zero exit, and a gated check that cannot run (for example griffe without the extra) also exits 1 unless fail-on-unavailable is disabled, which can turn a passing build red. Findings are heuristics, not proof of correctness.

Installation

In SourceWeft

  1. Open Docvet in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[CI] [Coverage] [PyPI] [Python] [License] [Renovate enabled] [Ruff] [docs vetted]

docvet

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.

LayerCheckruffinterrogatepydoclintdocvet
1. Presence"Does a docstring exist?"Yes (D rules, opt-in)Yes, with coverage metricsSkips absent docstringsYes, with coverage metrics
2. Style"Is it formatted consistently?"Yes (D rules, opt-in)--Some parsing/style checksLimited format checks
3. Completeness"Do sections and code structure agree?"Partial (D rules; DOC rules in preview)--Arguments, returns, yields, raises, attributes, type hintsAST-based section and agreement checks
4. Accuracy"What needs review for staleness?"Structural checks above--Structural checks aboveGit 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

bash
pip install docvet && docvet check --all

For optional griffe rendering checks:

bash
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.

toml
[tool.docvet]exclude = ["tests", "scripts"]fail-on = ["griffe", "coverage"]
[tool.docvet.freshness]drift-threshold = 30age-threshold = 90

Pre-commit

Add to your .pre-commit-config.yaml:

yaml
repos:  - repo: https://github.com/Alberto-Codes/docvet    rev: v3.0.0    hooks:      - id: docvet

For griffe rendering checks, add the optional dependency:

yaml
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:

yaml
- uses: Alberto-Codes/[email protected]

Select specific checks or pin a version:

yaml
- uses: Alberto-Codes/[email protected]  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 in fail-on reports findings, so if your pyproject.toml has griffe in [tool.docvet] fail-on, your build goes from green to failing with no change on your side. This repository's own ci.yml docvet 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 griffe from fail-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:

markdown
## Docstring Quality
After modifying Python functions, classes, or modules, run `docvet check` and fix all findings before committing.

Recommended pyproject.toml configuration:

toml
[tool.docvet]fail-on = ["enrichment", "freshness", "coverage", "griffe"]

Subcommand Quick Reference

CommandDescription
docvet checkRun all enabled checks (default: git diff files)
docvet check --allRun all checks on entire codebase
docvet check --stagedRun all checks on staged files only
docvet presenceCheck for missing docstrings with coverage metrics
docvet enrichmentCheck for missing docstring sections
docvet freshnessFlag potentially stale docstrings via git
docvet freshness --mode driftReview potential staleness via git blame
docvet coverageFind files invisible to mkdocs
docvet griffeCheck mkdocs rendering compatibility
docvet fixScaffold missing docstring sections
docvet fix --dry-runPreview scaffolding changes without writing files
docvet configShow effective configuration with source annotations
docvet lspStart LSP server for real-time editor diagnostics
docvet mcpStart 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:

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:

markdown
[![docs vetted | docvet](https://img.shields.io/badge/docs%20vetted-docvet-purple)](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

Source: README.md at commit dfdd2bd

Tools

0
SourceWeft started this package once in an isolated sandbox, without credentials, to list its tools. That failed: the package did not install.

Version history

4
  1. v3.0.1LatestOct 22, 2026
  2. v3.0.0Oct 21, 2026
  3. v2.0.3Oct 21, 2026
  4. v1.16.0Sep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts