Loading ToolBench
Agent-native network discovery over the Model Context Protocol: eleven typed tools, no command strings.
bathy-mcp exhibits significant definition quality gaps. Tool names follow verb_noun convention (scan.start, probe.execute) but lack clarity in distinguishing similar operations (scan.status vs scan.results both query scan state). Descriptions are present but minimal (10-50 chars), providing insufficient context for LLM tool selection. Input schemas are visible with basic type definitions, but parameter descriptions are sparse or generic. Output schemas are not documented. Error handling and recovery guidance are absent. The server targets network security scanning, a high-risk domain requiring explicit permission gates and audit trails, neither of which are evident.
Configure rate limiting parameters for scan execution
Query the evidence log for scan events and findings
Interpret a protocol banner to identify service and version
Generate a deterministic scan plan from targets and ports
Execute a single probe against a target
Cancel a running scan
Retrieve results from a completed scan
Start a network discovery scan with targets, ports, and optional filters
Minimal parameter descriptions. Most parameters lack actionable guidance on format, constraints, or valid ranges. E.g., 'targets' accepts 'array' but does not specify CIDR vs hostname format, or whether wildcards are allowed.
No output schemas documented. Tools return results but LLMs cannot infer response structure. E.g., scan.results returns 'results' but field names, types, and nesting are invisible.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or next steps. E.g., probe.execute does not explain what happens if target is unreachable.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2025-06-18+ | v2 |
Get the current status of a running or completed scan
Validate a scope manifest against authorization rules
Query the task store for scan state and history
Security-critical tools lack permission gates and audit declarations. scan.start and engine.rate_limit are destructive/configuration-altering but do not declare required scopes or permission checks.
Ambiguous tool naming for overlapping operations. scan.status, scan.results, and evidence.log all query scan state but names do not clearly distinguish what each returns or when to use each.