Loading ToolBench

Reading the current corpus…

server MCP server · D · ToolBench

← Browse

server

github.com/vitemcp/server

A TypeScript framework for building stateless MCP servers — deploy to serverless and edge.

2026-07-28+STREAMABLE_HTTP5 tools

52/100

Definition Quality37

Protocol Readiness65

Supportability67

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

ViteMCP provides a framework for building MCP servers with HTTP transport and OAuth support. However, tool definitions are sparse and lack critical metadata. Only 1 of 5 tools has a visible input schema (greet with {name: string}). The remaining 4 tools (get-time, get-user-info x2, get-server-info) show empty input schemas {} with no parameter descriptions. Descriptions are present but minimal (10-50 chars), below the 50-200 char baseline for LLM optimization. No output schemas are documented. Tool naming follows verb_noun convention (get_*, greet) but lacks clarity on when to use similar tools (two get-user-info tools with identical names). Error handling, recovery guidance, and parameter constraints are not visible in the provided code samples.

Tools (5)

get-server-inforead onlysource verified35/100

Get information about this OAuth-enabled MCP server

get-timeread onlysource verified33/100

Get current timestamp

get-user-inforead onlyauthsource verified

Get user information (requires OAuth)

get-user-inforead onlyauthsource verified

Get user information from OAuth token

greetread onlysource verified60/100

Greet someone over HTTPS

Issues (5)

CRITICALtool-naming ↗

Duplicate tool names: two 'get-user-info' tools with identical names but different implementations (oauth-integrated-server.ts vs oauth-server.ts). LLMs cannot distinguish between them and will select arbitrarily.

get-user-info

CRITICALconstrained-input ↗

Four of five tools have empty input schemas ({}). No parameter descriptions, types, or constraints visible.

get-timeget-user-infoget-server-info

HIGHtool-description ↗

Tool descriptions are 10-50 characters, well below the 50-200 char baseline for LLM optimization. 'Get current timestamp' and 'Get user information (requires OAuth)' lack context on WHEN to use the tool, WHAT it returns, and any prerequisites beyond a bare statement.

get-timeget-user-infoget-server-info

HIGHresponse-shaper ↗

Recommendations

Rename duplicate 'get-user-info' tools to distinguish them: e.g., 'get-user-info-from-oauth-token' and 'get-user-info-from-integrated-oauth'. Tool names must be unique and self-documenting.
Add complete input schemas for all tools. For get-time and get-server-info (which take no params), explicitly document empty input: {type: 'object', properties: {}, required: []}. For get-user-info, add parameters like 'token_type' or 'scope' with descriptions and enums.
Expand tool descriptions to 50-200 characters. Example: 'Get current server timestamp in ISO 8601 format. Use this to verify server time synchronization or schedule future events. Returns timestamp and timezone offset.'
Document output schemas for each tool. Specify return fields, types, and whether results are paginated. Example for get-user-info: {type: 'object', properties: {user_id: {type: 'string'}, email: {type: 'string'}, ...}, required: ['user_id']}.
Add error handling guidance. For OAuth tools, document: 'If token is invalid or expired, the tool returns a 401 error. Retry after refreshing the token via the OAuth provider.' For all tools, include actionable recovery steps.

Spec posture evidence

Inferred effective spec: 2026-07-28+.

Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)

Score history

Overall score trend

First recorded score · v2 rubric

52/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	52	2026-07-28+	v2