Databricks MCP Proxy
# Databricks MCP Proxy
An MCP proxy server that authenticates with Databricks and exposes remote MCP tools.
## Installation
```bash
uv sync
```
## Configuration
Edit `app.yaml` with your Databricks settings:
```yaml
env:
- name: DATABRICKS_HOST
value: "https://dbc-XXXXX.cloud.databricks.com"
- name: DATABRICKS_APP_URL
value: "https://your-mcp-app.databricksapps.com"
```
## Usage
### Test locally
```bash
uv run databricks-mcp-proxy
```
### Claude Desktop Configuration
Add to `~/Library/Application Support/Claude/claude_desktop_config.json`:
```json
{
"mcpServers": {
"databricks": {
"command": "uv",
"args": [
"--directory", "/path/to/databricks-mcp-proxy",
"run",
"databricks-mcp-proxy"
]
}
}
}
```
## Tools
| Tool | Description |
|------|-------------|
| `authenticate` | Start OAuth flow (opens browser) |
| `list_databricks_tools` | List available remote tools |
| `call_databricks_tool` | Call a remote tool by name |
## Flow
1. Claude starts the proxy via stdio
2. Call `authenticate` tool
3. Browser opens for Databricks OAuth
4. After auth, remote tools are discovered
5. Use `call_databricks_tool` to invoke any remote tool
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: authenticate handles OAuth authorization, list_databricks_tools enumerates available remote tools, and call_databricks_tools executes those remote tools. There is no overlap or ambiguity between these three functions.
The naming follows a consistent snake_case pattern throughout (authenticate, call_databricks_tool, list_databricks_tools). However, there is a minor inconsistency: two tools use plural 'tools' while one uses singular 'tool', which slightly reduces perfect consistency.
With only 3 tools, this feels thin for a Databricks proxy server. While the tools cover authentication, discovery, and execution basics, the count is borderline minimal for a comprehensive proxy interface to a complex platform like Databricks.
The toolset provides a complete proxy workflow: authenticate to establish connection, list tools to discover capabilities, and call tools to execute operations. The only minor gap is that it relies entirely on the remote Databricks server for actual functionality, but as a proxy this is appropriate.