Loading ToolBench
API 请求 MCP 服务器 - 自动发送 HTTP 请求并验证 JSON 响应
Single tool 'send_api_request' has a well-formed input schema with proper JSON Schema structure and detailed descriptions. Naming is action-oriented and clear. However, there are notable gaps: no documented output schema, missing parameter descriptions for several fields, and no explicit error handling guidance. The tool does what it claims but lacks production-grade polish around response documentation and error messages.
Send an HTTP request and return a JSON response. Supports proxy, raw body, and multipart uploads.
No documented output schema. The tool returns 'JSON response' but does not specify the structure, field names, or types of the response object. LLMs cannot plan downstream operations without knowing what fields to expect.
Missing descriptions on critical parameters. 'formFields' lacks a description of what happens when both body and formFields are provided simultaneously (error is thrown but this is not documented in the schema annotation).
Error handling provides no recovery guidance. When file does not exist or body/formFields conflict occurs, McpError is thrown with a message, but there is no documented set of error codes or recovery steps. LLMs cannot learn from errors.
No input validation documentation. The isValidRequestArgs function validates parameters at runtime, but the JSON Schema does not enforce constraints (e.g., no minLength, maxLength, or pattern for URL; no enum for HTTP method even though only 6 values are valid). Schema validation is incomplete.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Tool description is generic and lacks context about when to use it. '50-200 character descriptions that explain WHAT, WHEN, and WHY' baseline is not met. Current description (111 chars) states WHAT but not WHEN or WHY it should be preferred over other approaches.