Loading ToolBench
Execute Python code on RunPod infrastructure and manage RunPod endpoints
Two tools with minimal schema documentation and weak descriptions. execute_python_code has a single string parameter with no type validation, format constraints, or safety guardrails documented. check_runpod_status has no parameters but lacks context on when to call it vs execute_python_code. Neither tool documents output structure, error recovery paths, or idempotency guarantees. No parameter descriptions beyond the tool docstring. Missing pagination, rate limiting, and destructive operation warnings despite execute_python_code being IRREVERSIBLE.
Check the status of the RunPod connection and endpoint.
Execute Python code on RunPod and return the results.
execute_python_code lacks destructive operation warnings and confirmation pattern. Tool executes arbitrary code (IRREVERSIBLE risk) with no dry-run, confirmation step, or explicit warning in description that this is a dangerous operation.
No input schema validation or constraints documented. 'code' parameter accepts any string with no length limits, format validation, or safety constraints. LLM could pass multi-megabyte payloads or malicious code without guidance.
Output schema not documented. execute_python_code returns formatted text with stdout/stderr/return_code embedded in a string, not structured JSON. LLM cannot reliably parse execution results or distinguish success from failure.
Error handling lacks recovery guidance. Timeout, API errors, and missing credentials return raw error messages without actionable next steps (e.g., 'Check RUNPOD_API_KEY is set' or 'Retry with smaller code snippet').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Hardcoded API key in source code. RUNPOD_API_KEY set to 'xxx' in server.py is a security anti-pattern. Credentials must use environment variable injection only, never hardcoded defaults.