Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server defines 15 AWS infrastructure tools with reasonable naming conventions and complete input schemas. However, descriptions are generic and often minimal, parameter descriptions lack actionable constraints, and output schemas are undocumented. No tool annotations (readOnlyHint, destructiveHint) despite WRITE vs READ_ONLY risk classification. Error handling guidance is absent, tools will likely return raw AWS SDK errors without recovery hints. Naming follows verb_noun patterns well ('create-', 'get-', 'list-', 'start-'), but parameter descriptions often lack format/constraint detail required by the rubric (e.g., no minItems validation visible in subnetIds despite 'minimum 2 subnets' claim in description text). Output schemas are not visible in the provided code snippet, only input schemas are present.
Output schemas not documented. Tool definitions show input schemas but no documented return types or output field structures. LLMs cannot plan downstream calls or extract chaining IDs (e.g., instance IDs, security group IDs) without knowing what fields are returned.
Tool annotations missing (readOnlyHint, destructiveHint, idempotentHint). Risk classification exists (WRITE vs READ_ONLY) but is not exposed to the LLM via tool annotations. Agents cannot determine which tools are safe to retry without explicit hints.
Add comprehensive output schemas for all tools. Document return fields, types, and which IDs/references are available for chaining (e.g., createLoadBalancer should return loadBalancerArn, securityGroupIds, subnets for downstream tool composition).
Implement tool annotations: add readOnlyHint to all list_*, get_* tools; add destructiveHint to create_*, start_* tools; add idempotentHint only where true (none of the current tools guarantee idempotency on repeated calls with same params).
Expand tool descriptions to 100-200 chars with explicit 'When to use' guidance. E.g., 'Create a new EC2 instance with specified configuration. Use this after finalizing instance type, AMI, and security requirements. Returns instance ID, public IP, and DNS name for SSH access.' vs current 'Create a new EC2 instance with specified configuration'.
Add enum constraints to all constrained string parameters: scheme=['internet-facing', 'internal'], protocol=['HTTP', 'HTTPS', 'TCP'], targetType=['instance', 'ip', 'lambda'], healthCheckProtocol=['HTTP', 'HTTPS', 'TCP'], matcher=[list of valid HTTP status codes like '200', '200-299'], keyType=['rsa', 'ed25519'], keyFormat=['pem', 'ppk'], architecture=['x86_64', 'arm64'].
Add format and range constraints to numeric parameters: port (1-65535), port (1-65535), minSize (1-1000), maxSize (1-10000), desiredCapacity (minSize <= desiredCapacity <= maxSize), healthCheckGracePeriod (0-3600), page_size (1-100 if pagination added).
Implement error handling guidance in tool implementations. Catch AWS SDK errors and return structured responses with categories (retryable: true/false) and suggestions, e.g., 'VPCIdNotFound: The specified VPC does not exist. Call list-vpcs() to see available VPCs.' instead of raw error codes.
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 7 points across a rubric change (v1 → v2)
59/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
59
2025-06-18+
v2
2026-03-09
C
66
-
v1
73/100
Get details of a specific EC2 instance by its instance ID
get-key-pairread onlyauthsource verified73/100
Get details of a specific EC2 key pair by name. Note: Private key material cannot be retrieved after creation.
Parameter descriptions lack actionable constraints. E.g., 'subnetIds' claims 'minimum 2 subnets in different Availability Zones required' in description text but schema shows only minItems:2 without AZ constraint explanation. 'instanceType' has no description of valid values (t3.micro, t3.small, etc.). 'healthCheckPath' has no format guidance.
Tool descriptions are generic and under-100 chars. E.g., 'get-latest-amazon-linux-ami' description is only ~52 chars; 'create-auto-scaling-group' is ~36 chars. These lack context for WHEN to use the tool vs alternatives and what data it returns. Baseline is 194 chars for production tools.
No error handling guidance. Tools will return raw AWS SDK errors (e.g., 'InvalidParameterValue', 'VPCIdNotFound') without recovery suggestions. Rubric requires: 'Error responses must tell the LLM what to do next' and 'Categorize errors as retryable, user-fixable, or fatal.' Agents have no path forward on failure.
No confirmation or dry-run pattern for destructive operations. 'create-key-pair' warns 'private key material cannot be retrieved later' but offers no dry-run or confirmation step. Agents are not warned that calling this tool repeatedly with the same name will fail. No idempotency guarantees for 'create-*' tools.
Parameter documentation inconsistency. Some tools use hyphens in names ('launchTemplateName' in create-launch-template schema), others use camelCase. 'vpcId' vs 'vpcZoneIdentifier' in different tools. Naming convention should be unified. Also, some parameters lack descriptions entirely in the schema display (e.g., 'network interface configurations' in create-launch-template has nested objects but no per-field descriptions visible).
No pagination or result limits documented for 'list-ec2-instances' and 'list-key-pairs'. Rubric requires: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' These tools have optional 'tags' and 'state' filters but no visible pagination parameters in the schema.
Enum constraints missing for string parameters. 'scheme' (internet-facing vs internal), 'protocol' (HTTP/HTTPS/TCP), 'targetType' (instance/ip/lambda), 'healthCheckProtocol', 'state' are documented as free-form strings without enum declarations. LLMs will hallucinate invalid values. Rubric: 'When a parameter accepts one of a known set of values, declare it as an enum.'
Add confirmation/dry-run support for create_* tools. For create-key-pair, offer a 'dry_run' parameter or separate 'generate-key-pair' (returns private key without storing) vs 'create-key-pair' (stores public key in AWS). Warn agents about re-invocation failures.
Document parameter dependencies explicitly. E.g., create-target-group: 'protocol=HTTPS requires matcher to match 200-399; protocol=TCP ignores healthCheckPath; protocol=HTTP requires healthCheckPath to start with /'.
Add pagination support to list-ec2-instances and list-key-pairs: add 'maxResults' (1-100, default 20) and 'nextToken' parameters; return nextToken in response if more results available. Document: 'Returns max 20 results by default to fit agent context window.'
Standardize parameter naming: all camelCase or all snake_case. Currently mixed (launchTemplateName vs vpcId vs keyName). Choose one convention and apply consistently across all 15 tools.
Add per-tool security notes: document that AWS credentials are server-injected (not tool parameters), list required IAM permissions (ec2:CreateInstances, elasticloadbalancing:CreateLoadBalancer, etc.), and note that tool calls are auditable/logged.
Provide 'chaining' examples in tool descriptions or a separate 'composition guide'. E.g., 'Typical workflow: create-key-pair → create-security-group → create-launch-template (reference keyName, securityGroupId) → create-auto-scaling-group (reference launchTemplateName) → create-load-balancer (reference securityGroupId, subnetIds from ASG)'.