MCP server for document processing with SOW tools. Provides tools to parse, extract content from, and generate Word, Excel, and PowerPoint documents.
This server has significant quality gaps. While it provides 17 tools across document processing and Azure pricing domains, most tools suffer from incomplete schemas, vague or missing parameter descriptions, and no output schema documentation. The naming is generally acceptable (verb-noun format), but parameter quality is inconsistent. Many tools expose internal implementation details and lack clear recovery guidance on errors. The server would not pass code review by production standards.
Estimate monthly cost for an Azure resource based on service, SKU, region, and usage metrics.
Fetch and cache Azure retail prices for specified services and regions. Downloads pricing data from the Azure Retail Prices API and stores it locally for fast subsequent queries. Data is cached on disk for 24 hours.
List available Azure services for a given region and currency from cache or API.
Extract data from an Excel workbook. NOTE: This method is internal - use office_read() instead.
Convert Markdown tables to an Excel workbook from inline content or markdown_file. Parses GitHub Flavored Markdown content and extracts all tables. Each table becomes a separate sheet in the workbook.
Convert Excel sheets to Markdown tables. NOTE: This method is internal - use office_read(output_format='markdown') instead.
tool_office_patch has dangerously under-specified schema: 'changes' parameter is an array of objects with vague 'target' and 'value' fields. No enum constraints, no format documentation, no examples of valid target paths (cell reference? paragraph index? shape name?). LLMs will guess and fail.
Multiple tools export internal implementation details in descriptions: tool_excel_extract and tool_excel_to_markdown both say 'NOTE: This method is internal, use office_read() instead.' These should not be exposed as independent tools if they are internal. This creates confusion about which tool to call.
No output schemas documented. Every tool description fails to specify what fields and types the LLM should expect in the response. This forces LLMs to infer response structure, leading to parsing errors and failed downstream tool chains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
List document formats and features supported by the office tools (Word, Excel, PowerPoint).
Audit documents for unfilled placeholders, missing sections, and structure validation.
Add, list, or delete comments in documents (Word and PowerPoint).
Get contextual help for office tools based on a goal or scenario. Suggests appropriate tools and workflows.
Insert images into Word or PowerPoint documents.
Get document structure information (sections, tables, slides, sheets). Auto-detects document format.
Edit content in Word, Excel, or PowerPoint documents. Supports targeted edits to cells, placeholders, paragraphs, shapes, and sections.
Read content from Word, Excel, or PowerPoint documents. Auto-detects document format from file extension and extracts content in the requested output format.
Set default commenter identity for subsequent comment operations. Updates in-memory defaults used by office_comment and format-specific add-comment tools.
Add rows to tables in Word, Excel, or PowerPoint documents. Unified interface for table operations.
Inspect templates and copy/fill templates with placeholder replacement.
Parameter descriptions are too generic. E.g., tool_office_patch's 'target' field says 'What to edit', this is circular and tells LLMs nothing about valid syntax (cell addresses? shape IDs? paragraph numbers?). Same issue in tool_azure_estimate_resource 'usage' param: 'Usage metrics as key-value pairs', what keys? What units?
No error handling guidance. Tools do not document what happens on failure, what errors are retryable, or how an LLM should recover. E.g., tool_azure_fetch_prices can fail on network errors, invalid service names, or cache I/O issues, but the description provides zero guidance on what to do next.
Inconsistent parameter naming across related tools. tool_office_comment uses 'target' but tool_office_table also uses 'target', no clear definition of what target means in each context. tool_office_read uses 'output_format' enum but other tools do not follow this naming pattern for similar concepts.
tool_office_audit has a vague 'audit_type' parameter with no enum. Description says 'Type of audit to perform' but does not list valid audit types. LLMs will hallucinate values.
No pagination guidance. tools like tool_azure_list_services and tool_office_help return lists but do not document limits, offset parameters, or total_count fields. Large result sets will blow context windows.