Two tools with complete input schemas and reasonable descriptions. Naming follows verb_noun convention (search_, get_). However, descriptions lack depth on WHEN to use each tool and what distinguishes them. Parameters are documented but lack constraints (enums, ranges). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal. No tool annotations (readOnlyHint, idempotentHint). search_opportunities has 7 optional params with no validation guidance; get_opportunity requires opportunity_id but no guidance on how to obtain it. Descriptions are 150-180 chars (within baseline 194 avg but generic). No mention of pagination limits or result caps.

• Add explicit output schema documentation for both tools. Document normalizeHit() and normalizeDetail() return types with field names, types, and nullability (e.g., 'id: number | null, number: string | null, ...').
• Convert 'status' parameter to enum: ['forecasted', 'posted', 'closed', 'archived'] in inputSchema. Add min/max constraints to 'limit' (1-1000) and 'offset' (>= 0) in schema.
• Add readOnlyHint: true to both tool definitions to signal they are safe to retry and do not modify state.
• Enhance error messages with recovery guidance. E.g., 'Grants.gov API error 400: invalid status. Valid values: forecasted, posted, closed, archived. Retry with corrected status.' instead of generic 'unknown error'.
• Document pagination behavior in search_opportunities description. State: 'Returns up to 'limit' results (default 25, max 1000). Use 'offset' to paginate. Total count returned in 'total' field.' Add next_offset to response if more results exist.