Skip to main content
Glama
Alberto-Codes

docvet

by Alberto-Codes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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.

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

Related MCP server: MCP SDD Server

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

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

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:

[![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

Available Tools

2 tools
docvet_checkA

Run docvet checks on Python files.

Analyzes Python source files for docstring quality issues. Runs all
enabled checks except freshness by default (freshness requires git
context; griffe also excluded when not installed). When *path* is a
directory, only files within that directory tree are checked (not the
entire project). Returns a JSON object with findings, summary
statistics, and optional presence coverage data. Invalid
configuration triggers a structured error response instead of
crashing the server. Input, read, decode, and parse failures report
an incomplete run with unique attempted, analyzed, and failed file counts.
Presence coverage explicitly marks incomplete results, with a null
percentage when no input could be analyzed. Legitimate empty selections
succeed without requiring optional check dependencies or git context.

Args:
    path: Path to a Python file or directory to check.
    checks: Optional list of check names to run. Valid names are
        ``presence``, ``enrichment``, ``freshness``, ``coverage``,
        ``griffe``. Defaults to all except freshness.

Returns:
    JSON string with ``findings``, ``summary``, and optionally
    ``presence_coverage`` keys. Returns an ``error`` key on
    invalid path, unknown check name, or malformed configuration.
    Call docvet_rules() for per-rule fix guidance and format examples.
NameRequiredDescriptionDefault
pathYes
checksNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so: default check set and why freshness is omitted, directory-tree scoping, structured error responses for invalid config, incomplete-run reporting with attempted/analyzed/failed counts, and presence coverage marked incomplete with a null percentage. These are exactly the mutation-free but state-sensitive behaviors an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and default behavior are front-loaded, and the Args section is tight. The Returns block is somewhat long and restates return keys that the output schema already documents, which is mild redundancy rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no annotations and an output schema, the description covers everything an agent needs: scope, defaults, exclusions, parameter meanings, and failure modes. Return value explanation is technically redundant given the output schema but does no harm.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: path is defined as a file or directory with tree-scoping semantics, and checks enumerates all five valid names (presence, enrichment, freshness, coverage, griffe) plus the default. That is more semantic detail than the bare string/array schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Run docvet checks on Python files'), and the second sentence narrows it to docstring quality analysis. The Returns section explicitly routes rule-level fix guidance to the sibling docvet_rules, so the agent can separate the two tools without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states concrete usage conditions: freshness is excluded by default because it needs git context, griffe is skipped when not installed, and a directory path scopes checking to that tree rather than the whole project. It also points to docvet_rules for fix guidance. There is no explicit 'do not use this when' clause, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

docvet_rulesB

List all available docvet rules with fix guidance.

Returns the complete rule catalog with rule name, associated check
module, human-readable description, category (required or
recommended), prescriptive fix guidance, and a format example.

Returns:
    JSON string with a ``rules`` array containing objects with
    ``name``, ``check``, ``description``, ``category``,
    ``guidance``, and ``fix_example`` keys.
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It makes clear this is a static catalog read by describing the returned payload in detail, but it never explicitly states that the call has no side effects, is safe to repeat, or requires no configuration; the return enumeration also largely duplicates the output schema rather than adding behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded and wastes nothing. However, the multi-line 'Returns:' block enumerates keys that the output schema already defines, so a meaningful chunk of the text does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter catalog tool with an output schema present, the description covers purpose and payload adequately and need not explain return values further. The only real gap is the absence of guidance on how this relates to docvet_check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies the call is argument-free by framing it as a full catalog listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('docvet rules') and immediately adds scope ('all available', 'with fix guidance'). An agent can tell this is the rule catalog, but the description never mentions the sibling docvet_check, so differentiation must be inferred from the names alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus docvet_check, no prerequisites, and no exclusions. A reader can guess it is a lookup helper, but nothing in the text routes the agent between the two tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.16.0
    • First observeddocvet_check
    • First observeddocvet_rules
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: docvet_rules is a read-only catalog lookup while docvet_check executes analysis on files. An agent can easily tell which to call for discovery versus execution.

Naming Consistency4/5

Both tools share the docvet_ prefix, giving a predictable namespace and readable names. The slight verb/noun mismatch between docvet_rules (noun) and docvet_check (verb) is a minor deviation but still coherent.

Tool Count3/5

Two tools is on the thin side for the domain; a linter commonly benefits from separate config, fix, or freshness-context tools. It works but feels under-scoped for the apparent feature set (presence, enrichment, coverage, griffe, freshness).

Completeness4/5

Discovery (rules) and execution (check) cover the core linting lifecycle, with rules providing fix guidance. However there is no auto-fix operation despite the emphasis on fix guidance, and freshness/git-context handling is bundled rather than exposed, a minor gap.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-lint-tools

    rog0x
    A
    license
    Not graded
    quality
    D
    maintenance
    Code linting and style checking tools for AI agents, exposed as an MCP server. Supports style checks, naming conventions, complexity analysis, dead code detection, and import analysis.
    20 npm
    MIT

  • QE-MCP

    mov2day
    F
    license
    Not graded
    quality
    D
    maintenance
    A Python-based MCP server that enforces configurable Quality Assurance automation strategies for AI coding agents, ensuring generated tests adhere to strict architectural and testing standards.
    -