deepset-mcp
Official# deepset-mcp
**The official MCP server and Python SDK for the Haystack Enterprise Platform**
deepset-mcp enables AI agents to build and debug pipelines on the [Haystack Enterprise Platform](https://www.deepset.ai/products-and-services/deepset-ai-platform) through 45+ specialized tools. It also provides a Python SDK for programmatic access to many platform resources.
## Documentation
š **[View the full documentation](https://deepset-ai.github.io/deepset-mcp-server/)**
## Quick Links
- š **[Haystack Enterprise Platform](https://www.deepset.ai/products-and-services/deepset-ai-platform)**
- š **[Installation Guide](https://deepset-ai.github.io/deepset-mcp-server/installation/)**
- š ļø **[MCP Server Guide](https://deepset-ai.github.io/deepset-mcp-server/guides/mcp_server/)**
- š **[Python SDK Guide](https://deepset-ai.github.io/deepset-mcp-server/guides/api_sdk/)**
## Development
### Installation
Install the project using [uv](https://docs.astral.sh/uv/):
```bash
# Install uv first
pipx install uv
# Install project with all dependencies
uv sync --locked --all-extras --all-groups
```
### Local Development
If you want to test your changes locally, follow these steps:
1. Add a script run-deepset-mcp.sh that uses the binary from the project's virtual env
```bash
#!/usr/bin/env bash
# Wrapper to run the local deepset-mcp server for Cursor MCP.
# Use this as command so it doesn't depend on uv or PATH.
set -e
cd "$(dirname "$0")"
exec .venv/bin/deepset-mcp
```
2. Use it this way in Cursor:
```bash
"deepset": {
"command": "/bin/bash",
"args": ["/Users/*****/****/deepset-mcp-server/run-deepset-mcp.sh"],
"cwd": "/Users/*****/****/deepset-mcp-server",
"env": {
"DEEPSET_WORKSPACE": "WORKSPACE",
"DEEPSET_API_KEY": "API_KEY"
}
}
```
Note: If you change the codebase, make sure to restart the MCP server.
### Code Quality & Testing
Run code quality checks and tests using the Makefile:
```bash
# Install dependencies
make install
# Code quality
make lint # Run ruff linting
make format # Format code with ruff
make types # Run mypy type checking
# Testing
make test # Run unit tests (default)
make test-unit # Run unit tests only
make test-integration # Run integration tests
make test-all # Run all tests
# Clean up
make clean # Remove cache files
```
### Documentation
Documentation is built using [MkDocs](https://www.mkdocs.org/) with the Material theme:
- Configuration: `mkdocs.yml`
- Content: `docs/` directory
- Auto-generated API docs via [mkdocstrings](https://mkdocstrings.github.io/)
- Deployed via GitHub Pages (automated via GitHub Actions on push to main branch)
TDQS
Scored across 83 tools
Most tools target a clearly distinct resource+action, and the descriptions carefully distinguish subtle pairs (get_pipeline_logs vs get_pipeline_trace_logs, activate_deployment vs activate_deployment_revision). The main overlap is the search trio (search_pipeline, search_pipeline_with_params, search_pipeline_with_filters), where with_params also accepts filters, plus list_search_history vs list_pipeline_search_history and list_pipeline_traces overlapping in scope.
The set overwhelmingly follows a consistent verb_noun snake_case convention (list_, get_, create_, update_, delete_, search_, validate_, deploy_). Minor deviations exist in a handful of noun/tool-first names (yq_object_store, sed_object_store, grep_object_store, load_skill), but these are readable and don't undermine predictability.
83 tools is very heavy and exceeds the range where an agent can reliably select without help, even given the genuinely broad platform scope. Many fine-grained operations (per-revision, per-tag, per-cost-view) could be consolidated, making the surface hard to navigate.
Read/write coverage is broad across pipelines, deployments, indexes, workspaces, evaluations, costs, and docs, but delete/lifecycle operations are missing for several core resources (no delete_pipeline, delete_index, update/delete_workspace, and no create_secret despite get/list_secret). These gaps will cause dead ends for full CRUD workflows.