Loading ToolBench
MCP server exposing the full 2Captcha API surface (~31 captcha types + management + pingback CRUD) to Claude Code
Three tools with complete input/output schemas and descriptions. Naming follows verb_noun pattern (list, get, clear). Descriptions are adequate (60-120 chars) but lack actionable context for LLM selection. Parameters are typed and described, but lack constraints (enums, ranges). Output schemas are documented via Pydantic models. Error handling is minimal, no recovery guidance or categorization. Missing: parameter validation rules in descriptions, idempotency guarantees, and destructive operation confirmation patterns.
Delete pingback events from the local store. Combine filters or pass {} to wipe all. Returns {deleted: int}.
Fetch a single pingback event by captcha_id. Returns {event} or {event: null}.
List pingback events received by the local webhook receiver (see twocaptcha-mcp-webhook). Filter by `since_received_at` (Unix sec) to poll only new events. Returns {events, count}.
Destructive tool (twocaptcha_pingback_events_clear) lacks confirmation or dry-run pattern. No guidance on recovery if user accidentally wipes all events.
Parameter descriptions lack validation rules. 'since_received_at' and 'before_received_at' accept Unix timestamps but do not specify format, range, or example. LLMs may pass invalid values.
Error handling in dispatch_tool_call (server.py) returns generic error strings without recovery guidance. 'api_error: ...' tells LLM nothing about retry eligibility or next steps.
Tool descriptions do not explain when to use each tool or dependencies between them. LLM cannot infer that list() should be called before get() or clear().
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Output schema for list tool does not document pagination or result limits. No indication of max events returned or whether results are truncated.