The XLSX Reader MCP server provides two tools with reasonably well-structured schemas and descriptions. Both tools follow verb_noun naming conventions (read_xlsx, analyze_xlsx) and include comprehensive parameter documentation with types and constraints. However, there are significant gaps in output schema documentation, error handling guidance, and parameter descriptions lack sufficient detail to guide LLM invocations reliably. The server is domain-focused (read-only operations on Excel files) but lacks idempotency guarantees, recovery guidance, and explicit output structure declarations that would elevate it to production-grade quality.
Tools (2)
analyze_xlsxread onlysource verified74/100
Analyze Excel files to get detailed information about structure, data types, statistics, and sheet contents.
read_xlsxread onlysource verified77/100
Read and extract data from Excel (xlsx) files. Supports reading specific sheets, cell ranges, and converting data to various formats.
No output schemas documented for either tool. LLMs cannot know what fields to expect (e.g., does read_xlsx return {data: [...], rowCount: N} or {rows: [...], total: N}? Does analyze_xlsx return {sheets: [...], summary: {...}} or a flat object?). This forces LLMs to guess and breaks downstream tool chaining.
Parameter descriptions lack actionable constraints. 'maxRows: Maximum number of rows to return (default: 100, max: 1000)' appears in the schema but not in the description field. LLMs read descriptions, not schema internals. Parameter descriptions should include constraints inline: 'Maximum number of rows to return (1 - 1000; default 100). Larger values may timeout. Pair with pagination for large files.'
No error handling or recovery guidance. Code shows validation (file not found, invalid extension) but tool descriptions do not indicate what errors can occur or what the LLM should do next. E.g., 'If file not found, check file path. If extension is unsupported (.xls, .xlsm require additional parsing), use read_xlsx instead.' This guides agent recovery.
Inline all parameter constraints into descriptions. Replace schema-only docs with LLM-readable text: 'Maximum rows to retrieve (integer, 1 - 1000; default 100). Larger values slow retrieval and may timeout. Use pagination for files with >1000 rows.'
Add recovery guidance for common failure modes. E.g., 'If file not found, verify the path is absolute or relative to the MCP server's working directory. If Excel parsing fails with an unsupported extension (.xlsb), file format conversion is required outside this tool.'
Disambiguate searchColumn. Either split into three parameters (searchColumnLetter, searchColumnIndex, searchColumnName) or use a oneOf schema with proper type discrimination and descriptions.
Clarify what 'analyze' means. What data type categories are returned? (number, string, date, boolean, other?) Are null/empty cells counted? Does it infer data types or return observed types? Add to description: 'Classifies columns as: number, string, date, boolean, empty. Mixed-type columns are labeled by dominant type. Returns type distribution counts per column.'
read_xlsx searchColumn parameter overloads column identifiers. Accepts 'A' (letter), '1' (index), or 'Name' (header). This is flexible but ambiguous, an LLM might pass 'A' when the column header is actually 'Column A', causing silent mismatches. Provide separate parameters: searchColumnLetter, searchColumnIndex, searchColumnName, or use a discriminated union (oneOf in schema).
analyze_xlsx previewRows constraint (max: 20) is enforced in code but NOT in the parameter description. LLMs cannot see code, they only read descriptions and schema. Add to description: 'Number of rows to preview for data inspection (1 - 20; default 5).'
analyze_xlsx
Add pagination to read_xlsx for large sheets. Currently maxRows caps at 1000 absolute; this prevents reading files with >1000 rows. Add offset or startRow parameter: 'Starting row for retrieval (default 1). Pair with maxRows for pagination: first call with maxRows=1000, second with startRow=1001, maxRows=1000.'
Document idempotency guarantees. Both tools are read-only, so they are idempotent, state this explicitly: 'This tool is read-only and idempotent. Safe to retry with identical parameters.' This guides agent retry logic.
Specify timeout expectations. Large files may cause hanging. Add guidance: 'Large files (>10 MB) may take 30+ seconds to parse. MCP clients should set a 60-second timeout. If timeouts occur, try reading a smaller range or fewer sheets.'
Expand tool descriptions with use-case examples. E.g., 'read_xlsx: Extract revenue data from a monthly report to summarize quarterly totals. analyze_xlsx: Inspect a new data source to understand column types and data quality before automated processing.' This helps LLMs choose between the two.