Loading ToolBench
A Model Context Protocol server used to execute various application types with support for multi-turn conversations, message management, and integration with OpenRouter API for LLM interactions.
This MCP server has significant quality gaps across naming, descriptions, and schema completeness. Tool names lack verb prefixes (create-conversation, send-message use hyphens instead of underscores). Descriptions are present but minimal (10-50 chars, below the 194-char baseline for A+ tools). Parameter descriptions exist but are terse and lack context about constraints, formats, or when to use each tool. Input schemas are visible in the provided code but lack examples of output schema documentation. The server implements tools but does not follow Arcade's tool composition patterns for single responsibility. No evidence of error handling guidance, recovery paths, or actionable error messages beyond what MCP SDK provides by default.
Creates a new conversation with a specified model.
Sends a message to an existing conversation and receives a response.
Tool names use hyphens instead of verb_noun convention (create-conversation vs create_conversation). MCP SDK may normalize these, but the source code does not follow standard Arcade naming patterns. Verb-first names are critical for LLM discovery and intent inference.
Tool descriptions are under 20 characters and provide minimal context. 'Creates a new conversation with a specified model.' (62 chars) and 'Sends a message to an existing conversation and receives a response.' (71 chars) are below the 194-char baseline. They do not explain WHEN to use each tool, prerequisites, or state mutation implications. LLMs cannot reliably distinguish these from descriptions this sparse.
Parameter descriptions are terse and lack actionable constraints. 'The model ID to use for the conversation' does not explain: valid model values, format requirements, whether to use provider prefix (e.g., 'deepseek-chat'), or what happens if an invalid model is passed.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No enum constraints on the 'model' parameter. Free-form string invites hallucinated values. The config shows models are loaded from YAML (deepseek, etc.) but the tool schema does not expose valid options as an enum. LLMs must guess valid model names.
Output schemas are not documented in the tool definitions. The code snippet shows Conversation and Message types defined in src/types/conversation.ts, but tool descriptions do not specify what fields (id, createdAt, messages, etc.) the caller should expect from create-conversation or send-message.
No error handling guidance or recovery paths in tool descriptions. If create-conversation fails with 'Invalid model', the description does not hint at what to try next (e.g., 'Use resources/list to discover available models').
The 'stream' parameter in send-message is optional and boolean, but no description explains what streaming means, when to use it, or what format the streamed response takes. LLMs need explicit guidance on optional parameters to decide whether to include them.
No confirmation or dry-run pattern for destructive operations. The send-message tool mutates conversation state (appends messages). No evidence of this pattern in the schema.
Tool composition issue: create-conversation and send-message are tightly coupled. An agent cannot send a message without first creating a conversation. No batch variants for agents that might want to create multiple conversations or send multiple messages in one call. This forces N sequential tool invocations.