Loading ToolBench

Reading the current corpus…

myvrworlds MCP server · F · ToolBench

myvrworlds

Express-based API server that bridges MCP clients to VRChat and Avatar MCP servers via stdio transport. Exposes MCP tool execution and server status endpoints.

2026-07-28+STREAMABLE_HTTP2 tools

35/100

Definition Quality35

Protocol Readiness35

SupportabilityNot measured-

Spec posture

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

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Both tools have minimal descriptions (under 100 chars) and lack proper input schema documentation. Tool names are verb-based but descriptions are vague about when/why to use them. No output schemas documented. No error handling guidance. Parameters lack type constraints (enums, ranges). This server exposes internal MCP client management as tools rather than domain-specific functionality, which is architecturally questionable for an agent interface.

Tools (2)

checkServerStatusread only45/100

Checks the online status and available tools count for a specified MCP server

getMCPClientread only42/100

Establishes or retrieves a cached MCP client connection to a specified server (vrchat or avatar) via stdio transport

Issues (5)

CRITICALtool ↗

No output schemas documented. LLMs cannot plan downstream calls or extract required fields. getMCPClient returns a client object (opaque to LLM); checkServerStatus returns {online, tools, error} but structure is not formally specified.

getMCPClientcheckServerStatus

HIGHconstrained-input ↗

Parameter 'serverName' lacks enum constraint. Description says 'vrchat or avatar' but no formal enum in schema. LLMs may hallucinate other server names, causing failures.

getMCPClientcheckServerStatus

HIGHtool-description ↗

Descriptions are too brief (under 100 chars) and lack context. 'Establishes or retrieves a cached MCP client' does not explain WHEN to call this vs checkServerStatus, or what the returned client object is used for.

getMCPClientcheckServerStatus

HIGHrecovery-guide ↗

No error handling guidance. If serverName is invalid or connection fails, LLM receives null or error but has no recovery path. Should return actionable error like 'Server not found. Available: vrchat, avatar'.

Recommendations

Add formal output schemas: getMCPClient should document that it returns {client_id: string, status: 'connected'|'failed', available_tools: string[]}. checkServerStatus should return {online: boolean, tool_count: number, error?: string}.
Convert serverName parameter to enum: {type: 'string', enum: ['vrchat', 'avatar'], description: 'MCP server to connect to. VRChat for VR social platform control; Avatar for avatar customization.'}
Expand descriptions to 100-200 chars with WHEN/WHY context: 'Establishes a persistent stdio connection to a specified MCP server (VRChat or Avatar). Call this before invoking server-specific tools. Returns a client ID for subsequent tool calls. Connections are cached per server.'
Add error handling: return {error: 'Invalid server name. Available: vrchat, avatar'} instead of null. Document in description: 'Returns error object if server not found or connection fails. Check error.message for recovery steps.'
Reconsider architecture: if this is a bridge server, expose the downstream tools (VRChat tools, Avatar tools) directly via this MCP server, not the client management layer. Agents should call 'send_vrchat_emote' not 'getMCPClient' then 'send_emote'.

Score history

Overall score trend

First recorded score · v2 rubric

35/100

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