The CDC MCP server provides a single unified tool with comprehensive parameter coverage across 73 datasets. The tool definition is well-structured with detailed descriptions and an extensive, properly-typed input schema. However, there are significant gaps in output schema documentation, error handling guidance, and parameter descriptions lack actionable detail. The tool naming follows verb_noun convention ('cdc_health_data' is slightly generic but acceptable for a multi-dataset tool). Parameter descriptions exist but many lack specificity about format, range, or constraints. Output structure is undocumented, LLMs cannot plan downstream calls or extract required fields. Error handling provides no recovery guidance. The schema itself is comprehensive (18 parameters with proper enums and type constraints), placing it above the median community server, but the lack of documented output structure and error guidance prevents a higher score.

• Document the output schema for each method variant. For 'get_places_data', specify: returns array of objects with fields [location_name, year, measure_id, data_value, confidence_interval, population, ...]. For 'search_dataset', specify pagination structure: {results: [...], total_count: N, next_offset: N, returned_count: M}. Include which fields are guaranteed vs optional.
• Add range/format constraints to parameter descriptions. Examples: year: 'ISO 8601 year (e.g., 2024), available datasets span 2011-present. Invalid years return HTTP 404.'; state: '2-letter ISO 3166-1 alpha-2 code (CA, TX, NY). Case-insensitive; accepts full names which are resolved to codes internally.'; limit: 'Default 100, max 50000 per CDC SODA rate limits. Requests exceeding max silently cap to 50000.'
• Add explicit error recovery guidance to the tool description. Example: 'Common errors: (1) Rate limit exceeded (HTTP 429), retry after 1 minute with backoff. (2) Invalid measure_id, call list_datasets or get_available_measures first to discover valid IDs. (3) No data for year, available years are shown in get_available_measures.'
• Formalize conditional parameter documentation. Add a 'Parameter Dependencies' section to the main description: 'where_clause and select_fields are only valid for method=search_dataset. For get_places_data, use geography_level, year, state, measure_id, location. Passing unsupported parameters to a method returns HTTP 400 with clear field validation errors.'
• Consider splitting the unified tool into separate tools by primary method family: 'get_cdc_places_data', 'search_cdc_dataset', 'list_cdc_datasets', 'get_cdc_brfss_data', etc. This would allow LLMs to select tools by name rather than reasoning about method enums, reducing parameter passing errors and improving discoverability. This is a larger refactor but would improve usability significantly.