DocumentMCP has two tools with basic schemas and descriptions, but both suffer from significant quality gaps. Tool names are adequately action-oriented (read_*, edit_*), but descriptions lack depth and context about when to use each tool versus alternatives. Parameter descriptions are minimal. No documented output schemas. Error handling is present but not recovery-focused. The server implements prompts and resources as supplementary features, but tool definitions themselves are underdeveloped for production use.

• Expand read_doc_contents description to ~150 chars explaining: reads full document text, use before editing to verify content, returns a string. Add 'When to use: before calling edit_doc_contents to see current content.'
• Expand edit_doc_contents description to ~200 chars warning that it modifies state permanently, explaining the string replacement semantics, and recommending: 'Call read_doc_contents first to get exact text to replace. Match whitespace exactly (tabs, newlines count).'
• Document the return type for each tool: read_doc_contents returns {"content": string}, edit_doc_contents returns {"success": true, "updated_content": string}. Include examples.
• Add enum validation: convert doc_id from free-form string to an enum of {"deposition.md", "report.pdf", "financials.docx", "outlook.pdf", "plan.md", "spec.txt"} so LLMs know the valid set.
• Implement a dry-run mode for edit_doc_contents: add optional parameter 'dry_run: bool' (default false). When true, return the proposed changes without modifying the document. This lets agents preview changes before committing.
• Add recovery guidance to error responses: when doc_id not found, return 'Document "XXXX" not found. Available documents: [list]. Did you mean one of these?'
• Document idempotency: read_doc_contents is idempotent (safe to retry). edit_doc_contents is NOT idempotent if old_string appears multiple times, calling it twice will apply the replacement twice. State this clearly.
• Add parameter descriptions for old_string and new_string explaining how to handle special characters, multi-line text, and exact whitespace matching.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry