Two well-defined tools with complete input schemas, clear descriptions, and thoughtful parameter design. resource_data and resource_meta both have detailed descriptions (180+ chars) explaining purpose, prerequisites, and usage patterns. Input schemas are properly typed with required fields marked. Parameters include helpful context (e.g., 'Example resourceId 9ef84268-d588-465a-a308-a864a43d0070'). However, output schemas are not documented, LLMs cannot predict response structure. Error handling is implicit (API quirks documented in comments but not surfaced to callers). Tool names follow verb_noun pattern but lack action clarity: 'resource_data' and 'resource_meta' are domain-specific; 'fetch_resource_data' and 'get_resource_schema' would be clearer. No tool annotations (readOnlyHint, idempotentHint) despite both being read-only operations.

• Document output schemas for both tools. Example: resource_data returns {records: [{field_id: string, value: any}...], total: number, status: string}. resource_meta returns {title: string, org: string, sector: string, updated: ISO8601, fields: [{id, name, type}...]}.
• Rename tools to action-verb form: 'fetch_resource_data' and 'get_resource_schema' (or 'describe_resource'). This helps LLMs parse intent from the name alone.
• Add tool annotations: set readOnlyHint=true and idempotentHint=true on both tools to signal they are safe to retry and do not modify state.
• Wrap API error responses in structured error objects. Instead of returning raw {status: 'error', message: '...'}, throw an Error with a clear message: 'Resource not found. Verify resourceId is a valid UUID from data.gov.in.'
• Add pagination note to resource_data description: 'Results are paginated; default limit is 10. Use offset to fetch subsequent pages. The API does not return a total count; if fewer than limit records are returned, you have reached the end.'