Loading ToolBench
MCP server for diagnosing .NET applications via process ID, providing memory stats, GC events, thread pool statistics, event counters, and environment information
Strong tool naming (all verb-prefixed: get_*, list_*) and comprehensive descriptions (150-250 chars each, well above 10-char minimum). All 7 tools have clear input schemas with typed parameters and descriptions. Descriptions include WHEN to use each tool and dependency hints (e.g., 'Call get_process_info first'). However, output schemas are not documented, responses appear to be free-text strings rather than structured objects. Error handling is basic (returns 'Error:' prefix) without recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite all being read-only. Parameter descriptions are good but lack explicit constraints (e.g., sampleSeconds has no min/max bounds stated).
Returns runtime environment information for a target .NET process including .NET runtime version, OS details, processor count, memory, and process configuration. Use this when investigating version mismatches, environment-specific bugs, or unexpected runtime behavior. Call get_process_info first to confirm the process is reachable.
Returns all available EventCounter metrics from a .NET process including CPU usage, memory, GC, threading, exceptions, and JIT stats in a single call. Use this for a broad health overview when you don't know which specific area to investigate. For deeper analysis, follow up with get_memory_stats or get_thread_stats.
Returns recent GC events for a target .NET process including collection generation (Gen0/Gen1/Gen2), duration, pause time, and timestamp. Use this when investigating periodic response time spikes, application pauses, memory that grows without releasing, or when get_memory_stats shows high Gen2 collection counts. Call get_memory_stats first to establish whether GC pressure is the root cause before drilling into individual events.
Returns current .NET memory usage for a target process including total allocated bytes, GC generation collection counts (Gen0/Gen1/Gen2), Large Object Heap size, and memory pressure level. Use this when investigating memory leaks, unexpectedly high memory usage, frequent GC pauses, or slow application performance caused by garbage collection pressure. Call get_process_info first to confirm the process is reachable.
Returns basic information about a running .NET process by PID. Includes process name, uptime, .NET runtime version, OS platform, and CPU core count. Use this as the first step when investigating any .NET application — it confirms the process is reachable and provides baseline context before diving into memory or thread diagnostics.
Output schemas not documented. All tools return free-text strings (e.g., 'Error: ...', 'Process Name: ...') rather than structured JSON objects. LLMs cannot reliably parse unstructured text or chain results to downstream tools.
No tool annotations. All 7 tools are read-only (Risk: READ_ONLY) but lack readOnlyHint annotation in schema. Agents cannot infer safety/idempotency from tool definitions.
Parameter constraints missing. sampleSeconds parameter (used in 5 tools) has no min/max bounds documented. LLMs may pass invalid values (0, negative, or extremely large numbers).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Returns .NET ThreadPool statistics for a target process including worker thread count, available threads, queue length, and completed work items. Use this when investigating slow response times, request timeouts, or deadlocks — high queue length and low available threads indicates thread starvation, which is a common cause of latency spikes in .NET APIs. Call get_memory_stats first — GC pressure is a frequent cause of thread starvation.
Lists all available EventCounter names and current values from a .NET process. Use this to discover what metrics are available before calling get_memory_stats.
Error responses lack recovery guidance. Tests show errors return 'Error: <message>' but do not suggest next steps (e.g., 'Invalid PID. Verify the process is running with: ps aux | grep <name>').
ListCounters description is vague ('Lists all available EventCounter names and current values'). Does not explain what an EventCounter is or why an agent would call this before get_memory_stats.