ctx exposes 9 tools with explicit schemas and descriptions in internal/mcpserver/tools.go. All tools have names starting with 'ctx_' (verb-noun pattern present but unconventional prefix). Descriptions are present (avg ~80 chars) but generic and lack actionable context for LLM selection. Input schemas are properly typed JSON Schema objects with required fields declared. However, parameter descriptions are minimal (1-2 sentences), lack format/constraint details, and do not explain when to use each tool vs. alternatives. Output schemas are completely undocumented, no response structure guidance for downstream tool chaining. Error handling is present (errorReporting=true) but not visible in tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Tool composition is reasonable (each does one thing), but descriptions do not guide multi-step workflows (e.g., 'search first, then install').

• Add output schema documentation for all 9 tools. Example: ctx_search should document 'Returns array of {name, type, version, description, platform} objects with total count and next_offset for pagination.'
• Add tool annotations to schema: ctx_remove and ctx_update need destructiveHint=true; ctx_search, ctx_list, ctx_info, ctx_outdated, ctx_doctor, ctx_agents need readOnlyHint=true; ctx_install needs idempotentHint=true if safe to retry.
• Enhance parameter descriptions with constraints: 'limit: integer, 1 - 100 (default 20)'; 'package: string matching @scope/name or @scope/name@version (e.g., @ctx/skill@^1.0)'.
• Clarify tool selection in descriptions. E.g., ctx_search: 'Use to discover packages by keyword. For detailed info on a known package, use ctx_info instead.' ctx_update: 'Updates installed packages. To install new packages, use ctx_install.'
• Document error scenarios and recovery paths. E.g., ctx_install: 'If package not found, try ctx_search to verify the name. If permission denied, check auth via ctx_doctor.'