A Retrieval-Augmented Generation (RAG) MCP server for querying the latest Godot engine documentation and references using ChromaDB vector similarity search.
Single tool with significant quality gaps. The tool 'get_godot_context' has a verbose description (250+ chars, well above the 10-1024 guideline sweet spot of 50-200), lacks output schema documentation, has minimal parameter description, and exhibits error handling that returns inconsistent types (list vs dict). The input schema is visible and properly typed, but parameter description is minimal. No pagination support documented despite the tool returning up to 20 results. The tool is directly visible in code (FastMCP decorator registration), so no inference penalty applies, but the overall execution quality is poor.
Godot engine has evolved a lot, and a lot of the pretrained knowledge is outdated and cannot be relied on. This tool retrieves a list of the latest relevant Godot documentation snippets based on the provided query. If user askes anything related to the Godot engine, including api and class references, even you are confident, this function should still be called. If there is any conflict between your knowledge and the retrieved snippets, the snippets should be considered more reliable, otherwise it's okay to rely on your knowledge. Only call this function if you are certain it's about the Godot engine.
Output schema not documented. Tool returns a list but LLMs need to know the structure of items within that list (e.g., are they strings, objects with metadata, etc.). Without documented output schema, agents cannot reliably extract fields for downstream operations.
Inconsistent error handling. On success, returns list[str]; on failure, returns dict with 'error' key. This type inconsistency forces LLMs to handle two different response shapes and makes error recovery unclear. Should always return a structured error with retry guidance or raise an exception.
Parameter description is minimal (15 chars: 'keywords related to Godot engine'). Violates baseline that 100% of A+ tools have descriptions 50+ chars with format/constraint guidance. LLM lacks guidance on query length, format, or multi-word phrasing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Tool description exceeds 250 characters (well above sweet spot of 50-200). Contains redundant explanation about Godot evolution and conflict resolution that could be condensed. Wastes LLM tokens and buries key action (retrieve documentation snippets).
No pagination support documented. Tool hardcodes n_results=20 but does not expose limit/offset parameters or document the pagination behavior. If result set grows, LLMs cannot request more results or page through them, violating paginated-result pattern.
No relevance scoring or metadata returned. ChromaDB query returns results but strips distance scores and metadata. LLMs cannot assess confidence in results or explain why a snippet was selected, reducing transparency and trust.