mcp-zabbix
# mcp-zabbix
> MCP server for Zabbix API - exposes all Zabbix API functionality via MCP
[](https://pypi.org/project/mcp-zabbix/)
[](https://pypi.org/project/mcp-zabbix/)
mcp-name: io.github.daedalus/mcp-zabbix
## Install
```bash
pip install mcp-zabbix
```
## Configuration
Set the following environment variables:
- `ZABBIX_URL` - Zabbix API URL (required)
- `ZABBIX_TOKEN` - API token (required, or use user/password)
- `ZABBIX_USER` - Zabbix username (optional)
- `ZABBIX_PASSWORD` - Zabbix password (optional)
## Usage
```python
from mcp_zabbix import mcp
mcp.run()
```
Or via CLI:
```bash
mcp-zabbix
```
## API
The MCP server exposes all Zabbix API methods as tools. Tools follow the pattern:
- `zabbix_<namespace>_<method>` (e.g., `zabbix_host_get`, `zabbix_host_create`)
## Development
```bash
git clone https://github.com/daedalus/mcp-zabbix.git
cd mcp-zabbix
pip install -e ".[test]"
# run tests
pytest
# format
ruff format src/ tests/
# lint
ruff check src/ tests/
# type check
mypy src/
```
TDQS
Scored across 262 tools
Every tool name combines a resource with an operation (e.g., zabbix_host_get, zabbix_graph_delete), so each tool is clearly distinct. No two tools appear to overlap in purpose.
All tools follow the identical zabbix_<entity>_<operation> pattern, making the set highly predictable and internally consistent.
With 262 tools, the set is far too large for an MCP server. This would overwhelm context windows and make tool selection impractical. Even the most comprehensive APIs rarely need this many distinct tool entries.
Coverage is uneven: many core Zabbix entities (action, alert, hostgroup, proxy, script, etc.) are missing, while obscure entities like dcheck/dhost are over-represented. The presence of 'exists' methods for only some resources also suggests arbitrary generation rather than deliberate API coverage.