Loading ToolBench

Reading the current corpus…

fetchr MCP server · C · ToolBench

fetchr

HTTP client with TLS fingerprinting — CLI, MCP server, and Go package. Supports JA3/JA4 fingerprinting, HTTP/2, HTTP/3, custom headers, proxies, and browser profiles.

<=2025-11-25STDIO2 tools

60/100

Definition Quality75

Protocol Readiness47

Supportability45

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Two tools with complete JSON schemas and reasonable descriptions. Tool naming is clear (request, batch) and action-oriented. Schemas are well-structured with proper types and enums. However, parameter descriptions lack depth, many fingerprinting params (ja3, ja4r, http2_fingerprint, quic_fingerprint) have minimal or no guidance on format/usage. Output schema is undocumented; LLMs cannot predict response structure. Error handling is basic (errorResult returns plain text). No guidance on when to use batch vs sequential requests, or how to interpret TLS fingerprint responses.

Tools (2)

batchread onlysource verified72/100

Make multiple HTTP requests in parallel with TLS fingerprinting. Returns an array of responses in the same order as the requests.

requestread onlysource verified77/100

Make HTTP requests with TLS fingerprinting (JA3/JA4, HTTP/2). Supports all methods, custom headers, body, cookies, proxy, timeout, redirect control, and browser profiles.

Issues (5)

HIGHtool ↗

Output schema undocumented. LLMs cannot predict response structure (status_code, headers, body, timing, etc.). Forces agents to guess field names for downstream processing.

requestbatch

HIGHconstrained-input ↗

TLS fingerprinting parameters (ja3, ja4r, http2_fingerprint, quic_fingerprint) lack format guidance. No examples, no constraints, no explanation of when/why to use each. LLMs cannot reliably construct valid fingerprints.

requestbatch

MEDIUMtool-description ↗

Parameter descriptions are sparse. 'header_order' says 'critical for fingerprint accuracy' but does not explain format (array of header names? order matters how?). 'profile' references 'chrome, firefox' but no enum constraint or discovery mechanism.

requestbatch

MEDIUMrecovery-guide ↗

Error handling returns plain text (errorResult). No categorization (retryable vs fatal), no recovery guidance, no invalid-value echoing. LLMs cannot self-correct on validation failures.

Recommendations

Document the response schema for both tools. Include fields: status_code (int), headers (object), body (string), timing (object with connect_ms, ttfb_ms, total_ms), tls_version (string), cipher_suite (string). This enables LLMs to extract and chain results.
Add enum constraints for 'profile' parameter. Instead of 'e.g. chrome, firefox', define: enum: ['chrome', 'firefox', 'safari', 'edge', 'custom']. If custom profiles are supported, document how to define them.
Expand TLS fingerprinting parameter descriptions. For ja3: 'JA3 fingerprint string (format: SSLVersion,Ciphers,Extensions,EllipticCurves,EllipticCurveFormats). Use to mimic specific TLS client behavior.' Similar detail for ja4r, http2_fingerprint, quic_fingerprint.
Enhance error responses with structured error objects: {error: string, code: string, retryable: boolean, suggestion: string}. Example: {error: 'Invalid ja3 format', code: 'INVALID_JA3', retryable: false, suggestion: 'ja3 must be comma-separated: SSLVersion,Ciphers,...'}.
Add tool selection guidance in batch description: 'Use batch for 10+ parallel requests to the same domain. For sequential requests or mixed domains, use request in a loop. Batch returns results in request order.'

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

60/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	60	<=2025-11-25	v2