MCP server for running benchmark tests against backend APIs using benchmark-proxy service
Three tools with complete input schemas and descriptions, but significant quality gaps. Tool names lack action verbs (call, run_duration_test, run_times_test are weak). Descriptions are present but generic, 'Runs a benchmark test' repeats across tools without distinguishing when to use each. Parameter descriptions are adequate but lack constraints (no min/max for duration_seconds, concurrency, times). Output is unstructured raw text, not typed objects. No error recovery guidance. The 'call' tool is a low-level wrapper; run_duration_test and run_times_test are higher-level but poorly differentiated. Missing pagination, result limits, and structured response schemas.
Call a benchmark test job for the backendAPI using benchmark-proxy service. Example: curl https://www.baidu.com \ -H 'Benchmark-Proxy-Times:1' \ -H 'Benchmark-Proxy-Concurrency:1'
Runs a benchmark test for a specified duration and concurrency.
Runs a benchmark test for a specified number of times and concurrency.
Tool names lack action verbs. 'call' is vague; 'run_duration_test' and 'run_times_test' are similar and undifferentiated. LLMs cannot infer intent from names alone.
Output is unstructured raw text (curl stdout). No typed response schema. LLMs cannot parse results reliably or extract fields for downstream calls.
Numeric parameters (duration_seconds, concurrency, times) lack min/max constraints. LLMs can pass absurd values (0, -1, 999999) that break the service.
Error handling returns raw curl stderr/stdout. No recovery guidance. LLM cannot determine if error is retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
run_duration_test and run_times_test are nearly identical in signature and behavior. Descriptions do not explain when to use one vs the other.