Loading ToolBench
MCP server that provides chat completion responses from OpenRouter for multiple models
Single tool with basic registration but significant quality gaps. Tool name lacks action verb convention. Input schema present but incomplete (missing 'required' array and description fields on parameters). Tool description is generic and lacks context on when/why to use it. No output schema documentation. No error handling guidance. No parameter descriptions. This server falls below baseline standards for production use.
Returns chat completion responses of given models from OpenRouter for the user message
Tool name 'user-chat-completion' does not follow verb_noun naming convention. Should start with action verb like 'get_', 'send_', or 'create_'. Current name is ambiguous about the primary action.
Input schema missing 'required' array. The schema buildJsonObject defines 'models' and 'user_message' but does not explicitly mark them as required in the JSON Schema, which could allow agents to omit critical parameters.
Parameter descriptions are entirely missing. 'models' and 'user_message' parameters have no descriptions explaining what values are expected, their format, or constraints.
No output schema documented. Tool returns TextContent with unstructured free-text response. LLMs cannot plan downstream operations or extract structured data without knowing the response format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
No error handling or recovery guidance. If OpenRouter API fails, returns generic error. LLM cannot determine if error is retryable, what the constraint violation was, or what to try next.
Tool description 'Returns chat completion responses of given models from OpenRouter for the user message' is generic and lacks context. Does not explain when to use it, what prerequisites exist (API key configuration), or how results differ from similar tools. Baseline tool descriptions are 194 chars on average; this is ~117 chars but lacks specificity.
API key 'openRouterApiKey' is hardcoded into the tool execution path via environment variable. While server-side injection is correct, there is no documentation of what API key format is expected, what scopes/permissions are required, or how the agent's call is authenticated and audited.
'models' parameter accepts arbitrary strings with no validation or enumeration. LLM can pass invalid model names, leading to silent failures from OpenRouter. Should either enumerate known models or document the exact format and validation rules.
Response structure is unstructured free-text ('Model: X, Response: Y, ---'). No structured object with typed fields. Agents must parse plain text to extract model names and responses, wasting tokens and inviting parsing errors.
No pagination or result limiting. If 'user_message' is ambiguous or returns many models, response could balloon unbounded. No limit parameter offered, no guidance on result caps.