Client SDK to auto-generate markdown documentation by parsing python codebase source scripts.
This MCP server has a single tool 'write_documentation' with severe quality gaps. The tool has a name that follows verb_noun convention (positive), but the description is superficial (only 82 characters, below the 10-1024 baseline), the input schema is missing critical context and constraints, and there is no documented output schema. The source code shows a naive regex-based parser with no error handling, validation, or recovery guidance. The implementation lacks any of the 54 production patterns and does not align with MCP best practices.
Parses functions/classes and docstrings, returning formatted markdown output.
Output schema completely undocumented. No structured response definition provided. LLMs cannot plan downstream operations or extract structured data from markdown output.
Input parameter 'source_code' lacks validation constraints, format hints, size limits, or encoding specification. LLMs will pass arbitrary untrusted input without guidance on what constitutes valid Python.
Tool description is only 82 characters and generic. It does not explain WHEN to use this tool, what it returns, what happens with invalid input, or expected prerequisites (e.g., does source_code need to be complete/syntactically valid Python?).
No error handling or recovery guidance. Source code with syntax errors, unparseable constructs, or edge cases (e.g., decorators, type hints, async methods) will silently fail or produce incorrect markdown. LLM has no error classification or next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
Implementation uses naive regex-based parsing (r'class (\w+)', r'def (\w+)') which will fail on: nested classes, docstrings with 'def' in them, string literals with 'class', decorators, type annotations with complex signatures, f-strings, comments. No validation or fallback.
No parameter description provided in the schema. The 'source_code' parameter has a description in the tool description text but not in the JSON Schema input definition. This violates the 100% A+ baseline for parameter descriptions.