Loading ToolBench
MCP server for rapidly creating mocked REST APIs from JSON examples
The server has three well-named tools with clear, detailed descriptions (avg 180 chars) and explicit input schemas. However, output schemas are completely undocumented, critical for agent planning. Error handling is present but minimal (no guidance on retries or recovery). Tool compositions are sound (three distinct responsibilities), but missing validation details in parameter descriptions. No tool annotations (readOnlyHint, destructiveHint) despite having tools with clear risk profiles. Per-tool scores: create_mock_api=70, get_deployment_status=68, delete_mock_api=66 (avg=68).
Start creating a CRUD REST API from sample data. Returns immediately. This enqueues a background deployment job. Poll get_deployment_status with the returned deployment_id to check progress.
Delete a previously created mock API. Removes the Container App and CosmosDB container for the given deployment.
Check the status of a deployment started by create_mock_api. Poll this until status is 'succeeded' or 'failed'.
Output schemas completely undocumented. create_mock_api returns {deployment_id, status}, get_deployment_status returns a job object, delete_mock_api returns {deployment_id, status, error?}, none of these response structures are documented for the LLM. Agents cannot reliably extract fields or plan downstream calls.
Missing tool annotations. delete_mock_api is destructive (removes Azure resources), but has no destructiveHint annotation. get_deployment_status is read-only but has no readOnlyHint. These annotations guide agent confidence in retry/side-effect decisions.
Parameter descriptions lack validation constraints. 'record_count' has no bounds (0-10000?). 'name' has no length limit or character restrictions. 'sample_records' has no schema for individual record structure. Input validation happens inside the tool, but LLM cannot see constraints in descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Error responses are minimal. create_mock_api returns {error, status} on validation failure, but does not guide next steps. E.g., 'name must be a non-empty string' doesn't explain how to recover. delete_mock_api catches exceptions into 'errors' array but returns no guidance on transient vs. permanent failures.
No pagination or result-limiting documented. delete_mock_api queries all container apps matching the deployment_id prefix and processes all in a loop. If 100s exist, response could be massive. No documented limit or guidance for agents on handling large result sets.
create_mock_api description mentions 'background deployment job' and polling, but does not specify expected polling interval, max wait time, or timeout behavior. Agents cannot determine reasonable retry strategy.
get_deployment_status does not document job state machine. Description says 'Poll until status is succeeded or failed', but does not list all possible status values (accepted, queued, in_progress, succeeded, failed?). LLM cannot reliably detect completion.