Loading ToolBench
Security scanner for AI agent tools. Local static scan of MCP IDE configs (41 rules, toxic flow heuristics, AAuth visibility, auto-fix, tool pinning). Optional proxy + in-browser dashboard: traffic, findings, AAuth Explorer, YARA, Playground. Smart Scan optional (your API token). Rule registry fetch is opt-in.
MCP Shark provides 6 tools for querying and invoking connected MCP servers. Tool definitions are minimally complete with names, descriptions, and partial input schemas for some tools. However, most tool descriptions are generic and lack actionable detail for LLM selection. Several tools (tools/list, prompts/list, resources/list) lack visible input schemas entirely. Output schemas are not documented. The server acts as a meta-layer over other MCP servers rather than a primary tool provider, which constrains scoring, tools are essentially passthroughs without rich semantic structure. Tool naming follows basic verb_noun patterns but descriptions lack the specificity needed for LLM reasoning (e.g., 'List all available tools' is generic; context on WHEN to call this vs. alternatives is absent). No error handling guidance or recovery patterns are visible. Input validation and parameter constraints are minimal.
Get a specific prompt from an MCP server
List all available prompts from connected MCP servers
List all available resources from connected MCP servers
Read a specific resource from an MCP server
Call a specific tool from an MCP server with provided arguments
List all available tools from connected MCP servers
Three tools (tools/list, prompts/list, resources/list) have no visible input schemas in the provided source. Per hard scoring rules, schema score must be 0 for tools without documented input structure.
Tool descriptions are all under 60 characters and lack actionable context. 'List all available tools from connected MCP servers' does not explain WHEN to call this vs. tools/call, what prerequisites exist, or what the response structure contains. Descriptions should be 50-200 chars and include dependency hints and context.
No output schemas are documented for any tool. LLMs cannot plan downstream calls or know what fields to extract without response structure documentation. A schema mapper is needed to show what each tool returns.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | 1.20.2+ | v1 |
tools/call accepts generic 'arguments' object without constraints or type hints. LLMs cannot know what fields are valid for arbitrary tool invocations. This defeats the purpose of a tool gateway, no validation or sanitization is visible.
No error handling guidance is visible. Tools return raw API errors without recovery hints. 'Tool not found' should suggest 'Call tools/list first to see available tools.' Instead, raw errors force LLM guessing.
Parameter descriptions are minimal. 'The name of the tool to call' lacks format guidance (is it 'namespace/tool' or flat 'tool_name'?). 'Tool-specific arguments' is vague, no hint of what valid keys are or how to discover them.
No permission gates or audit trails visible. tools/call can invoke any connected MCP server without apparent scope checks or logging of who called what. A meta-tool like this should gate by role and log all invocations.