jarvis-kb has 6 tools with basic schemas and descriptions, but significant gaps prevent production use. All tools have descriptions (10-100 chars, mostly adequate), and input schemas are present with type definitions. However, parameter descriptions are sparse or missing entirely (e.g., kb_compile has no parameter descriptions at all). Output schemas are completely undocumented, LLMs cannot plan downstream calls or extract structured data. Error handling is absent; no guidance on retryability, recovery, or actionable next steps. Tool naming is verb-noun compliant (kb_search, kb_ask, kb_ingest, kb_remember, kb_compile, kb_audit), but compositions lack chaining IDs, e.g., kb_search returns results but no IDs to feed into kb_ask or kb_ingest. No security annotations, no permission gates, no audit trail. The server is STDIO-only, which is a hard cap at 50 for protocol readiness.

• Document output schemas for all 6 tools. Example for kb_search: 'Returns {results: [{id, title, source, snippet, score}], total_count, next_cursor}'. This enables LLMs to extract IDs and plan downstream calls.
• Add parameter descriptions to kb_compile (vault: 'Synto or Synthadoc vault to compile'; auto_approve: 'If true, skip manual review step, use with caution') and kb_audit (scope: 'self=current vault, world=all external sources, all=both').
• Implement error handling with recovery guidance. Example: 'If kb_search returns no results, try: (1) broaden query, (2) call kb_audit to check vault health, (3) call kb_ingest to add missing documents.'
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to distinguish safe reads (kb_search, kb_ask, kb_audit) from writes (kb_ingest, kb_remember, kb_compile). Mark kb_compile with destructiveHint if auto_approve=true.
• Implement confirmation pattern for destructive operations. kb_compile with auto_approve=true should require a separate confirm_compile tool or return 'input_required' asking the user to approve before proceeding.