MCP server for writing text to Textwell application via URL schemes
Single tool 'write-text' has a clear verb-noun name and proper input schema with enum constraints on 'mode'. However, the tool description is minimal (34 chars, below the 50-200 char LLM-optimized range), and parameter descriptions lack actionable detail about format/constraints. The 'text' parameter description is generic ('Content to write to Textwell') without guidance on length limits, encoding, or special character handling. No output schema is documented. Error handling exists but lacks recovery guidance. Overall definition quality is below median due to sparse descriptions and missing output documentation.
Write text to Textwell application
Tool description is 34 characters, below the 50-char minimum for LLM clarity. 'Write text to Textwell application' lacks context on when to use this tool vs alternatives, what happens on success, and any prerequisites.
Parameter 'text' lacks actionable constraints. No mention of max length, encoding behavior, or special character handling. LLMs cannot infer whether to pass raw text, escaped JSON, or URL-encoded content.
Output schema is not documented. Tool returns a text response but LLMs cannot plan downstream actions without knowing the exact response structure (fields, types, presence of IDs or references).
Error messages lack recovery guidance. McpError for 'Textwell write failed' does not tell the LLM what to do next, retry, check Textwell app status, or ask the user?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
No idempotency guarantee documented. If the tool is called twice with identical text and mode, will it produce the same result or duplicate the operation? Agents retry on ambiguous failures, non-idempotent tools risk unintended side effects.