Loading ToolBench
A Model Context Protocol server for AWS cloud operations
CloudOps MCP has only 2 tools with minimal definitions. Tool names lack clear verb prefixes (ask_cli_agent, execute_aws_commands are somewhat generic). Descriptions are present but extremely brief (under 100 chars each). Parameter schemas exist but lack depth: 'message' and 'commands' parameters have minimal descriptions. No output schemas documented. No error handling guidance. No parameter validation rules, enums, or constraints visible in the code. Risk ratings are marked READ_ONLY but no destructive hints or idempotent annotations in schema. The tool definitions appear inferred from prompt files rather than explicitly registered with full MCP schemas. Code shows Agent class invoking aws_expert_agent but actual tool registration via FastApiMCP.mount() is not visible in the provided source.
Get details from the CLI agent about the AWS resources managed by the user.
Execute the aws commands through aws cli.
Tool names lack clear action verbs. 'ask_cli_agent' uses a weak verb and is vague about what CLI agent does. 'execute_aws_commands' is slightly clearer but generic. Per pattern:tool, names should start with strong action verbs (get_, create_, update_, list_, search_, execute_) to help LLMs infer intent before reading description.
Descriptions are critically short and lack WHAT, WHEN, and actionable context. 'Get details from the CLI agent about the AWS resources managed by the user' (84 chars) does not explain when to call this vs other tools, what 'CLI agent' means, or what output to expect. Per pattern:tool-description, descriptions should be 10-1024 chars with explicit guidance on selection criteria. These fall at the bare minimum.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Parameter descriptions are missing or trivial. 'message' is described only as 'The message to ask the CLI agent.', no guidance on format, length, expected content, or examples of good queries. 'commands' is described as 'The list of aws commands to execute.', no explanation of format (shell syntax? JSON? aws-cli format?), constraints, or whether dry-run is supported. Per pattern:tool-description, every parameter must have a substantive description.
No input schemas visible for parameters. The 'message' param for ask_cli_agent should declare minLength, maxLength, pattern, or enum if applicable. The 'commands' array should specify items schema, minItems, maxItems, and whether duplicate commands are allowed. Per pattern:constrained-input, enums and constraints are self-documenting and prevent hallucinated values.
No output schemas documented. What does ask_cli_agent return? A string? JSON? Structured response with cost breakdown, resource list, errors? What does execute_aws_commands return, exit codes, stdout, structured per-command results? Per pattern:tool, all tools must document return types so LLMs can plan downstream calls and extract the right data.
execute_aws_commands marked as READ_ONLY but is a write operation that executes AWS commands. This is contradictory. Per pattern:command-tool, state modification tools must declare their destructive intent clearly. No idempotentHint, destructiveHint, or readOnlyHint annotations visible in schema. LLMs need to know which calls are safe to retry.
No error handling guidance. What happens if the CLI agent is unavailable? If an AWS command fails? If invalid syntax is passed? Per pattern:recovery-guide, error responses must tell the LLM what to do next. Returning a stack trace or generic 500 error leaves the agent stuck.
No validation rules documented for 'commands' parameter. Can agents pass arbitrary shell commands or only aws-cli syntax? No mention of allowed characters, max command length, blacklist of dangerous commands (e.g., rm -rf /). Per review:param-validation-rules, expected format, range, and allowed values must be documented directly in the description.
Tool definitions appear inferred rather than explicitly registered. File locations listed as 'app/main.py' and 'app/agents/aws_expert/prompt.py' but full tool registration code (with complete schemas, error handlers, output formatters) is not provided in source. Per hard scoring rule, tools with inferred definitions cap at 50 overall.
No pagination or result-limiting strategy visible. If ask_cli_agent returns a large list of resources or execute_aws_commands returns verbose output, context window bloat is likely. Per pattern:paginated-result and mxe:enforce-result-limits, tools returning lists must support limit/offset and cap results at reasonable defaults (20-50 items).
No composition guidance. How do ask_cli_agent and execute_aws_commands interact? Can the output of ask_cli_agent be passed as input to execute_aws_commands? Are their response IDs compatible for chaining? Per pattern:tool-chain, ensure tool A's output contains IDs tool B needs.