Loading ToolBench
MCP server for API performance analysis and load testing. Runs concurrent HTTP load tests against endpoints, analyzes results for performance issues (threadpool starvation, GC pressure, slow responses), and compares endpoint performance.
Server has 5 tools with complete schemas and descriptions. Naming follows verb_noun pattern (run_load_test, compare_endpoints, analyze_results, detect_slow_responses, detect_threadpool_starvation). Descriptions are detailed (100-250 chars) and explain WHAT and WHEN. However, parameter descriptions lack format constraints (e.g., URL validation rules, duration bounds), and output schemas are not formally documented, responses are formatted strings rather than structured JSON objects. Error handling is present but generic ('❌ Load test failed'). No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY. Missing pagination guidance for result storage.
Analyze a previous load test result by its ID and get a diagnosis. Detects slow responses, threadpool starvation symptoms, high error rates, latency variance, and GC pressure. Returns severity, issues found, and concrete .NET recommendations. Pass the result ID returned by run_load_test.
Run a load test against two endpoints and compare the results side by side. Shows percentage improvement or regression in RPS, average latency, p95, p99, and error rate. Ideal for comparing Thread.Sleep vs Task.Delay, or sequential vs parallel implementations.
Check a load test result for slow response patterns. Returns whether the endpoint has slow average latency, high p95/p99 tail latency, or poor throughput.
Analyze a load test result for ThreadPool starvation symptoms. Starvation occurs when all ThreadPool threads are blocked (e.g. by Thread.Sleep or .Result calls) and new requests queue up. The signature is a very large gap between p50 and p99 latency.
Run a load test against an API endpoint. Fires concurrent HTTP requests for the specified duration and returns throughput, latency percentiles, and error rate. Returns a result ID that can be passed to analyze_results or generate_report.
Output schemas not formally documented. Tools return formatted strings (StringBuilder output) rather than structured JSON objects. LLMs cannot reliably extract metrics (RPS, latency, error rate) for downstream analysis or chaining.
Parameter descriptions lack format constraints. 'url' parameter has no validation rules (must be HTTP/HTTPS, valid domain). 'durationSeconds' and 'concurrentUsers' have no min/max bounds. 'method' accepts 'GET or POST' but no enum constraint. LLMs may pass invalid values.
Tool annotations missing. All 5 tools are READ_ONLY (no state modification) but lack readOnlyHint annotation in schema. Agents cannot infer safety/idempotency from tool definitions alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Error messages are generic and non-actionable. 'Load test failed: {ex.Message}' or 'No result found with ID' do not guide LLM recovery. Missing recovery hints like 'Try run_load_test() first' or 'Available result IDs: ...'.
Result storage (IResultStore) has no documented pagination or limits. If load tests accumulate, responses could grow unbounded. No guidance on result retention, cleanup, or max result count.