Server provides 7 tools with clear verb-noun naming (list_tools, detect_tool, add_custom_tool, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, responses are inferred from implementation rather than explicitly declared. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool descriptions lack WHEN/WHY context and prerequisites. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications (READ_ONLY vs WRITE). Parameter descriptions are adequate but lack format constraints, ranges, or validation rules.

• Add explicit output schema documentation for each tool. E.g., list_tools should declare: returns array of {key: string, displayName: string, detected: boolean, skillsDir: string, isCustom: boolean}.
• Implement tool annotations: mark add_custom_tool, remove_custom_tool, set_default_tool, clear_default_tool with destructiveHint=true; mark list_tools, detect_tool, get_default_tool with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., detect_tool should return: 'Unknown tool: {key}. Available tools: [list]. Call list_tools() to see all options.'
• Add parameter constraints to descriptions. E.g., 'key' parameter: 'Tool key identifier (2-50 alphanumeric chars, lowercase, hyphens allowed). Must match a registered tool or 'all'.'
• Expand tool descriptions with WHEN/WHY context. E.g., set_default_tool: 'Persist the default tool in config so subsequent calls without --tool use it. Use this to avoid repeating --tool flags in scripts. Pass key="all" to default to cross-tool discovery.'