GxGenie MCP demonstrates solid schema completeness with 9 well-defined tools covering GeneXus KB operations. All tools have descriptions (avg 120 chars) and explicit JSON schemas with type constraints and enums. Naming follows verb_noun pattern (gx_list_objects, gx_create_transaction). However, output schemas are entirely undocumented, the code explicitly omits outputSchema. Error handling lacks recovery guidance and categorization. Parameter descriptions are present but often generic (e.g., 'Diccionario de cambios' for updates object). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing idempotency guidance for write operations.

• Document output schemas for all 9 tools. Specify response structure (e.g., gx_list_objects returns {objects: [{name, type, module}], total_count, has_more}). This enables LLMs to chain tools and extract required fields.
• Add tool annotations: mark gx_delete_object with destructiveHint=true, gx_create_transaction/gx_update_object_code/gx_build_object with idempotentHint=false (or true if they are), gx_kb_info/gx_list_objects/gx_read_object/gx_export_xpz with readOnlyHint=true.
• Enhance error handling with recovery guidance. E.g., gx_read_object: 'Object not found. Try gx_list_objects(type=<expected_type>) to verify it exists.' Categorize errors as retryable (network timeout) vs user-fixable (invalid name).
• Clarify 'updates' parameter in gx_update_object_code. Document valid Part names (Events, Rules, Procedure, Structure, Variables, etc.) and expected code format. Add example: {"Events": "Event 'Start'\n // code here\nEndEvent"}.
• Add idempotency notes to write tools. E.g., gx_create_transaction: 'If a transaction with this name already exists, returns error (not idempotent). Use gx_read_object to check first.' This guides agent retry logic.