Think of it as a bridge: your AI asks questions, this server translates them into Databricks API calls, and returns structured, AI-friendly responses.
Most database access work still happens through a UI a human drives. Bricks And Context MCP server moves it into the conversation instead. Think of it as a bridge: your AI asks questions, this server translates them into Databricks API calls, and returns structured, AI-friendly responses.
The server publishes 14 tools. What each one is for:
execute_sql_query — Run SQL with bounded, AI-safe outputdiscover_schemas — List all schemas in the workspacediscover_tables — List tables in a schema with metadatadescribe_table — Get column types, nullability, structureget_table_sample — Preview rows for data explorationconnection_health — Verify Databricks connectivitylist_jobs — List jobs with optional name filteringget_job_details — Full job config: schedule, cluster, tasksget_job_runs — Run history with state and durationtrigger_job — Start a job with optional parameterscancel_job_run — Stop a running jobget_job_run_output — Retrieve logs, errors, notebook outputConfiguration is passed through the environment: MCP_AUTH_PATH, MCP_CONFIG_PATH. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.
Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client. The configuration blocks on this page cover the common clients.
Plenty of database access servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Bricks And Context's toolset — execute_sql_query, discover_schemas, discover_tables and 11 more — is a fair guide to whether it matches your workflow. It is maintained by laraib-sidd; worth a glance at recent repository activity before you build anything load-bearing on it.
SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.
| Tool | What it does |
|---|---|
| execute_sql_query | Run SQL with bounded, AI-safe output |
| discover_schemas | List all schemas in the workspace |
| discover_tables | List tables in a schema with metadata |
| describe_table | Get column types, nullability, structure |
| get_table_sample | Preview rows for data exploration |
| connection_health | Verify Databricks connectivity |
| list_jobs | List jobs with optional name filtering |
| get_job_details | Full job config: schedule, cluster, tasks |
| get_job_runs | Run history with state and duration |
| trigger_job | Start a job with optional parameters |
| cancel_job_run | Stop a running job |
| get_job_run_output | Retrieve logs, errors, notebook output |
| cache_stats | Hit rates, memory usage, category breakdown |
| performance_stats | Operation latencies, error rates, health |
**Or using venv directly:**
```json
{
"mcpServers": {
"databricks": {
"command": "/path/to/bricks-and-context/.venv/bin/python",
"args": ["/path/to/bricks-and-context/run_mcp_server.py"],
"env": {
"MCP_AUTH_PATH": "/path/to/bricks-and-context/auth.yaml",
"MCP_CONFIG_PATH": "/path/to/bricks-and-context/config.json"
}
}
}
}Configuration as documented by the project. Restart the client after saving.
| Variable | Description | Required |
|---|---|---|
| MCP_AUTH_PATH | Filesystem location the server is allowed to use. | Optional |
| MCP_CONFIG_PATH | Filesystem location the server is allowed to use. | Optional |
Read-only SQL access to Postgres — let your assistant inspect schemas and answer questions from real data.
Manage your whole Supabase project in conversation — database, auth, storage, Edge Functions and branches.
Query, modify and analyse local SQLite databases in conversation — the fastest way to chat with a data file.
Metabase ships its own MCP endpoint — search your BI content, build and run queries, and save questions and dashboards without leaving the chat.
Official MongoDB server covering data, schemas and Atlas management — from find queries to spinning up clusters.
Serverless Postgres with database branching — point your assistant at Neon and let it work on disposable copies.