Loading ToolBench
Kubernetes Computational Mathematics MCP Server - enables LLMs to offload heavy mathematical and financial computations to a Kubernetes cluster using specialized operators like Kubeflow MPI-Operator and JobSet
Server defines 5 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (submit_*, check_*, read_*). Descriptions are present (avg 150 chars) and explain WHAT the tool does and WHEN to use it. However, output schemas are not documented, LLMs cannot predict return structure for downstream chaining. Parameter descriptions are adequate but lack format/constraint details (e.g., 'job_id' has no format hint). Error handling is absent, no guidance on retryability, recovery steps, or actionable error messages. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write semantics. Composition is sound: tools are single-responsibility and chainable (submit_* returns job_id, check_status accepts job_id). Security: no secrets in params (good), but no audit logging or permission gates visible.
Check the status of a submitted job. Returns phase (Pending/Running/Succeeded/Failed) and replica counts.
Read the first N lines of a result file from the shared storage (PVC at /mnt/data). Useful for inspecting job outputs without downloading entire files.
Submit a batch of parallel Monte Carlo simulations using JobSet. Each replica gets a unique JOB_COMPLETION_INDEX for output path uniqueness. Returns immediately with a job ID (non-blocking).
Submit an MPI workload to the Kubernetes cluster. Returns immediately with a job ID (non-blocking). Use check_status to monitor progress.
Submit a job to aggregate results from Monte Carlo simulations or other batch jobs. Returns immediately with a job ID (non-blocking).
Output schemas not documented. LLMs cannot predict return structure (e.g., what fields does check_status return? Is it {phase, replicas} or {status, details, metadata}?). This breaks downstream tool chaining and forces agents to guess field names.
No error handling guidance. Tools return errors but do not tell LLMs whether to retry, ask the user, or give up. E.g., 'job not found', is this retryable? Should the agent search for the job first?
No tool annotations. submit_* tools are destructive (create K8s resources) but lack destructiveHint. check_status and read_artifact_head are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Parameter descriptions lack format/constraint details. 'job_id' has no format hint (UUID? alphanumeric?). 'namespace' defaults to 'client default' but does not explain what that means. 'lines' has min/max but no guidance on typical values.
No pagination or result limits documented. read_artifact_head accepts 'lines' up to 1000, what happens if the file is 10MB? No guidance on chunking or streaming large results.