Loading ToolBench

Reading the current corpus…

dsh-mcp MCP server · F · ToolBench

dsh-mcp

MCP management UI + tool search — stable tool list, cache-friendly, no context bloat. Visualizes configuration/start-stop/refresh of MCP servers and tool selection, on-demand tool search with hot injection.

2026-07-28+STREAMABLE_HTTP12 tools

49/100

Definition Quality47

Protocol Readiness55

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

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

Deprecated protocol patterns detected

Summary

dsh-mcp exposes 12 tools for MCP server management and tool control. Most tools lack proper input schemas and descriptions are minimal (10-50 chars). Tool names are reasonable (verb-noun style: list, upsert, delete, test, toolsList, toolsSet, toolsMode, envList, envSet, adopt, release) but parameter documentation is sparse. No output schemas are documented. Error handling is absent, no recovery guidance or categorization. The server manages MCP configuration state but does not follow production-grade tool definition patterns.

Tools (12)

adoptwritesource verified50/100

Take over management of an MCP server declared in Cordis patch layers

deletedestructivesource verified52/100

Delete an MCP server configuration

envListread onlysource verified33/100

Read the process-level environment variables

envSetwritesource verified50/100

Set process-level environment variables

listread onlysource verified35/100

Read the MCP server list

releasewritesource verified50/100

Release management of an MCP server back to Cordis patch layers

testread onlysource verified52/100

Test the connection to an MCP server

toolsListread onlysource verified

Issues (5)

CRITICALtool ↗

No output schemas documented. Tools like list, toolsList, envList return data but LLMs cannot predict field structure, forcing guesswork on downstream tool calls.

listtoolsListenvList

CRITICALtool-description ↗

Descriptions are too short (10-50 chars). 'Read the MCP server list' and 'Read the tool-control state' lack context on WHEN to call, WHAT data is returned, and HOW to use results. LLMs cannot reliably select these tools.

listtoolsListenvListtest

HIGHtool-description ↗

Parameter descriptions are missing or trivial. 'Server configuration object' and 'Environment variables for the server' do not explain structure, required fields, or format. LLMs cannot construct valid payloads.

upsertupsertJsontest

HIGHconfirmation-request ↗

Recommendations

Add output schemas to all tools. Document what fields list, toolsList, and envList return (e.g., list returns {servers: [{id, name, command, env}], total: number}). This enables LLMs to chain tool calls correctly.
Expand descriptions to 100-200 chars. Example: 'list' → 'Retrieve all configured MCP servers with their IDs, commands, and environment variables. Use this to discover available servers before testing or modifying them.'
Document parameter structures. For 'server' object in upsert, specify required fields (command, args?) and optional fields (env, disabled?). Use JSON Schema properties with descriptions.
Add confirmation step for destructive tools. delete and upsertJson should support a dry_run parameter or require explicit confirmation via a separate confirm_delete tool.
Constrain toolsMode 'mode' parameter to enum: {type: 'string', enum: ['full', 'search'], description: 'Injection mode: full (all tools available) or search (on-demand tool discovery)'}.

Score history

Overall score trend

First recorded score · v2 rubric

49/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	49	2026-07-28+	v2