Loading ToolBench
MCP server exposing an OOP-style API Tool for making HTTP requests to public APIs
Single tool 'fetch_data' has decent schema coverage and parameter documentation, but lacks critical error handling patterns, output schema documentation, and security considerations. The tool is functional but below production grade. Naming is verb-based and clear. Parameter descriptions exist but lack constraints and validation guidance. Output structure is documented in the docstring but not in a formal schema. No error classification or recovery guidance.
Fetch data from any public API endpoint with optional headers and query/body parameters. Args: endpoint (str): Absolute URL (e.g. "https://meowfacts.herokuapp.com/"). params (dict, optional): Query parameters to append to the URL. headers (dict, optional): HTTP headers to include (no secrets!). method (str): HTTP method ("GET", "POST", "PUT", "DELETE", ...). Defaults to GET. body (dict | str, optional): Request body for non-GET methods. If dict → sent as JSON; if str → sent as raw text. Returns: dict: { "status": int, "url": str, "method": str, "query": dict, "headers": dict, "data": any | str, # JSON if possible else text }
No error handling guidance or recovery patterns. Tool documentation does not explain what happens on network failure, timeout, invalid URL, or failed auth. LLM receives raw error responses with no actionable guidance.
Output schema not formally declared. While the docstring describes return structure {'status', 'url', 'method', 'query', 'headers', 'data'}, there is no JSON Schema definition visible in tool registration. LLM cannot guarantee which fields exist or their types.
Parameter 'method' lacks enum constraint. Documentation lists allowed values ('GET', 'POST', 'PUT', 'DELETE', etc.) in text, but no formal enum in schema. Code snippet shows validation exists server-side ('Unsupported HTTP method'), but LLM cannot discover valid options statically.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Security risk: 'headers' parameter allows arbitrary header injection including Authorization, Cookie, etc. Tool description warns 'no secrets!' but does not prevent them. An agent could be tricked into exfiltrating credentials via header values. No allowlist, no sanitization visible in schema.
Parameter descriptions lack constraints and validation guidance. 'endpoint' description says 'Absolute URL' but does not specify format, protocol whitelist, domain restrictions, or length limits. 'params' and 'body' descriptions lack guidance on size limits or data type expectations.
No rate limiting, timeout, or retry guidance documented. Tool can make unbounded HTTP requests to any endpoint. If an agent retries on network errors, it could hammer a service. No maxRetries, timeout, or backoff guidance in description.
Response field 'data' is typed as 'any | str', leaving LLM uncertain of structure. If API returns nested JSON, markdown, or large datasets, LLM has no guidance on parsing or truncation. No pagination support visible despite 'any' return type potentially being a large list.