Loading ToolBench
MCP server providing Claude Code and Claude Desktop with tools to interact with IBM Cloud Code Engine services for managing serverless applications, batch jobs, builds, and related resources
This server has 22 well-structured tools with comprehensive input schemas and descriptions. All tools are explicitly registered with name, description, and detailed JSON Schema input definitions. However, there are gaps in output schema documentation, error handling guidance, and some parameter descriptions could be more explicit about constraints and formats. The tool set is well-organized across 6 functional domains (Projects, Applications, Builds, Jobs, Domains, Secrets), and naming follows the verb_noun convention consistently. Most tools accept human-friendly identifiers (names) alongside IDs, which is good. The main weaknesses are: (1) output schemas are not documented in the tool registry; (2) error recovery guidance is minimal; (3) some parameter constraints (like CPU/memory formats) rely on descriptions rather than format/pattern/enum constraints; (4) no confirmation pattern for destructive write operations.
Deploy a new application from local source code (builds Docker image and deploys)
Create a new Code Engine application from a pre-built image
Create a build configuration from Git source
Execute a build by creating a build run
Find a Code Engine project by name with optional resource group filtering
Get detailed information about a specific application revision
Output schemas not documented in tool registry. Tools return complex objects (projects, applications, jobs) but the MCP tool registration does not include outputSchema definitions. This forces LLMs to infer result structure without explicit guidance, risking misinterpretation of returned fields.
No error handling guidance in tool descriptions. Write operations (create_application, update_application, create_build, create_build_run) do not document what errors are possible, whether they are retryable, or what the LLM should do if they fail. Example: does create_application return a specific error if the image URL is unreachable? Can the LLM retry?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get detailed information about a specific application
Get the status and details of a specific build run
Get detailed information about a specific domain mapping
Get detailed information about a specific batch job
Get the status and details of a specific job run
Get details of a specific secret (sensitive data is masked)
List revisions for a specific application
List applications in a specific Code Engine project
List build runs in a Code Engine project
List build configurations in a Code Engine project
List domain mappings in a specific Code Engine project
List executions (runs) of a specific batch job
List batch jobs in a specific Code Engine project
List all IBM Code Engine projects in your account
List secrets in a Code Engine project (sensitive data is masked)
Update configuration of an existing Code Engine application
No confirmation pattern for destructive operations. Write tools like create_application, update_application, and create_build_run modify cloud state directly without a dry-run, preview, or explicit confirmation step. Agents can accidentally overwrite configurations or trigger expensive builds.
CPU and memory parameters use free-form string descriptions ('e.g., 0.25, 0.5, 1, 2') instead of enum constraints. Descriptions mention valid values but do not enforce them with JSON Schema. LLMs may pass invalid values like 'cpu: 3' or 'memory: 256gb' that the API will reject.
Port parameter in create_application and create_app_from_source has default (8080) but no constraints (min/max). Description says 'port the application listens on' without specifying valid range (1-65535). An LLM could pass port 0 or 99999.
Pagination limits documented in description but not exposed as structured fields. list_* tools accept 'limit' with min/max constraints, which is good, but responses do not include 'total_count', 'next_cursor', or 'has_more' fields to enable LLM-driven pagination. The tool description (under 20 items returned) is inferred, not explicit.
Tool descriptions lack WHEN-to-use context for overlapping tools. For example, create_application vs create_app_from_source differ (pre-built image vs local source), but the distinction is buried in the description. A new user reading the list might not know which to call.
Parameter 'env_vars' in create_application, update_application, and create_app_from_source is typed as 'object' with description 'Environment variables as key-value pairs' but no schema for the object structure. Are all values strings? Can nested objects be passed? Format is ambiguous.
No documented example of chaining tools. If list_applications returns apps with names, the next logical call is get_application(project_id, app_name), but the response does not explicitly state that app_name can be used directly. This violates the principle of including chaining IDs.