Loading ToolBench
MCP Server for Kubernetes OpenAPI Discovery. Discovers Kubernetes services, fetches their OpenAPI specifications, and exposes them through the Model Context Protocol for integration with AI assistants.
The server provides 4 tools with clear action verb names (list_, get_, invoke_) and reasonable descriptions. All tools have input schemas with typed parameters and descriptions. However, there are significant gaps: output schemas are not documented, error handling guidance is minimal, the invoke_endpoint tool lacks dry-run or confirmation patterns for an IRREVERSIBLE operation, and parameter constraints (enums, min/max) are sparse. Tool descriptions are adequate (100-150 chars) but lack dependency hints and recovery guidance. This is solid foundation work but falls short of production-grade quality.
Gets complete details of an operation: parameters, request body schema, response schemas
Lists all HTTP operations (endpoints) available in a microservice
Invokes a microservice endpoint. WARNING: This executes a real HTTP call to the service.
Lists all microservices with OpenAPI specs available in the K8s cluster
invoke_endpoint is IRREVERSIBLE but lacks confirmation or dry-run support. No guidance on recovery if the operation fails partway through or produces unintended side effects.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract required fields (e.g., service_id returned by list_services for use in get_operations). This breaks tool chaining.
invoke_endpoint accepts 'body' as a plain string, not structured JSON. This invites parsing errors and makes it unclear to the LLM what structure is valid. Parameter should document expected JSON format or accept an object type.
path_params and query_params are typed as generic 'object' with no constraints or description of expected structure. LLMs cannot validate what keys are needed or their types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Tool descriptions lack dependency hints. E.g., get_operations should state 'Call list_services first to discover service_id values.' This guides planning and reduces wasted calls.
No error handling guidance in any tool description. What should the LLM do if list_services returns no results? If invoke_endpoint times out? If a service lacks an OpenAPI spec?
get_operations and get_operation_details use optional string parameters (tag, method, operation_id) without enums or constraints. 'method' should be an enum: GET, POST, PUT, DELETE, PATCH, etc.
active_only in list_services is a boolean but no default value is specified. Should it default to true (only active) or false (all services)?