11 tools with consistent verb-noun naming (get_*, search_*, lookup_*). All have descriptions (10-200 chars, within baseline). Input schemas present with type definitions and parameter descriptions. However, output schemas are undocumented, LLMs cannot infer what fields to expect from responses. Error handling is minimal; tools return plain strings without structured error guidance. No tool annotations (readOnlyHint, etc.). Parameter descriptions are adequate but lack format constraints (e.g., project enum values, decision_number range). Results are capped (20 for search_transcripts, 5-10 for summaries) but limits not always stated in descriptions.

• Document output schemas for all tools. Define the structure of returned data (e.g., get_profile returns {facts: [{category, key, value, confidence}], preferences: [{category, preference}]}). Use JSON Schema or explicit field descriptions so LLMs know what to extract.
• Convert 'project' parameter to an enum in get_project_state, search_transcripts, lookup_fact, search_semantic. Replace free-text description with formal enum: ['jg', 'mb', 'gen', 'js', 'lt', 'jga', 'oth']. This prevents hallucinated project codes.
• Add structured error responses. Return JSON objects with {error: string, code: string, recovery_hint: string} instead of plain text. Classify errors as 'not_found', 'invalid_input', 'service_unavailable' so LLMs know whether to retry, ask the user, or fail.
• Add readOnlyHint: true to all tool schemas. This signals to MCP clients that these tools are safe to retry and do not modify state, enabling more aggressive caching and retry strategies.
• State result limits explicitly in tool descriptions. E.g., 'Returns up to 20 results ranked by relevance' for search_transcripts. Add limit and offset parameters to enable pagination for large result sets.