This MCP server exposes 3 tools for browsing React hooks from @reactuses/core. All tools have proper names starting with action verbs (get_, list_, search_), clear descriptions (100-150 chars), and well-defined input schemas with typed parameters. However, output schemas are not documented in the source, parameter descriptions lack specificity around constraints and formats, and no error handling guidance is visible. The server follows a clean verb-noun naming convention and provides enum constraints for category filtering, but falls short of production-grade documentation expected for A-tier tools.

• Document output schemas for all tools. Specify: get_hook returns {hook_name, description, usage_example, api_table, category}; list_hooks returns {hooks: [{name, description, category}], total}; search_hooks returns {results: [{name, description, relevance_score}], total}.
• Expand parameter descriptions with constraint details. For hook_name: 'Hook name (case-insensitive). If not found, returns an error with similar hook names. Example: "useToggle" or "usetoggle".' For query: 'Searches hook names, descriptions, and source code. Returns matches ranked by relevance.'
• Add error handling guidance. E.g. get_hook: 'If hook not found, call list_hooks() to discover available hooks by category.' search_hooks: 'If no results, try broader queries or list_hooks() to browse by category.'
• Clarify search_hooks limit default. Update description: 'Maximum number of results returned (default 20, max 50). Limit is capped to prevent context overflow.'
• Consider adding per-tool examples in descriptions. E.g. 'Example: call get_hook('useToggle') to fetch docs, then ask the user how to integrate it.' This helps LLMs understand intent.
• If tools are read-only, add explicit annotations (readOnlyHint) so agents know they are safe to call speculatively without confirmation.

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry