Summary
docs_project_scan returns a completeness_score that only counts standard documentation files (README, LICENSE, CHANGELOG, etc.). A project with 100% docstring coverage across all 24 Python modules scores 0% (later 25% after adding a README).
This is misleading — the score implies the project is undocumented when it actually has excellent code documentation.
Suggestion
Consider one of:
- Composite score that weights both file-level docs AND inline documentation (docstring coverage)
- Rename the field to
doc_file_completeness to clarify what it measures
- Add a separate field like
inline_doc_coverage alongside completeness_score
Context
From docs-mcp project scan on a new project:
completeness_score: 0% (later 25%)- Actual state: 24/24 Python modules with docstrings, 76/76 public names documented
docs_check_completeness separately reported 100% API documentation coverage
The disconnect between these two tools sends a confusing signal.
Summary
docs_project_scanreturns acompleteness_scorethat only counts standard documentation files (README, LICENSE, CHANGELOG, etc.). A project with 100% docstring coverage across all 24 Python modules scores 0% (later 25% after adding a README).This is misleading — the score implies the project is undocumented when it actually has excellent code documentation.
Suggestion
Consider one of:
doc_file_completenessto clarify what it measuresinline_doc_coveragealongsidecompleteness_scoreContext
From docs-mcp project scan on a new project:
completeness_score: 0% (later 25%)docs_check_completenessseparately reported 100% API documentation coverageThe disconnect between these two tools sends a confusing signal.