Loading ToolBench
An MCP server for creating formatted RTF documents with TextEdit compatibility
Single tool with adequate basic structure but significant gaps in LLM-optimization and error handling. Schema is present and typed, but descriptions lack depth and parameter documentation is minimal. The tool name is clear (verb_noun: 'create_rtf_document'), but descriptions do not explain WHEN to use it, WHAT prerequisites exist, or HOW to recover from errors. No output schema documented. Error responses are generic. Security concern: no validation guidance for file paths (traversal risk). Composition is sound (single responsibility), but documentation fails to guide LLM usage effectively.
Create a formatted RTF document with TextEdit compatibility
Tool description too short and lacks context. At ~75 characters, it omits WHEN to call this tool, WHAT prerequisites exist (RTF software on client?), and how to recover if output_path is invalid. Baseline average is 194 chars; recommend 150-250 chars.
Output schema not documented. LLM does not know what fields to expect in response, forcing it to infer structure. Response hardcodes 'content' array with 'text' field, but this is not declared in a formal schema. Document: {type: 'object', properties: {success: {type: boolean}, path: {type: string}, message: {type: string}}}.
Parameter 'output_path' accepts free-form strings with no validation guidance. No mention of required directory existence, path traversal restrictions, or permission requirements. At risk of directory traversal attacks or silent failures if parent directory missing. Describe format: 'Absolute or relative path; parent directory must exist. Relative paths resolved from current working directory.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
Error handling does not guide LLM recovery. Response text 'Failed to create document: <message>' is unstructured. Per pattern:recovery-guide, error must state WHAT went wrong, WHICH tool to call next (if any), and whether the operation is retryable. Example: 'Output directory does not exist. Create it first or provide a different output_path.' or 'Permission denied writing to /path, try a different location.'
Parameter descriptions are minimal (40-65 chars vs baseline 72 chars). 'Document content with formatting markup', what markup? RTF native? HTML? Markdown? 'Path where the RTF file will be saved', absolute or relative? Must parent dir exist? Add constraints: 'Document content as plaintext or RTF markup (e.g., {\\rtf1\\ansi...}). If plaintext, auto-wrapped in RTF.'
No tool annotation metadata (readOnlyHint, destructiveHint, idempotentHint). This tool WRITES a file, making it destructive. Annotate: destructiveHint=true to signal to LLM that the call may overwrite existing files and requires user confirmation or careful intent verification.
No idempotency guidance. If LLM retries with same parameters, does it overwrite the file or error? Specify: 'If output_path already exists, the file is overwritten without warning.' Then add confirmation-request pattern or soft-fail guidance.
Template enum values lack descriptions. Enum ['business', 'technical', 'meeting', 'custom'] is present but descriptions of each template style missing. LLM cannot distinguish which template suits the user's intent. Add: enum with per-option docs or expand description to 'Template style: business (formal letterhead), technical (code-friendly fonts), meeting (agenda format), custom (no preset styling).'
No mention of supported RTF features or limitations. Does it support fonts, colors, tables, images? Does TextEdit on macOS reliably open all generated RTF? Expectations unclear. Add: 'Supports basic formatting: bold, italic, underline, fonts, line breaks. Does not support: embedded images, tables, hyperlinks. Compatible with macOS TextEdit and Microsoft Word.'