Two well-defined tools with clear schemas, good parameter descriptions, and proper type constraints. Both tools have comprehensive docstrings and proper annotation hints. The server follows the single-responsibility principle effectively, splitting search and fetch operations. Tool naming is verb-first and action-oriented. Schemas include proper enums, bounds constraints, and optional/required field distinctions. Main gaps: output schemas are documented only in descriptions (not in JSON Schema format); no error handling patterns documented; no recovery guidance for common failure modes.

• Add formal JSON Schema output definitions to both tools. Example: For grants_gov_search_opportunities, document structure like {"opportunities": [{"id": int, "title": string, "agency": string, "status": string}], "total_count": int, "next_page": int}
• Document error handling in tool descriptions. Example: 'Returns 404 if opportunity not found. Returns 429 if rate limited, retry after 60s. Returns 400 if search terms exceed 500 chars, shorten keyword and retry.'
• Add a dependency hint to fetch_opportunity: 'Use grants_gov_search_opportunities first to find opportunity IDs. The search returns opportunity_id values compatible with this tool's opportunity_id parameter.'
• Clarify markdown vs JSON format choice: 'Use markdown for human-readable summaries in chat; use json for programmatic downstream processing or when results will be chained to other tools.'
• Explicitly cap and document result limits. Update description: 'Returns up to 25 opportunities per page (configurable via rows parameter, max 100). Use start_record for pagination. For large result sets, iterate through pages.'
• Add examples of valid filter combinations. E.g., 'Search by agency: {"agencies": ["NSF"]}, or by status: {"opp_statuses": ["posted"]}, or by ALN: {"aln": "93.268"}. Combine filters to narrow results.'
• Document what happens when no results match. Does it return empty array, null, or error? Update description accordingly.