Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This is an HTTP proxy/wrapper server that translates between HTTP endpoints and upstream MCP tool calls. Tool definitions are visible with schemas and descriptions, but quality is inconsistent. All 5 tools have descriptions and input schemas, but descriptions are generic and lack actionable context. Parameter descriptions are minimal (often single phrases). No output schemas are documented. Error handling is basic (ValueError returns 400, generic 500). The naming follows verb_object patterns (aws___ prefix is unconventional but consistent). Input validation exists but is permissive, notably in get_regional_availability which accepts arbitrary keys and passes them through to upstream, creating security/complexity issues. No tool annotations (readOnlyHint, etc.) despite all tools being read-only. The architecture is a thin HTTP wrapper around an undocumented upstream MCP endpoint, which limits what we can assess about actual tool quality, we're evaluating the proxy layer, not the true tool definitions.
Tool descriptions lack context and LLM selection guidance. Descriptions are 18 - 59 chars, below the 50 - 200 char baseline for LLM-optimized descriptions. Example: 'Get regional availability information for AWS services' does not explain WHEN to call this tool vs similar lookup tools, what it returns, or what prerequisites exist.
No parameter descriptions in aws___list_regions. The tool accepts zero required parameters but this is not explicitly documented. LLMs may attempt to pass parameters that are silently ignored.
aws___get_regional_availability accepts 7 optional parameters (service, region, feature, sku, instance_type, family, platform) but validation logic is permissive, it accepts 'any' additional keys, lists up to 20 items, and objects are rejected only post-hoc. Lack of enum constraints for known AWS values (service names, region codes) invites hallucinated inputs. Schema shows no enums despite AWS having fixed sets (e.g. service ∈ {EC2, Lambda, S3, ...}, region ∈ {us-east-1, eu-west-1, ...}).
Recommendations
Expand tool descriptions to 50 - 200 characters. For example: 'Get regional availability information for AWS services. Specify a service name (e.g., EC2, Lambda) and optionally a region code (e.g., us-east-1) to retrieve availability matrices, pricing, or SKU details. Use this to verify which services/features are available in a region before recommending architecture.'
Add descriptions to all parameters. For aws___list_regions, explicitly state: 'This tool takes no parameters and returns a list of all AWS regions with their region codes, display names, and opt-in status.' For aws___get_regional_availability, describe each parameter: service: 'AWS service name (e.g., EC2, Lambda, S3), required if querying service availability', region: 'AWS region code (e.g., us-east-1, eu-west-1), if omitted, returns availability for all regions', etc.
Add enum constraints for parameters with known valid values. For aws___get_regional_availability, change service from free-form string to enum with at least {EC2, Lambda, S3, RDS, CloudFront, DynamoDB, ...}. For region, define enum with all current AWS region codes. Document the source/link to the authoritative list.
Document output schemas for all tools. For list_regions, specify: 'Returns an object with regions: [{region_code: string, region_name: string, opt_in_status: string}, ...], total_count: integer.' For search_documentation, specify: 'Returns an object with results: [{title: string, url: string, summary: string, relevance_score: number}, ...], total: integer, limit: integer.'
No output schemas documented for any tool. LLMs have no way to know what fields to expect in responses, making it impossible to plan downstream calls or extract structured data reliably. get_regional_availability likely returns availability matrices; list_regions likely returns a list of region objects with codes and names, but this is inferred, not documented.
Error responses are generic. ValueError returns 400 with only a message string; 500 errors include a truncated error string but no recovery guidance. Per the recovery-guide pattern, errors must tell the LLM what to do next (e.g. 'URL must start with https://docs.aws.amazon.com, try searching for documentation first if unsure of the URL').
aws___search_documentation has a 'limit' parameter documented as 'fixed to 10' but the schema does not enforce this, LLMs could pass 100 or 1000, and the validation code does not cap the value. Undocumented enforcement invites confusion.
Tool names use 'aws___' prefix with three underscores, which is unconventional and may confuse LLMs. Standard naming is verb_noun (e.g. list_regions, search_documentation). The triple underscore suggests namespace escaping but is not documented and breaks visual parsing.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all 5 tools being read-only. Per current MCP spec, read-only tools should declare readOnlyHint: true to help agents reason about safety and retry logic.
Improve error messages to guide recovery. For read_documentation when URL is invalid, return: '400 Invalid URL: must start with https://docs.aws.amazon.com/. Try search_documentation() first to find a valid documentation URL.' For search_documentation with zero results, return: '200 No results found for "query". Try: (1) simplify your search phrase, (2) use search_documentation with topics filter, (3) or browse aws___list_regions and call aws___get_regional_availability for service data.'
Add readOnlyHint: true to all tool definitions. Agents need to know these calls are side-effect-free and safe to retry. This is now a standard annotation in MCP.
Change tool naming convention from aws___ to aws_ or remove prefix entirely. Standard practice is verb_noun: list_regions, search_documentation, get_regional_availability. If namespacing is needed, use a single underscore or a namespace prefix in the server registration, not embedded in the tool name.
For aws___search_documentation, enforce the limit parameter in validation code. Explicitly cap values: if limit > 10, set limit = 10. Add to description: 'Maximum number of results returned. Hard limit is 10. If omitted, defaults to 10.'
For aws___get_regional_availability, restrict validation to known parameter keys. Instead of accepting arbitrary keys, explicitly allow only {service, region, feature, sku, instance_type, family, platform} and return a 400 error with the list of valid keys if unknown parameters are passed. This prevents accidental misuse and makes debugging easier for LLMs.