nautilus-compass defines 17 tools with schemas and descriptions present, but quality is inconsistent. Most tool descriptions are adequate (50-150 chars), but parameter descriptions are sparse or missing context. Schemas are present but lack depth: many parameters lack type constraints (e.g., 'parameters' object in long_task, submit_platform_task are untyped). No output schemas documented. Error handling is absent, tools do not guide recovery or categorize failures. Naming is verb-forward (recall, drift_check, ingest_obs) but some names are vague (long_task, submit_platform_task). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. STDIO transport caps protocol readiness at 50.

• Add explicit output schemas for all tools. Document returned fields, types, and which fields enable chaining (e.g., recall should return memory_id, snippet, score, thread_id for downstream thread_recall calls).
• Replace untyped 'parameters' object in long_task and submit_platform_task with explicit typed fields. E.g., long_task: task_type (enum: reindex|rerank|anchor_retrain), reindex_depth (integer, 1-10), rerank_model (string). Enumerate valid task_type values in description.
• Add tool annotations to schema: readOnlyHint=true for recall, drift_check, profile, governance_audit; destructiveHint=true for governance_dispatch; idempotentHint=true for ingest_obs (if write-time-zero design guarantees idempotency).
• Rename generic tools: profile → get_user_profile; long_task → submit_async_task; submit_platform_task → enqueue_platform_task. Add 1-2 sentence descriptions explaining when to use each vs similar tools.
• Add error handling guidance to tool descriptions. E.g., recall: 'Returns empty list if no matches found (not an error). If project not found, returns 404 with available projects.' governance_dispatch: 'Purge is irreversible. Confirm with user before calling.'