Skip to main content
Glama

docvet_check

Analyze Python files or directories for docstring quality issues and return findings, summary stats, and presence coverage from selected checks.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
pathYes
checksNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.16.0

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.

Deploy Server

Other Tools