Loading ToolBench
An MCP server that saves AI conversations as structured Markdown files
Single tool 'save_chat_history' has minimal quality issues across multiple dimensions. Tool naming is adequate (verb-based), but descriptions lack depth and parameter quality is inconsistent. Input schema is present but incomplete, the 'messages' parameter lacks detailed structure documentation. No output schema is documented. No error handling guidance. This server demonstrates poor adherence to the 54 agentic tool patterns and production-grade baselines.
Save chat history as a Markdown file
Tool description lacks depth and context. Current description 'Save chat history as a Markdown file' is only 43 characters, below the 50-character baseline and missing WHEN to use, WHY, and WHAT constraints apply. No mention of file system side effects, directory creation, or disk space implications.
Input parameter 'messages' has no description of expected structure. Rubric requires: 'Every parameter needs a description explaining what it controls.' Current schema only states 'List of chat messages, each containing role and content', incomplete. No specification of valid 'role' values (e.g., enum: user, assistant, system?), required vs optional 'content' field, character limits, or message count bounds.
Parameter 'conversation_id' description is vague: 'Optional conversation ID for file naming' (50 chars). No specification of: format (UUID? slug? alphanumeric only?), length bounds, or how it affects filename generation when omitted. LLMs cannot infer constraints from name alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No output schema documented. Rubric states: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' Tool returns a string (success message), but this is not formally declared. No structured response fields, no error response format, no fallback guidance.
No error handling or recovery guidance. Tool writes to filesystem, operations can fail (permission denied, disk full, invalid path). No try-catch, no error categorization (retryable vs fatal), no actionable guidance for the agent. Rubric: 'Error responses must tell the LLM what to do next.'
No input validation. Tool accepts 'messages' array with no bounds checking. LLM could pass 10,000 messages, causing memory exhaustion or huge files. Rubric: 'Specify minimum and maximum for numeric parameters... Unbounded numbers let LLMs pass absurd values that break APIs or cause timeouts.' No per-message content length limit, no array size cap documented.
Parameter schema for 'messages' is incomplete. Declared as array type with description, but inner object schema is not defined. Should include: { type: 'object', properties: { role: { type: 'string', enum: ['user', 'assistant', 'system'] }, content: { type: 'string', minLength: 1 } }, required: ['role', 'content'] }. Current schema allows arbitrary structures.
No idempotency guarantee. Tool generates timestamped filenames, ensuring unique files per call, which is good. However, this is implicit, not documented. No discussion of what happens if the same conversation_id + timestamp collision occurs, or if the agent retries.
Security: No input sanitization against path traversal. If 'conversation_id' is '../../../etc/passwd', the tool could write outside the intended 'chat_logs' directory. Rubric: 'Treat all agent-provided input as untrusted. Sanitize against SQL injection, command injection, and path traversal.'