Loading ToolBench

Reading the current corpus…

inspector MCP server · F · ToolBench

inspector

A web-based inspector and debugging tool for Model Context Protocol servers. Provides a UI to interact with MCP servers, test tools, resources, prompts, and other MCP features.

2025-06-18+STREAMABLE_HTTP2 tools

47/100

Definition Quality40

Protocol Readiness56

Supportability53

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Sampling, Logging

Deprecated protocol patterns detected

Summary

This is an MCP inspector/debugging tool with 2 tools. Both tools have descriptions and basic schemas, but critical gaps prevent higher scores. listTools lacks parameter documentation (none required, but description is generic). callTool has a minimal schema with 'name' and 'args' but 'args' is typed as generic 'object' with no field-level constraints, making it impossible for LLMs to understand what arguments specific tools accept. Neither tool documents output schemas. Error handling is absent, no guidance on what happens when a tool call fails or when a tool doesn't exist. The tool names are verb-based (good), but descriptions are under 100 chars and lack context on when to use each tool or what they return. No pagination, no result limits, no idempotency hints.

Tools (2)

callToolwrite47/100

Call a tool on the connected MCP server with specified arguments

listToolsread only40/100

List all available tools from the connected MCP server

Issues (5)

CRITICALconstrained-input ↗

callTool 'args' parameter is untyped generic object, LLMs cannot infer what fields/values are valid for any given tool. Should document expected schema or accept structured input with validation.

callTool

CRITICALtool ↗

No output schemas documented for either tool. LLMs cannot plan downstream calls or extract results. listTools should document the structure of returned tools (name, description, input schema). callTool should document result format.

listToolscallTool

HIGHrecovery-guide ↗

No error handling or recovery guidance. If callTool fails (tool not found, invalid args, execution error), LLM receives no actionable error message. Should return structured errors with suggestions.

callTool

HIGHtool-description ↗

Tool descriptions are generic and under 100 chars. 'List all available tools' and 'Call a tool on the connected MCP server' lack context on when to use each, what they return, or prerequisites.

Recommendations

Document output schema for listTools: return array of {name: string, description: string, inputSchema: JSONSchema}. This lets LLMs understand what tools are available and their signatures.
Document output schema for callTool: return {success: boolean, result?: any, error?: {code: string, message: string, suggestion?: string}}. Include error codes like TOOL_NOT_FOUND, INVALID_ARGS, EXECUTION_ERROR with recovery hints.
Expand tool descriptions to 100-200 chars. E.g., 'List all tools available on the connected MCP server. Call this first to discover what tools are available and their input schemas before calling callTool.'
Add parameter descriptions: 'name' should say 'The exact name of the tool to call (case-sensitive). Use listTools to discover available tool names.' 'args' should say 'An object containing the tool's input parameters. Structure depends on the tool, use listTools to see the inputSchema for each tool.'
Implement input validation for callTool: validate that the named tool exists, then validate 'args' against the tool's schema. Return structured errors like 'Tool "foo" not found. Available tools: [list]. Did you mean "foobar"?'

Spec posture evidence

Inferred effective spec: 2025-06-18+.

Relies on Sampling (deprecated) - integrate directly with the LLM provider API

Score history

Overall score trend

First recorded score · v2 rubric

47/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	47	2025-06-18+	v2