A minimal WebSocket-based MCP server implementation for a chatbot that handles tool calls and initialization requests
Single tool 'chat' has a basic description (72 chars, within range) but lacks critical depth. Input schema is present with two parameters (message, history) but descriptions are minimal and generic. No output schema documented. No error handling guidance, no parameter constraints (enums, ranges), no indication of idempotency or side effects. Tool does not follow verb_noun naming (should be 'send_message' or 'process_message'). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The implementation shows hardcoded responses and state mutation (message_history) but the tool definition does not document these behaviors or their implications for agent planning.
챗봇 도구 처리 - handles chat messages with optional history, returns text responses
Tool name 'chat' is generic and does not start with an action verb. Should be 'send_message', 'process_message', or 'query_chatbot' to clearly signal intent to the LLM.
Output schema is not documented. Tool returns {content, type} but LLMs cannot plan downstream calls without knowing the response structure. Document the full output schema with field types and descriptions.
Parameter descriptions are too generic. 'The user message to process' and 'Message history array (kept to last 10 messages)' lack actionable detail. Specify format, constraints, and examples: 'User message as plain text (1-2000 chars). Supports English and Korean.'
No error handling guidance. Tool can fail (e.g., invalid message format, processing timeout) but error responses do not tell the LLM what to do next. Add recovery hints: 'If message is empty, provide a non-empty string. If timeout occurs, retry with a shorter message.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | <=2025-11-25 | v2 |
Tool mutates server state (appends to message_history) but description does not declare this. LLMs cannot reason about side effects or idempotency. Clarify: 'This tool maintains conversation history on the server. Repeated calls with the same message will append duplicate entries.'