Loading ToolBench
MCP server for security monitoring, tool discovery, and management of Model Context Protocol servers with detection pipeline for prompt injection, credential exposure, behavioral anomalies, and tool drift detection
The Aran MCP Sentinel server provides 7 security-focused tools with schemas and descriptions, but suffers from critical gaps in naming conventions, parameter documentation, and output schema clarity. All tools are present and registered with basic descriptions (50-100 chars), but lack the specificity and LLM-optimization needed for production use. Parameter descriptions are minimal or absent for compound objects. Output schemas are not documented. Error handling guidance is missing entirely. Tool names follow a class.method pattern (PromptInjectionDetector.AnalyzePrompt) rather than idiomatic verb_noun conventions, which reduces clarity for LLM selection. Most tools score in the 35-50 range; the inconsistency suggests this is an early-stage implementation.
Analyzes agent behavior for anomalies
Scans text for exposed credentials and secrets
Runs the full detection pipeline on a tool response for security analysis
Analyzes a prompt for potential injection attacks
Detects if a request is a replay attack by checking for duplicate request fingerprints within a time window
Compares stored tool metadata with live metadata to detect tool drift
Logs a tool invocation for replay detection and audit trails
Tool names use class.method pattern (PromptInjectionDetector.AnalyzePrompt) instead of idiomatic verb_noun format. LLMs struggle to parse intent from non-standard naming, and this pattern is not self-documenting. Should be: analyze_prompt, scan_credentials, analyze_agent_behavior, check_tool_drift, log_tool_invocation, check_replay_attack.
BehavioralAnalyzer.AnalyzeAgentBehavior accepts 'params' as a bare object type with no nested schema or property descriptions. LLMs cannot determine what fields are expected, their types, or whether they are required. Should define a structured schema with typed properties for each expected parameter.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 27 | - | v1 |
DetectionPipeline.AnalyzeResponse accepts both 'response' (object) and 'metadata' (object) with no nested schema documentation. The tool description does not clarify required fields, nested structure, or expected content. Output schema is also undocumented.
ToolManager.LogToolInvocation accepts an 'invocation' object with unspecified nested structure. Description mentions 'tool_id, arguments, result, status, and execution timestamp' but these are not formally declared in a schema. LLMs cannot validate the structure before calling.
No output schemas documented for any tool. Tool descriptions do not state what fields are returned, their types, or how downstream tools should interpret the results. This forces LLMs to guess response structure and breaks tool chaining.
No error handling guidance documented. None of the tool descriptions explain what happens on failure, what the LLM should do next, or how to recover from invalid inputs. No field validates input constraints (e.g., tool_id UUID format, time_window duration format).
ToolManager.CheckReplay expects 'time_window' as a string with no format specification (e.g., '5m', '1h', ISO 8601 duration). Description does not clarify format. LLMs will guess wrong, producing '5 minutes' or '300s' instead of expected format.
All tool_id parameters are described as 'UUID of the tool' with no guidance on how to obtain a tool_id. Should reference discovery tools or document where tool IDs are sourced. Likewise, request_fingerprint in CheckReplay lacks documentation on hash algorithm, input format, or generation method.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool definition. ToolManager.LogToolInvocation is marked Risk:WRITE in the listing but this is not formalized in the tool metadata. Modern MCP servers should declare write intent explicitly.