Loading ToolBench
MCP governance server for security audit and resource control with OPA policy enforcement, audit logging, and multi-tool orchestration
SARK exposes 4 tools with critical definition gaps. Tool descriptions exist but are minimal (19-84 chars vs. baseline 194 chars). Input schemas are present but incomplete, parameters lack type definitions and comprehensive descriptions. The invoke_tool tool accepts arbitrary object arguments with no schema validation guidance. Parameters like 'tool_id', 'server_id', and 'timeout' have basic descriptions but no constraints (enum, range, format). Output schemas are not documented. Error handling descriptions are absent. The tool set mixes authentication (login), discovery (list_servers, list_tools), and invocation (invoke_tool) without clear composition or recovery paths. Security concern: login tool exposes password as a parameter rather than using server-side injection. No tool has actionable error recovery guidance or LLM-optimized descriptions.
Invoke an MCP tool through SARK with authorization policy evaluation
List all available MCP servers registered in SARK
List available MCP tools, optionally filtered by server
Authenticate with SARK using LDAP credentials
invoke_tool accepts 'arguments' as a free-form object with no schema constraints. LLMs cannot infer what keys and types the arguments dict expects, leading to malformed invocations.
login tool exposes password as a plain parameter. Credentials must never appear in tool parameters, use server-side secret injection via environment or vault to prevent leakage into agent logs and traces.
All tool descriptions are under 100 characters (baseline: 194 chars). Descriptions lack actionable context on WHEN to use each tool, what it returns, and how it chains with others. E.g., list_tools says 'List available MCP tools, optionally filtered by server' but does not explain why an agent would call this before invoke_tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Parameters lack type definitions and constraints. 'timeout' accepts an integer with no range (1-3600?). 'server_id' is a string with no format or enum. No parameter constraints enable LLMs to pass absurd values (timeout=-1, server_id=';;;').
No output schemas documented for any tool. LLMs cannot infer what fields list_servers returns, what fields list_tools includes, or how to chain results into invoke_tool calls. Missing return type documentation forces LLMs to guess.
No error recovery guidance in descriptions. E.g., invoke_tool does not explain 'If the tool is not found, call list_tools() to discover available tools' or 'Invalid arguments will return a validation error, check parameter types.' Error classification is absent.
invoke_tool description does not clarify whether it is idempotent or has side effects. Risk=WRITE suggests state modification, but agents need explicit guidance: 'This invocation may modify state. It is NOT idempotent, repeated calls will execute the remote tool multiple times.'
Tool set lacks composition guidance. The logical flow is login → list_servers → list_tools → invoke_tool, but no description hints this sequence. Agents waste planning cycles determining the order.
list_servers and list_tools do not document pagination. If the MCP registry contains 1000+ servers/tools, do these tools return all? Accept limit/offset? Return a total_count or next_cursor? Missing pagination docs invite context window exhaustion.