cost-explorer tool description conflates 9 distinct operations (getCostAndUsage, getCostAndUsageWithResources, getDimensionValues, getCostForecast, getUsageForecast, getTagsOrValues, getCostCategories, getSavingsPlansUtilization) into a single tool with an 'operation' parameter. This violates the single-responsibility pattern and forces LLMs to choose between wildly different behaviors within one tool definition.
aws-pricing tool requires strict operational sequencing (get_service_codes → get_service_attributes → get_attribute_values → get_pricing_from_api) but the tool signature accepts any operation in any order. No validation prevents misuse. LLMs may skip required steps or call operations out of order, leading to confusing errors like 'invalid service code' when the service code was never discovered.
cost-explorer 'operation' parameter lacks an enum constraint. The description lists valid values (getCostAndUsage, getCostAndUsageWithResources, etc.) but the parameter type is 'string' with no enum. LLMs may hallucinate invalid operation names like 'getHistoricalCost' or 'analyzeCost'.
aws-pricing 'filters' parameter is type 'string' requiring JSON format manually. The description says 'Format: {"instanceType": "t3.medium", ...}' but does not enforce it. LLMs frequently mis-format JSON strings, leading to parse errors. Should be type 'object' with explicit subproperties.
cost-explorer parameter 'filter' (for getCostAndUsageWithResources and getCostForecast) is type 'string' requiring JSON format, with example Filter syntax shown in description but no schema validation. Parameter descriptions reference 'Dimensions' and 'And/Or' operators that only some operations support, creating silent misuse.
cost-anomaly 'total_impact_operator' parameter is type 'string' with valid values listed in description (EQUAL, GREATER_THAN, etc.) but no enum constraint. Same risk as cost-explorer operation parameter.
No error handling guidance visible in any tool description. What happens when: service_code is invalid? Filters are malformed? Date range is outside 90 days (for cost-anomaly)? Budget name does not exist? Descriptions do not say 'if X fails, try Y' or classify errors as retryable vs user-fixable. LLMs cannot recover from failures.
aws-pricing tool description includes prescriptive steps ('USE THE OPERATIONS IN THIS ORDER') but the tool signature does not enforce it. No validation layer prevents out-of-order calls. The tool accepts any operation in any order, so the sequential requirement exists only in documentation, not in code.
cost-explorer description is 3,200+ characters, exceeding the 1,024-char baseline by 3x. The description tries to document 9 operations, dimension reference, and usage guidelines in a single block. This exceeds cognitive load for LLM parsing and wastes tokens. Should split into separate tools or condense drastically.
cost-explorer parameter 'granularity' lacks type constraint. Description says 'DAILY, MONTHLY, etc.' but does not define 'etc.' or enforce enum. Same for 'metric' (which has case-sensitivity rules: UNBLENDED_COST vs UnblendedCost depending on operation).
cost-explorer returns complex nested structures (cost data grouped by dimensions, forecasts with confidence intervals, etc.) but does not formally document the output schema. LLMs must infer structure from description text, risking misunderstanding.
cost-explorer
Recommendations
Split cost-explorer into 9 separate tools: get_cost_and_usage, get_cost_and_usage_with_resources, get_cost_forecast, get_usage_forecast, get_dimension_values, get_tag_values, get_cost_categories, get_savings_plans_utilization. Each tool should have its own description, required/optional parameters, and output schema. This follows the single-responsibility pattern and eliminates the operation parameter ambiguity.
Split aws-pricing into 4 separate tools mirroring the operational sequence: list_aws_services (discover service codes), get_service_pricing_dimensions (get attributes for a service), get_dimension_values (enumerate valid values), get_service_pricing (the final pricing lookup). Enforce sequential dependency through tool naming and descriptions.
Convert string-based JSON parameters (aws-pricing 'filters', cost-explorer 'filter', 'group_by', 'metrics') to proper JSON Schema objects with typed subproperties. For aws-pricing, define 'filters' as type 'object' with properties like instanceType, location, etc., each with type 'string'. For cost-explorer, define 'filter' as a discriminated union supporting Dimensions, And, Or operators.
Add error handling guidance to each tool description. For aws-pricing: 'If service_code is invalid, call list_aws_services first to discover valid codes.' For cost-anomaly: 'If no anomalies are found and the date range is >90 days old, please narrow the date range; anomalies are retained for up to 90 days.' For cost-explorer: 'If filter syntax is rejected, check that dimension names match the DIMENSION REFERENCE section.'
Reduce cost-explorer description from 3,200 chars to <500 chars by removing operation-by-operation documentation. Move operation details into a separate 'Operations Reference' document and link it. Core description should answer: What does it do? (retrieves AWS cost/usage data) When to use it? (for cost analysis, forecasting, resource tracking) What permissions needed? (ce:GetCostAndUsage, etc.)
Formally document output schemas for all tools. For aws-pricing 'get_pricing_from_api': 'Returns Dict with keys: ServiceCode (str), PriceListUrl (str), PriceListVersion (str), NextToken (optional str).' For budgets: 'Returns Dict with keys: Budgets (List of {BudgetName, BudgetType, Limit, CurrentSpend, ForecastedSpend}), NextToken (optional).' For cost-explorer: Document each operation's return type separately.
Add parameter dependency documentation. For cost-explorer getCostAndUsageWithResources: 'RESOURCE_ID is required, include it in either filter OR group_by. If using filter, format as {"Dimensions": {"Key": "RESOURCE_ID", "Values": ["arn:aws:..."]}}'.
For aws-pricing, add validation hints: 'region parameter must be one of: us-east-1, eu-central-1, ap-southeast-1 (classic partition) or cn-northwest-1 (China partition). Your region will be mapped to the nearest pricing endpoint.' For cost-anomaly: 'start_date and end_date must be within the last 90 days. Anomalies older than 90 days are not available.'
Add batch operation hints. For cost-explorer, note: 'To retrieve costs for multiple services, include multiple values in the filter, e.g., {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon EC2", "Amazon RDS", "Amazon S3"]}}, rather than calling the tool three times.'
Include chaining hints for common workflows. For budgets: 'The BudgetName returned here can be passed to cost-anomaly if you want to monitor anomalies for a specific budget.' For cost-explorer: 'Use getDimensionValues to enumerate available service names before filtering by SERVICE dimension.'
Document rate limits and result caps. For cost-explorer: 'GetCostAndUsage is limited to 100 pages of results. Use pagination (NextToken) to retrieve additional pages. Each page typically contains 100-1000 line items depending on your query complexity.' For cost-anomaly: 'Results are limited to 50 anomalies per call; use max_results to paginate if more exist.'