This AWS Cost Explorer MCP server has well-structured tool definitions with clear names and comprehensive parameter descriptions. All 6 tools follow verb_noun naming conventions (get_*, all action-oriented). Input schemas are visible and properly typed with descriptions for parameters. However, there are significant gaps: output schemas are NOT documented anywhere in the visible code, error handling guidance is absent, and there is no explicit tool registration visible in the provided source. The server appears to be a wrapper around an official MCP server (`uvx awslabs.cost-explorer-mcp-server@latest`), and tool definitions are inferred from comments/docstrings rather than explicitly registered. Parameter descriptions are generally solid (60-80 chars average), but lack guidance on dependencies between parameters (e.g., metric format differs between get_cost_and_usage and get_cost_forecast, requiring underscore notation). No error recovery guidance is documented.

• Document output schemas for all 6 tools. For get_cost_and_usage, specify: returns {ResultsByTime: [{TimePeriod, Total, Groups?, Estimated}], ...}. For get_cost_forecast, specify: returns {ForecastResultsByTime: [{TimePeriod, Total, MeanValue}], ...}. Include field types and meanings so LLMs can extract and chain data.
• Add error handling guidance to each tool description. Example: 'Returns error if date range is invalid (start > end), ensure dates are in YYYY-MM-DD format and start_date <= end_date. Returns error if metric is invalid, must match the metric enum. LLM should validate before calling and suggest specific metric from the enum if invalid.'
• Standardize metric naming. Either use CamelCase for ALL (NetAmortizedCost) or UPPERCASE_UNDERSCORE for ALL (NET_AMORTIZED_COST). Currently the inconsistency between get_cost_and_usage and get_cost_forecast creates cognitive load for LLMs. Choose one and document it in the tool descriptions.
• Add pagination and result-limit guidance. For get_dimension_values and get_tag_values, add: 'Results are paginated at 100 items per request. To fetch all values, check the NextToken field; if present, call again with the NextToken parameter. Typical dimensions return 10-50 values (services, regions) but tags can be numerous.'
• Clarify filter_expression and group_by usage with examples. E.g., 'filter_expression with Dimensions key: {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Elastic Compute Cloud"], "MatchOptions": ["EQUALS"]}} filters to EC2 costs only. Use Tags key for tag-based filtering. group_by as string ("SERVICE") groups results by service; as object {"Type": "TAG", "Key": "env"} groups by tag value.'