Three tools with complete input schemas and descriptions. Tool names follow verb_noun pattern (bps_list, bps_get_data, bps_view). Descriptions are detailed (150-250 chars) and explain discovery flow. However, output schemas are NOT documented, LLMs cannot predict response structure. Parameters lack enums for constrained values (model, lang, domain). No error handling guidance. API key exposed as parameter (_apiKey) violates secret-injection pattern. Missing parameter validation rules in descriptions (e.g., domain format, page number constraints).

• Document output schemas for all three tools. Example: bps_list returns { status: string, 'data-availability': string, data: Array<{id, name, ...}>, page: number, total: number }. Include field types and meanings.
• Move _apiKey to server-side environment variable injection. Remove from tool parameters. Update tool descriptions to note 'API key configured server-side' instead of requiring user input.
• Add enum constraints: model: enum[subject|subcat|subcsa|var|vervar|turvar|th|data|statictable|pressrelease|publication|news|newscategory|infographic|kbli|kbki], lang: enum[eng|ind].
• Add parameter validation rules to descriptions: 'domain: 4-digit BPS region code (0000=national)', 'page: 1-based integer, default 1', 'var: variable ID from bps_list(model=var)'.
• Implement error classification in responses. Return structured errors: { error: true, code: 'cloudflare_blocked'|'invalid_domain'|'no_data', message: '...', recovery: 'Retry with domain=0000' }. Guide LLM on next steps.