Engram provides 23 tools with complete JSON Schema input definitions and descriptions for all tools. Most tool names follow verb_noun convention (remember, neural_search, get_bundle, search_sessions, list_projects, query_concept, rebuild_index, ledger_ingest, ledger_query). Descriptions are present and substantive (average ~130 chars, within the baseline 194-char median). However, there are significant gaps: (1) Parameter descriptions are inconsistent, many lack actionable detail about format, constraints, or when to use them. E.g., 'query' params say 'The search query' or 'Keyword query to search for' but do not specify max length, character restrictions, or examples. (2) Output schemas are NOT documented in the source code, we can see input schemas but have no visibility into response structures, field types, or pagination patterns. This forces LLMs to guess what fields exist in responses. (3) Error handling is not evident, no examples of error messages, recovery guidance, or categorization (retryable vs fatal). (4) Several tools have trivial or generic descriptions: get_stats (13 chars), get_graph_summary (14 chars), session_append_event (25 chars). (5) Parameter naming inconsistencies: some tools use 'query', others use 'pattern' for search-like operations. (6) No indication of which operations are idempotent, destructive, or read-only in the tool descriptions themselves, only inferred from the Risk field in the metadata. (7) Missing output pagination guidance: neural_search, cross_project_search, find_duplicates return multiple results but no documented limit enforcement or next_cursor pattern.

• Document output schemas for all tools. Specify response field names, types, and structure. Example: 'neural_search returns { query: string, total_matches: number, decay_enabled: boolean, results: [{ session_id, relevance_score, summary, project_hint }] }'.
• Expand parameter descriptions with actionable constraints. Replace 'The search query' with 'Semantic search query (max 500 chars; searches across summaries, topics, and learnings; uses time decay by default to prioritize recent sessions)'.
• Add explicit WHEN to use guidance to tool descriptions. E.g., neural_search: 'Use for semantic/meaning-based search across all projects. Choose this over search_sessions when you need fuzzy matching or when keyword search returns no results.'
• Document result limits and pagination. E.g., 'Returns up to 20 results by default. Use the limit parameter to adjust (max 100). If more results exist, the response will indicate total_matches; call again with offset to fetch subsequent pages.'
• Implement and document error responses. Provide structured error objects with code, message, and recovery hint. E.g., '{ error: true, code: EMBEDDINGS_NOT_READY, message: "Embeddings not initialized", nextStep: "Call rebuild_index(embeddings=true) first" }'.
• Add dry-run or confirmation pattern to destructive operations (remember, rebuild_index, ledger_ingest). Document idempotence: are repeated calls safe?
• Standardize search tool naming. Consider renaming to clarify scope: semantic_search (cross-project), project_search (keyword, single project), knowledge_search (ledger), session_search (by ID). Or add disambiguating descriptions.