execute_sql_queryLABSCO SUMMARY
Bounded output is the feature, not a limitation.
A SELECT against a real warehouse can return more than any conversation can hold; the row, byte and cell limits mean a careless query fails usefully instead of burning the context window. Job runs are covered end to end, including reading the output of a run that failed.
What it is
A Python server for Databricks that puts SQL Warehouses and the Jobs API in front of an agent, with output limits so a wide result set does not flood the conversation. Multiple workspaces are configured at once and selected per call.
What you get
- execute_sql_query with configurable row, byte and cell limits, returned as markdown tables
- discover_schemas, discover_tables, describe_table and get_table_sample for finding your way around
- connection_health to check the workspace is reachable before anything else
- list_jobs, get_job_details, get_job_runs, trigger_job, cancel_job_run and get_job_run_output
- cache_stats and performance_stats — hit rates, operation latencies and error rates
- Retries and circuit breakers around the API calls
- Workspace switching by one parameter, so dev and prod are the same conversation
Requirements
Python 3.10 or later, installed with uv sync or pip install -e .. Workspaces are declared in an auth.yaml file — each with a host, a token and an HTTP path to a SQL warehouse — with one marked as the default.
Setup effort
Build from source — git clone https://github.com/laraib-sidd/bricks-and-context.git
USE CASES
01
Understanding a warehouse nobody documented
List the schemas, then the tables with their metadata, then the column types for the one you care about.
02
Answering a data question without opening a notebook
Sample a few rows to see the shape, then run the query with bounded output and read it as a table.
03
Finding out why last night's job failed
Read the run history for state and duration, then pull the logs and errors from the run that failed.
04
Rerunning a job against the right workspace
Trigger it with parameters, naming the workspace in the call so prod and dev do not get confused.
14 tools
Listed in project docs. Your client may show a different list.
discover_schemasdiscover_tablesdescribe_tableget_table_sampleconnection_healthlist_jobsget_job_detailsget_job_runstrigger_jobcancel_job_runget_job_run_outputcache_statsperformance_statsBEFORE YOU INSTALL
What to know first
Tools you get
14 tools named in the project's documentation.
Where it runs
Both documented setups run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
git clone https://github.com/laraib-sidd/bricks-and-context.git
cd bricks-and-context
uv sync # or: pip install -e .MCP Clients
Cursor — uv
CURSOR — UV · JSON
{
"mcpServers": {
"databricks": {
"command": "uv",
"args": [
"--directory",
"<YOUR_PATH_TO_BRICKS_AND_CONTEXT>",
"run",
"python",
"run_mcp_server.py"
],
"env": {
"MCP_AUTH_PATH": "<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/auth.yaml",
"MCP_CONFIG_PATH": "<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/config.json"
}
}
}
}Cursor — venv Python
CURSOR — VENV PYTHON · JSON
{
"mcpServers": {
"databricks": {
"command": "<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/.venv/bin/python",
"args": [
"<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/run_mcp_server.py"
],
"env": {
"MCP_AUTH_PATH": "<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/auth.yaml",
"MCP_CONFIG_PATH": "<YOUR_PATH_TO_BRICKS_AND_CONTEXT>/config.json"
}
}
}
}
