Loading ToolBench
Self-healing API proxy MCP — your API calls, but they never actually break.
ProxyPI has 4 tools with clear naming (verb_noun pattern: proxypi_request, proxypi_history, proxypi_replay, proxypi_clear). Descriptions are present and substantive (100-200 chars), exceeding the 10-char minimum. Input schemas use Zod with type definitions and descriptions for all parameters. However, output schemas are not formally documented, responses are inferred from code (text content only, no structured object schema). Error handling is basic (try/catch with formatApiError), lacking recovery guidance or error classification. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (3 READ_ONLY, 1 DESTRUCTIVE). Parameter descriptions are good but could specify constraints more formally (e.g., 'limit: 1-50' is in schema but not emphasized in description text).
Clear all stored healing records from memory.
Show the history of auto-healed API requests. Optionally filter by API host.
Replay a previously healed request. Useful for testing that a fix still works after an API update.
Send a request to any REST API. If the request fails, ProxyPI diagnoses the error, patches the request using Claude, and retries automatically — up to 3 times. Learned fixes are remembered and applied instantly next time without calling Claude. Examples: - GET https://api.github.com/users/torvalds - POST https://api.stripe.com/v1/customers with a body - Any REST endpoint with headers, body, or query params
Output schemas not formally documented. Tool responses return text content only; no structured object schema is declared. LLMs cannot plan downstream tool calls or extract typed fields reliably.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). proxypi_clear is destructive but unmarked; proxypi_request, proxypi_history, proxypi_replay are read-only but unmarked. Agents cannot infer safety/retry semantics.
Error handling lacks recovery guidance. Errors return raw messages (e.g., 'ProxyPI error: ...') without actionable next steps or error classification (retryable vs. user-fixable vs. fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
proxypi_clear has minimal description (60 chars: 'Clear all stored healing records from memory.'). No warning about irreversibility or confirmation step. Destructive operations should require explicit confirmation.
Parameter descriptions do not emphasize constraints. E.g., 'limit' has min/max in schema (1-50) but description says only 'Number of records to show', LLMs may not parse JSON Schema constraints and rely on text.