Loading ToolBench
Exposes Linux kernel eBPF tools and monitoring capabilities via the Model Context Protocol
The eBPF MCP server has significant gaps in tool definition quality. While 7 tools are defined with basic names and descriptions, the definitions lack depth and rigor expected of production-grade agent tools. Descriptions are present but often generic (12-50 chars), parameter schemas are skeletal with minimal type information, and output schemas are not documented. Parameter descriptions are sparse or missing entirely. Error handling guidance is absent. The server does not follow action-verb naming consistently (e.g., 'info', 'hooks_inspect' are weaker than 'get_system_info', 'list_hooks'). Critical issues: (1) Most parameters lack type constraints and descriptions, LLMs cannot reason about valid inputs. (2) Output schemas are completely undocumented, the agent cannot plan downstream operations. (3) No error handling guidance, failures provide no recovery path. (4) Schemas shown are incomplete JSON objects without proper $schema, required arrays, or type definitions. (5) Tool names like 'info' and 'inspect_state' are vague and do not clearly convey action or responsibility.
Attach a loaded program to a hook
Inspect eBPF hooks attached to the system
Get eBPF system information
Inspect eBPF system state including programs, maps, links, and tools
Load an eBPF program
Dump contents of an eBPF map
Trace kernel errors using eBPF
Tool names lack action verbs or are vague. 'info' does not convey action; 'inspect_state' is ambiguous about what state. LLMs cannot infer intent from weak names and will conflate similar tools.
Parameter descriptions are minimal or absent. 'type' field in load_program lacks context (what enum values are valid?). 'filters' in inspect_state has no guidance on structure. Parameters must have non-empty descriptions explaining what they control.
Output schemas are completely undocumented. No tool declares what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract data without documented response schemas.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 47 | 2025-03-26+ | v1 |
Input schemas are incomplete JSON objects without formal JSON Schema structure. Missing $schema version, type declarations for object properties, required arrays, and proper enum constraints. The schema for 'attach_type' should declare an enum of valid values (xdp, kprobe, kretprobe, tracepoint) instead of relying on description text.
No error handling guidance. Tools do not provide recovery instructions (e.g., 'If program load fails, check kernel version' or 'Program not found. Call inspect_state to list available programs.'). Agents have no path forward on failure.
Tool 'info' description is only 31 characters ('Get eBPF system information'). This is below the 50-char minimum for actionable context. No guidance on when to call it vs. inspect_state, what structure is returned, or what the agent can do with the result.
Parameter 'options' in attach_program is declared as object type with no schema or structure guidance. LLMs cannot reason about what keys/values are valid. Must provide concrete examples or a JSON Schema definition of the object structure.
No documentation of dependencies or required call order. E.g., must a program be loaded before it can be attached? Must inspect_state be called first to list available programs? Tool descriptions must state prerequisites and dependencies.