LibreOffice MCP exhibits significant definition quality gaps. The primary tool 'libreoffice' is a portmanteau combining 8+ distinct operations (status, convert, merge, batch_pack, pdf_merge, watch_*, live_write, run_macro, bridge_call, help) into a single tool with a massive 30+ parameter schema. This violates the single-responsibility principle and forces LLMs to reason about which operation to invoke via a string enum. Parameter descriptions are present but often terse (10-30 chars). The two read-only tools (show_libreoffice_status_card, show_templates_card) have minimal schemas (empty input) and adequate descriptions. Overall, the server prioritizes feature breadth over clarity and composability.

• Split 'libreoffice' into separate tools: convert_document, merge_documents, batch_pack_markdown, pdf_merge, watch_folder, live_write_document, run_macro. Each tool should have one clear responsibility and verb-noun naming.
• Expand parameter descriptions to 50-200 chars. Include format constraints, valid ranges, and examples. E.g., 'output_format: Target document format (pdf, docx, odt, html, xlsx, csv). Default: pdf. Determines file extension and LibreOffice export filter.'
• Document output schemas for all tools. Specify returned fields, types, and pagination (if applicable). E.g., 'Returns {success: bool, output_path: str, file_size_bytes: int, conversion_time_sec: float}'.
• Add error handling guidance to tool descriptions. E.g., 'If LibreOffice is not found, ensure soffice is in PATH or set LIBREOFFICE_PATH env var. Call show_libreoffice_status_card to diagnose.'
• For 'libreoffice_writer' and 'libreoffice_calc', split operation dispatch into separate tools (e.g., writer_status, writer_live_write, writer_run_macro) so LLMs can compose them naturally without string-based operation selection.

Inferred effective spec: 2025-06-18+.

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API