The Data Commons MCP server presents well-structured tool definitions with clear naming conventions (all tools start with action verbs: search_, get_) and comprehensive parameter descriptions. All 6 tools have documented input schemas with typed parameters. However, there are critical gaps in output schema documentation, which prevents LLMs from understanding what fields to expect in responses. Tool descriptions are adequate but somewhat generic, lacking context about when to use each tool versus alternatives. The server handles read-only operations exclusively (all marked READ_ONLY), which simplifies error handling but limits utility. Parameter descriptions are generally good (e.g., 'DCID of the statistical variable') but lack format constraints, enums, or validation guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the visible code, though the risk designation mitigates this partially.

• Document the output schema for each tool. For search_* tools, specify returned fields (e.g., dcid, name, description, topic) with types. For get_* tools, specify the structure of observations (e.g., date, value, source) and metadata. This enables LLMs to extract the right fields and plan downstream calls.
• Add enums or pattern constraints to date parameters. E.g., date: one of 'latest' (string) or YYYY-MM-DD format (string), mutually exclusive with date_range_start/date_range_end. Document this in parameter descriptions.
• Clarify the distinction between search_indicators and search_child_indicators in their descriptions. When should an agent choose one over the other? What does 'child-place level' mean to a non-expert?
• Document pagination behavior and result limits. If search_indicators returns at most 10 results by default, state that. If there are more results, document how to request the next page (per_search_limit param suggests client-side control; clarify if total results count is returned).
• Add a brief dependency hint to get_child_observations and get_multi_entity_observations. E.g., 'To discover available variables, call search_indicators first. To discover available places, consult the Data Commons API documentation.'
• For get_multi_entity_observations, the 'entities' parameter is documented as 'Dictionary mapping entity properties to lists of DCIDs' but lacks concrete examples or constraint details. Clarify with an example: entities: {StaffType: ['Faculty', 'Staff'], EducationLevel: ['High_School', 'Bachelor']}.