19 tools with complete schemas and descriptions, but quality is uneven. Naming follows verb_noun convention well (start_session, record_event, finish_session). Descriptions are present but often generic (50-100 chars, below the 194-char baseline). Parameters have types and descriptions, but lack constraints (enums, ranges, patterns). No output schemas documented. Error handling is minimal, no recovery guidance or categorization. Security concerns: sessions_dir and evidence_dir exposed as parameters across all tools, forcing clients to manage paths. No idempotency hints or confirmation patterns for destructive operations (promote_capability, export_capability, adapt_capability).

• Expand tool descriptions to 150-250 chars. Include WHAT (action), WHEN (use case), and WHAT IT RETURNS. E.g., 'health' → 'Check if a capability is ready for use. Returns status (ready/degraded/failed), last evaluation date, and any warnings. Call this before export_capability to ensure quality.'
• Document output schemas for all tools. Add a 'returns' field to each tool definition showing field names, types, and descriptions. E.g., start_session returns {session_id: string, created_at: ISO8601, project_root: string}.
• Move sessions_dir, evidence_dir, capabilities_dir, eval_dir to server-side configuration (environment variables or config file). Remove from tool parameters. Clients should not manage paths.
• Add parameter constraints: outcome enum [success, failure, partial, cancelled]; skill_style enum [prompt, function, task]; bundle_format enum [json, yaml, zip]; target enum [openai, anthropic, gemini, etc.].
• Add idempotency hints and confirmation patterns to promote_capability, export_capability, adapt_capability, remap_capability. Include error recovery guidance: 'If promotion fails, call inspect_capability to diagnose, then retry.'