Server has 5 tools with basic verb-noun naming (get_*, identify_*). All tools have descriptions (10-200 chars, within baseline range). However, input schemas are present but lack critical detail: parameter types are declared but descriptions are minimal or generic. Output schemas are not documented anywhere in the source. Error handling is absent, no recovery guidance, no categorization, no actionable error messages. Tool composition is reasonable (each does one thing), but the lack of schema documentation and error patterns significantly limits LLM usability. STDIO transport caps protocol readiness at 50, further limiting production viability.

• Document output schemas for all 5 tools. Example: get_borough_mortgage_stats should return {borough: string, year: int, originated_count: int, denied_count: int, denial_rate: float, race_filter: string|null}. This enables LLMs to chain calls and extract fields.
• Convert 'race' parameter to an enum with exact valid values: ['Asian', 'Black', 'Hispanic', 'White', 'Native American', 'Pacific Islander']. Remove free-form string acceptance to prevent hallucinated values.
• Add range constraints to 'year' parameter in all tools: 'year (integer, 2018-2022, default 2022)'. Currently only one tool mentions the range in description.
• Implement error handling with recovery guidance. Example: 'If HMDA API returns no data for a borough, try identify_borough_from_location() to verify the borough name is valid.' Categorize errors as retryable (timeout) vs user-fixable (invalid borough).
• Enhance tool descriptions with WHEN-to-use context. Example for get_all_nyc_boroughs_data: 'Use this to compare denial rates across all 5 boroughs in one call. Use get_borough_mortgage_stats() for detailed stats on a single borough or neighborhood.'