Loading ToolBench
An AI interface for Inspektor Gadget to debug and monitor applications in Kubernetes clusters and Linux systems
This MCP server has significant structural issues that prevent reliable LLM interaction. Of 6 tools, 3 (gadget_trace_dns, gadget_snapshot_process, gadget_top_tcp) have incomplete input schemas with empty parameter properties, making it impossible for an LLM to understand what values to pass. Tool naming is inconsistent (verb-noun for ig_lifecycle, ig_gadgets, but bare gadget_* for others). Descriptions are present but generic and fail to explain when/why to use each tool or what the output structure is. Error handling is not documented. No output schemas are visible. The gadget_trace_open tool has an empty input schema ({}) with no documentation of what it does or how to control it. The server lacks critical composition patterns: tools don't document chaining relationships (e.g., does 'is_deployed' action need to run before 'deploy'?), and gadget tools offer no guidance on which gadget to choose for different observability scenarios.
Tool for image "snapshot_process:latest", complete description will be available once Inspektor Gadget is deployed
Tool for image "top_tcp:latest", complete description will be available once Inspektor Gadget is deployed
Tool for image "trace_dns:latest", complete description will be available once Inspektor Gadget is deployed
Ephemeral gadget tool for trace_open
Manage running gadgets
Manage the deployment of Inspektor Gadget on target system
Three gadget tools (gadget_trace_dns, gadget_snapshot_process, gadget_top_tcp) have empty input parameter schemas with '"properties":{}'. LLMs cannot understand what inputs these tools accept or how to invoke them.
gadget_trace_open has a completely empty input schema ({}) with no parameters defined. The description 'Ephemeral gadget tool for trace_open' does not explain what the tool does, when to use it, or what parameters are available. This violates the tool-description pattern requiring descriptions to answer WHAT, WHEN, and expected output.
No output schemas are documented for any tool. LLMs need to know what fields to expect in responses so they can extract data and plan downstream calls. Without documented return types, agents cannot reason about chaining or composing calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Tool descriptions are generic and fail to explain WHEN to select each tool instead of alternatives. E.g., three similar gadget tools (trace_dns, snapshot_process, top_tcp) are documented identically ('Tool for image X, complete description available once deployed'). LLMs cannot distinguish when to use each.
Inconsistent tool naming: ig_lifecycle and ig_gadgets use verb_noun (manage), but gadget_* tools use bare noun_verb with no clear action verb. For gadget_trace_dns, does 'trace' imply starting a trace, listing traces, or retrieving trace results? The name alone is ambiguous.
No error handling documentation. If a gadget fails to run (e.g., insufficient privileges, eBPF not available), what error does the LLM receive? How should it recover? Should it fall back to a different gadget? This is completely undocumented.
Tool composition relationships are undocumented. ig_lifecycle has an 'is_deployed' action, does this need to succeed before gadget_* tools will work? Do gadgets require the Inspektor Gadget to be deployed? These dependencies are not stated, forcing LLMs to guess or discover through trial and error.
The 'params' parameter in gadget_trace_dns, gadget_snapshot_process, and gadget_top_tcp is defined as 'key-value pairs of parameters' but the properties object is empty. There is no documentation of what keys are valid (e.g., pod name, namespace, container name?). LLMs cannot invoke these tools without knowing what parameters to pass.
Description lengths: gadget_trace_open is only 31 chars, gadget_snapshot_process is 76 chars. Even at 31-76 chars, these are too short to explain what the tool does, when to use it, or what it returns (baseline 194 chars, p10=34 chars but those still have meaningful content).