Loading ToolBench
MCP server for AWS China partition (aws-cn) resource inventory and EKS kubectl operations, with IAM Roles Anywhere authentication support
Two tools with strong descriptions and clear use cases, but schema completeness and parameter documentation vary. call_kubectl has excellent, detailed description (500+ chars) with clear constraints and examples. cn_list_inventory has comprehensive description (800+ chars) with mode guidance and coverage warnings. Both tools have input schemas with type definitions. However, neither tool documents output schemas, and parameter descriptions in cn_list_inventory lack detail on expected formats/ranges. call_kubectl's single parameter is well-described; cn_list_inventory's parameters are present but sparse. No tool annotations (readOnlyHint, destructiveHint) despite both being read-only operations. Error handling guidance is minimal.
Execute read-only kubectl commands against the configured EKS cluster. Only the following verbs are permitted: get, describe, logs, top, explain, version, cluster-info, api-resources, api-versions. Write operations (apply, delete, patch, exec, port-forward, etc.) are rejected. For remediation commands, output the command as a draft for human approval — do not call this tool with write verbs. Examples: call_kubectl("kubectl get pods -n bjs-web -o wide") call_kubectl("kubectl describe pod <name> -n bjs-web") call_kubectl("kubectl logs <pod> -n bjs-web --since=1h") call_kubectl("kubectl get events -n bjs-web --sort-by=.lastTimestamp") call_kubectl("kubectl get deployments -n bjs-web")
Batch inventory of this AWS China (aws-cn) account's resources in ONE call. Use this FIRST when you need to know what exists in this China account — before running individual describe/list calls with call_aws. It merges AWS Resource Explorer and the Resource Groups Tagging API, because measurement shows neither API alone is complete: on a real cn account Resource Explorer saw 128 resources, the Tagging API saw 176, and only 27 overlapped. Resource Explorer finds untagged resources (CloudWatch log groups, KMS keys, ECR repos); the Tagging API finds tagged resources Resource Explorer misses (SageMaker, S3, ECS) and returns the aws:cloudformation:stack-name tags that give deployment lineage. When to use: - "What resources exist in this China account?" / inventory / stocktake - Building or refreshing a topology view of the China environment - "Which CloudFormation stacks are deployed here?" (see cloudformation_stacks) - "Where are the EKS/RDS/ECS resources?" (filter by service) - Cross-region questions: an AGGREGATOR index covers all regions in one call When NOT to use: - Full configuration of one known resource → use call_aws describe-* - Pod logs or Kubernetes state → use call_kubectl - Relationship edges between resources (which SG is on which ENI) → not available here; only AWS Config exposes those, and it must be enabled first Modes (start with summary, it is bounded regardless of estate size): "summary" (default) — counts by service / resource type / region, plus CloudFormation stack names and tag keys. ~1k tokens. "list" — one line per resource. ALWAYS pass a filter, or this can be very large (~300 bytes per resource). "detail" — full records including all tags. ALWAYS read the "coverage" and "completeness" fields before answering the user. The payload reports its own blind spots — a LOCAL (non-aggregator) index covers only one region, and a still-building index returns partial data. Report the scope you actually saw; do not present a partial result as the full estate. Examples: cn_list_inventory() cn_list_inventory(mode="summary", region="cn-north-1") cn_list_inventory(mode="list", service="eks") cn_list_inventory(mode="list", resource_type="ec2:vpc") cn_list_inventory(mode="list", tag_key="aws:cloudformation:stack-name", limit=100)
Output schemas not documented. Neither tool specifies what fields/structure the LLM should expect in responses, forcing the agent to infer output shape and risking parsing errors.
cn_list_inventory parameter descriptions lack format/range guidance. 'limit' has no bounds stated (default 200, but max?). 'mode' enum values are in description text, not formal schema enum. 'region' format (e.g. 'cn-north-1') not specified.
No tool annotations despite both tools being read-only. Missing readOnlyHint annotation prevents LLMs from reasoning about safety and retry semantics.
Error handling guidance absent. No recovery hints for common failures (e.g., 'kubectl command not found', 'region does not exist', 'insufficient permissions'). LLM has no actionable next steps on error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
call_kubectl description includes example values ('kubectl get pods -n bjs-web'). LLMs may reuse 'bjs-web' namespace literally in real calls instead of adapting to user context.