Single tool 'search_schemes' has a clear verb-noun name and acceptable description (89 chars). Input schema is present with two parameters, both typed (string, float) and described. However, the output schema is completely undocumented, the tool returns a JSON string containing scheme objects, but no schema is declared for the response structure. Parameter descriptions are minimal (under 72 chars baseline) and lack format/constraint details. No error handling guidance, no recovery paths, and no documentation of what happens when no schemes match. The tool is READ_ONLY (good security posture) but lacks idempotent/readonly annotations. Overall, this is a bare-minimum tool definition that would not pass production code review.

• Add explicit output schema: {type: 'object', properties: {results: {type: 'array', items: {type: 'object', properties: {id, name, min_land_acres, max_land_acres, allowed_crops, description}}}}}. Document in tool description.
• Replace free-form crop_type description with enum constraint: allowed_crops from DB (Paddy, Ragi, Jowar, Maize, Pulses, All) or add validation that returns 'Invalid crop_type: got "X", valid options: Paddy, Ragi, Jowar, Maize, Pulses, All'.
• Add land_size_acres range to description: 'Float acres, typically 0.1 - 10.0 based on Karnataka scheme eligibility. Values outside this range may return no matches.'
• Add error handling: 'If no schemes match, returns {results: []} with explanation. If crop_type is invalid, returns error with valid options. If land_size_acres is negative, returns validation error.'
• Add tool annotations to FastMCP decorator: @mcp.tool(readOnlyHint=True, idempotentHint=True) to signal safety properties to clients.