openeruka provides 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (get_*, write_*, search_). However, descriptions are verbose and technical (200-400+ chars), mixing API details with functional intent. Parameter descriptions are present but inconsistent in clarity. Output schemas are not documented. Error handling is mentioned in descriptions but not formalized. The write_context tool lacks clear guidance on knowledge state invariants and conflict resolution. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification.

• Document output schemas for all tools. For get_context, specify: returns {path: string, value: object, knowledge_state: string, confidence?: number, source?: string, updated_at: string}. For get_entities, specify: returns {entities: [{id: string, type: string, properties: object}], total: number}.
• Refactor descriptions to 50-200 chars, separating API details into implementation notes. E.g., get_context: 'Retrieve a context field by path or scan all fields matching a prefix. Returns the field value, knowledge state, and metadata.' Move 'BUG-1 fix' to release notes, not the tool description.
• Add error recovery guidance to write_context: 'If knowledge state conflict occurs, the field was not updated. Retry with a higher knowledge state (confirmed > inferred > uncertain > unknown) or ask the user to confirm the value.'
• Add tool annotations to the MCP tool registration: write_context with destructiveHint=true; all read tools with readOnlyHint=true. This signals to LLMs which tools have side effects.
• Declare knowledge_state and source as enums in the schema: knowledge_state: {type: 'string', enum: ['confirmed', 'inferred', 'uncertain', 'unknown']}; source: {type: 'string', enum: ['user_input', 'document_extraction', 'web_search', 'agent_inference']}. Update parameter descriptions to reference the enum.