The server defines 7 read-only tools with reasonable coverage of WoW API reference data. All tools have descriptions and visible input schemas with Zod definitions. However, definitions lack depth in several areas: parameter descriptions are generic, output schemas are not formally documented in the tool registration, and error handling is minimal. Tool names follow verb_noun convention (lookup, search, list, get) which is good. The codebase shows solid structure with helper formatters (formatFunction, formatFunctionCompact) that produce human-readable output, but the MCP tool definitions themselves do not expose the structured output schema to clients, they return flat text in a 'text' content block. This makes it harder for LLMs to programmatically extract and chain results. All tools are read-only (low risk), but descriptions could be more precise about when to use each variant (e.g., lookup_api vs search_api distinction is somewhat unclear from descriptions alone).

• Define explicit output schemas for all tools. Instead of returning text, return structured JSON objects. Example: lookup_api should return [{fullName, description, params: [{name, type, description, optional}], returns: [{name, type, description}], deprecated, replacedBy, wikiUrl, gameVersions}]. This enables LLMs to extract and chain data.
• Add enum constraints to filter parameters. For list_deprecated, define filter as enum ['namespace', 'name'] or expand description to clarify behavior. For get_namespace and get_widget_methods, clarify that 'list' is a reserved keyword, not a filterable value.
• Expand tool descriptions to explicitly compare overlapping tools. Example: 'Use lookup_api for exact or partial function name matches. Use search_api to find functions by keyword across names and descriptions.'
• Implement recovery guidance in error responses. When a lookup fails, suggest alternatives. Example: 'Function "IsSpellKnown" not found. Did you mean: IsSpellKnownWithSpellID (updated in patch 10.0)? Available namespaces: C_SpellBook, C_Item, C_Spell.'
• Add pagination support to search_api. Accept parameters limit (1-100, default 50) and offset (0+, default 0). Return total_count so LLMs know if more results exist.
• Clarify parameter intent with type suffixes where ambiguous. Example: for get_namespace and get_widget_methods, rename 'name' and 'widget_type' parameters to clearly distinguish them from partial matches or IDs if applicable.
• Document parameter constraints in descriptions. Example: for search_api query parameter, state 'Keywords are case-insensitive. Supports partial matches (e.g., "spell" matches "IsSpellKnown"). Max 100 characters.'