Loading ToolBench
A multi-layered security framework for AI agent execution with scanning, signing, sandboxing, reference monitoring, and audit logging. Includes AgentProxy (Layer 4 reference monitor), Scanner API (Layer 1), FlightRecorder (Layer 5), OpenClaw, ReplayEngine, MemoryService, CodeRunner, and Dashboard.
This is a security policy evaluation service, not a traditional MCP tool server. The 4 tools (evaluate, health, status, metrics) are monitoring/observability endpoints. All tools lack proper input schemas, only 'evaluate' has parameters, but they are not formally defined in JSON Schema format. Descriptions exist but are generic and lack LLM-optimized guidance. No output schemas are documented. Tools do not follow verb_noun naming conventions (e.g., 'evaluate' is ambiguous; 'evaluate_tool_call' would be clearer). No error handling guidance, no parameter constraints, no pagination support. This server appears designed for internal platform monitoring, not agent tool composition.
Evaluates tool calls through a security pipeline with multiple gates (rate limiting, human gating, capability checking, semantic scanning, CER analysis). Returns decision (Allow/Deny/HumanGate) with detailed gate results and audit hash.
Health check endpoint returning service status, layer information, and runtime details.
Returns performance metrics snapshot including RPS history, deny rate history, CER history, gate latencies, and per-skill token burn statistics.
Returns comprehensive system status including uptime, evaluation counts, CER, layer status, and performance metrics (RPS, latency percentiles).
No JSON Schema input definitions visible for any tool. Only 'evaluate' declares parameters (skill, tool, tokenBudget, tokenCount) but without formal type/constraint definitions. health, status, metrics accept empty input {} with no schema.
Tool names lack action verbs. 'evaluate', 'health', 'status', 'metrics' are nouns or generic terms. Should be 'evaluate_tool_call', 'get_health_status', 'get_system_status', 'get_performance_metrics' to clarify intent.
No output schemas documented. Descriptions mention return fields (e.g., 'decision', 'gate results', 'audit hash' for evaluate; 'uptime', 'RPS', 'latency percentiles' for status) but no formal schema definition. LLMs cannot plan downstream tool calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Parameter descriptions for 'evaluate' are minimal. 'skill' and 'tool' lack context on valid formats (e.g., are they free-form strings, enum values, or IDs?). 'tokenBudget' and 'tokenCount' lack units/range constraints.
No error handling guidance. Descriptions do not explain failure modes, recovery steps, or what the LLM should do if a call fails (e.g., if 'evaluate' returns Deny, what should the agent do next?).