excel-mcp-server
MCPExcel MCP Server for manipulating Excel files
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ~ | Complex nested types in formatting and chart tools may require schema simplification, Some tools have optional parameters with complex Dict types that may not translate cleanly to OpenAI function calling format, Tools with union types (str | None) need careful handling in schema translation, SSE transport preferred but stdio also works with OpenAI SDK |
| LangChain | ✓ | Tools maintain minimal state (file operations), which is compatible with LangChain's execution model, Some tools with complex Dict parameters may need custom serialization handlers |
Security findings
Path traversal vulnerability in file operations
The server accepts arbitrary file paths from clients without sanitization. In validation.py:17, data.py:22, formatting.py:81, and throughout, filepath arguments are passed directly to load_workbook() and file operations. An attacker could use paths like '../../../etc/passwd' to access files outside the intended directory. While SSE/HTTP modes have EXCEL_FILES_PATH, stdio mode (which is the recommended installation method per README) has no path restrictions.
Formula injection vulnerability
In calculations.py:28-30, user-supplied formulas are validated for syntax but not for malicious content. Excel formulas can execute commands via DDE or external references. The validation in validation.py:48-79 only checks syntax and cell references, not dangerous formula functions like HYPERLINK, WEBSERVICE, or external data connections. A malicious formula could potentially execute code when the Excel file is opened.
No authentication or authorization
The server exposes sensitive file operations over HTTP (SSE and streamable HTTP modes) without any authentication mechanism. As shown in __main__.py and server.py configuration, anyone who can reach the HTTP endpoint can read, write, modify, or delete Excel files within the configured directory. No API keys, tokens, or access controls are implemented.
Missing input length validation
Verbose error messages expose internal paths
No rate limiting on file operations
Reliability
Success rate
72%
Calls made
100
Avg latency
150ms
P95 latency
400ms
Failure modes
- • Missing file path handling: When EXCEL_FILES_PATH is not set for SSE/HTTP transports, server defaults to './excel_files' but doesn't validate directory exists or is writable
- • Incomplete error handling in file I/O: load_workbook() calls throughout codebase lack proper exception handling for corrupted files, permission errors, or file locks
- • Race conditions: No file locking mechanism - concurrent writes to same workbook will cause data corruption or crashes
- • Resource leaks: Some functions (read_excel_range, get_workbook_info) call wb.close() but others don't consistently close workbook handles, especially in error paths
- • Partial validation: Cell reference validation exists but edge cases like '$' symbols in references may not be fully handled (see cell_utils.py)
- • Empty data handling: Several functions (write_data, create_pivot_table) check for empty data but error messages may not be structured consistently
- • Range boundary issues: validate_range_bounds function referenced but implementation incomplete in provided code (validation.py truncated)
- • Chart creation failures: create_chart_in_sheet has extensive validation but may fail silently on unsupported chart configurations or invalid data ranges
- • Formula validation incomplete: validate_formula function referenced but not fully shown - regex-based cell reference extraction may miss complex formula patterns
- • Unicode and special character handling: No explicit encoding validation for cell values, formulas, or sheet names
- • Missing timeout protection: File I/O operations lack timeout mechanisms for large files or slow storage
- • Inconsistent exception hierarchy: Custom exceptions defined but not all functions use them consistently (some raise generic Exception)
- • Pivot table creation complexity: Complex data transformation logic with limited error recovery if intermediate steps fail
- • No rollback mechanism: Failed operations may leave workbook in partially modified state with no transaction support
- • Type coercion issues: Data validation functions convert types implicitly which may cause unexpected behavior with mixed-type data
Code health
License
MIT
Has tests
No
Has CI
No
Dependencies
4
Active project with good documentation and published to PyPI. Code is well-structured with proper error handling and logging. However, critical gaps include: no test files, no CI/CD pipeline, no type hints (despite Python 3.10+ requirement), and no CHANGELOG. The lockfile (uv.lock) is present and comprehensive. Dependencies are minimal and appear current (mcp, fastmcp, openpyxl, typer). License is clearly MIT. README is detailed with installation instructions and feature documentation. Without access to git history, cannot assess maintenance activity, but the version (0.1.7) and polished documentation suggest ongoing development. The absence of tests is the most significant quality concern for a tool handling file operations.