MCP server for managing bug reports and resolutions
Two tools with minimal descriptions (10-20 chars each), basic parameter schemas lacking depth, and no output schema documentation. Naming is acceptable (verb_noun pattern), but descriptions are too terse to guide LLM selection. No error handling guidance, no parameter constraints (enums, ranges), and no documentation of return structures. Parameters lack descriptions entirely in the schema definitions visible in main.py. This server falls in the F-D range due to incomplete definitions and missing LLM-critical metadata.
Report a new bug
Resolve a bug by ID
Tool descriptions are critically short (10-20 chars). 'Report a new bug' and 'Resolve a bug by ID' lack context on WHEN to use each tool, what happens on success/failure, and any prerequisites. LLMs cannot reliably select between tools with such minimal guidance.
Input parameters lack descriptions in the schema. The 'title' and 'description' params in report_bug have descriptions in the schema shown, but 'bug_id' in resolve_bug has only 'The ID of the bug to resolve', no guidance on format (UUID? string? numeric?). LLMs cannot infer valid input formats.
No output schema documented. Both tools return unstructured strings ('Bug reported with ID: {bug_id}', 'Bug {bug_id} marked as resolved'). LLMs cannot parse the returned bug_id reliably or plan downstream calls. Should return structured JSON with typed fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
No error handling guidance. resolve_bug returns 'Bug ID not found' as a plain string, not a structured error with recovery hints. LLMs cannot distinguish success from failure or know what to do next (retry? ask user? search for bug?).
No parameter constraints. 'bug_id' accepts any string with no validation. No enums, no format patterns, no length limits. LLMs will pass invalid IDs, causing silent failures or confusing error messages.