Loading ToolBench
A Model Context Protocol server providing tools to make HTTP requests (GET, POST, PUT, PATCH, DELETE)
The server defines 5 HTTP method tools with clear, action-verb naming (http_get, http_post, http_put, http_patch, http_delete). All tools have descriptions (120-180 chars, within the 10-1024 baseline) and complete JSON Schema input definitions with properly typed parameters. However, several quality gaps prevent a higher score: (1) output schemas are not documented, the response format (status code, headers, body) is only evident from the implementation, not declared in the tool definition; (2) error descriptions lack actionable recovery guidance, LLMs receive only generic McpError wrapping without hints on what to do next; (3) parameter descriptions are present but minimal (30-50 chars), providing bare minimum context; (4) no enum constraints exist for common header names or body types, leaving room for LLM hallucination; (5) the tool does not declare whether it supports retries on transient failures or what constitutes a retryable error. The server follows basic MCP tool registration patterns but omits response schema documentation and error recovery guidance that production tools require.
Makes an HTTP DELETE request to the specified URL. Use this to delete resources from an API.
Makes an HTTP GET request to the specified URL. Use this to retrieve data from an API or web server.
Makes an HTTP PATCH request to the specified URL with an optional body. Use this to partially update existing resources in an API.
Makes an HTTP POST request to the specified URL with an optional body. Use this to create new resources or submit data to an API.
Makes an HTTP PUT request to the specified URL with an optional body. Use this to update or replace existing resources in an API.
Output schemas not documented. The tools return (status_code, response_headers, response_body) but this structure is not declared in the tool registration. LLMs cannot plan downstream operations without knowing what fields to expect.
Error responses lack actionable recovery guidance. When an HTTP request fails (HTTPError caught in make_http_request), the McpError contains only 'Failed to make {method} request to {url}: {e!r}'. LLMs receive no hint on whether to retry, whether it's a client error, rate limit, or network issue.
No input validation or error categorization. Tools accept 'headers' and 'body' as free-form objects without type hints or constraints. If an LLM passes body={...} as a nested dict where a string is expected, or headers with non-string values, the error message will not guide correction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter descriptions are minimal (30-50 chars). The 'body' parameter says 'Optional request body. Can be a JSON object or a string. If a dict is provided, it will be sent as JSON' but does not explain when to use each form, what Content-Type headers are set, or how deeply nested structures are handled.
No mention of request limits, timeouts, or retry semantics. The make_http_request function sets timeout=30 seconds, but this is not exposed to the LLM. An LLM might assume timeouts are configurable or that the tool will retry on transient failures.