Loading ToolBench

Reading the current corpus…

mcpg-inspector MCP server · F · ToolBench

← Browse

mcpg-inspector

github.com/mcpg-dev/mcpg-inspector

MCP inspector for mcpg — web UI, TUI and scriptable CLI in one binary

2025-06-18+STREAMABLE_HTTP3 tools

48/100

Definition Quality40

Protocol Readiness68

Supportability48

Spec posture

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

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

MCPG Inspector exposes 3 tools with critical definition gaps. tools.list and resources.read lack visible input schemas in source; tools.call has a minimal schema but no parameter descriptions. All three tools have descriptions under 100 chars, insufficient for LLM reasoning. No error handling guidance, no output schemas documented, no parameter constraints (enums, ranges). Tool definitions appear inferred from UI components rather than explicit MCP registration. This server prioritizes inspection/debugging over production-grade tool design.

Tools (3)

resources.readread onlysource verified37/100

Read the contents of a resource from the connected MCP server

tools.callwritesource verified45/100

Call a tool on the connected MCP server with specified arguments

tools.listread onlysource verified37/100

List all tools available on the connected MCP server

Issues (5)

CRITICALtool ↗

No input schemas visible for tools.list and resources.read; tools.call schema lacks parameter descriptions.

tools.listtools.callresources.read

CRITICALtool-description ↗

All tool descriptions under 100 chars; insufficient context for LLM selection. Baseline: 194 chars average. E.g. 'List all tools available on the connected MCP server' lacks WHEN to use, WHAT it returns, prerequisites.

tools.listtools.callresources.read

HIGHconstrained-input ↗

tools.call accepts 'arguments' as free-form object with no type constraints, validation rules, or error guidance. LLM cannot infer valid argument structure.

tools.call

HIGHtool ↗

No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g. does tools.list return tool_id, tool_name, tool_description?).

tools.listtools.call

Recommendations

Add explicit input schemas to tools.list (empty object or optional filters) and resources.read (uri: string, required). Document all parameter types and descriptions.
Expand tool descriptions to 150-250 chars. Example for tools.call: 'Call a tool on the connected MCP server. Provide the tool name and arguments object. Returns the tool's result or error. Use tools.list first to discover available tools and their argument schemas.'
For tools.call, document the 'arguments' parameter as 'Object with tool-specific key-value pairs. Consult tools.list output for each tool's required and optional arguments.' Add validation: reject calls with unknown tool names.
Document output schemas for each tool. E.g. tools.list returns {tools: [{name: string, description: string, inputSchema: object}]}. tools.call returns {result: any, error?: string}.
Add error handling: 'If tool not found, call tools.list to verify name. If execution fails, check argument types against the tool's inputSchema in tools.list output.'

Spec posture evidence

Inferred effective spec: 2025-06-18+.

Current-spec patterns present: structured tool output, Streamable HTTP

Score history

Overall score trend

First recorded score · v2 rubric

48/100

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