Databricks SQL
Aperçu
Cette fonctionnalité est en Aperçu public.
Le serveur MCP Databricks SQL est un serveur MCP géré par Databricks qui permet aux agents d’exécuter du SQL généré par IA sur vos tables Unity Catalog pour lire et écrire des données, avec un accès régi par les autorisations Unity Catalog. Les queries s’exécutent de manière asynchrone : l’agent appelle l’outil pour start une query, puis interroge jusqu’à ce que la réponse soit terminée.
Utilisez ce serveur pour le développement et le data engineering : exécution d'une query spécifique que vous ou votre agent de codage avez écrite, inspection des schémas, validation de la syntaxe SQL et création de pipelines de données à partir d'outils de codage IA. Cela vous donne un contrôle déterministe sur le SQL exact qui est exécuté.
Modèle d'URL | Champ d’application d’OAuth |
|---|---|
|
|
Serveurs MCP Genie One vs. Databricks SQL MCP
Pour les cas d'usage analytiques, lorsqu'un utilisateur pose une question métier en langage naturel, utilisez plutôt le serveur MCP Genie One. Genie résout les termes métier via Genie Ontology, votre couche sémantique gouvernée, ce qui permet de produire des réponses plus précises qu'un agent écrivant du SQL directement sur des tables brutes.
Utilisez le serveur MCP Databricks SQL lorsque vous devez exécuter une query spécifique que vous avez déjà écrite, par exemple pour valider la syntaxe ou créer un pipeline.
_meta parameter
_meta Les paramètres sont des valeurs de configuration que vous prédéfinissez dans le code de votre agent pour définir le comportement du serveur MCP de manière déterministe, plutôt que de laisser le LLM les générer dynamiquement au moment de l’appel d’outil. Le serveur MCP Databricks SQL prend en charge le parameter _meta suivant :
Nom du parameter | Type | Description |
|---|---|---|
|
| L’ID du SQL Warehouse à utiliser pour l’exécution des queries. Exemple : S’il n’est pas spécifié, le système sélectionne automatiquement un warehouse en fonction des ressources et des autorisations. |
Exemple : spécifier un SQL warehouse pour les requêtes Databricks SQL
Cet exemple montre comment utiliser le parameter warehouse_id _meta pour spécifier quel SQL Warehouse exécute les queries depuis le serveur Databricks SQL MCP à l’aide du SDK MCP Python officiel.
Dans ce scénario, vous souhaitez :
- Utilisez un SQL Warehouse spécifique pour l'exécution de la query au lieu de laisser le système en sélectionner un automatiquement
- Vérifiez la cohérence des performances en routant les query vers un warehouse dédié
Pour exécuter cet exemple, configurez votre environnement Python pour le développement MCP géré:
Pour trouver votre ID de SQL Warehouse, consultez Connect to a SQL warehouse.
# Import required libraries for MCP client and Databricks authentication
import asyncio
from databricks.sdk import WorkspaceClient
from databricks_mcp.oauth_provider import DatabricksOAuthClientProvider
from mcp.client.streamable_http import streamablehttp_client
from mcp.client.session import ClientSession
from mcp.types import CallToolRequest, CallToolResult
async def run_dbsql_tool_call_with_meta():
# Initialize Databricks workspace client for authentication
workspace_client = WorkspaceClient()
# Construct the MCP server URL for DBSQL
# Replace <workspace-hostname> with your workspace hostname
mcp_server_url = "https://<workspace-hostname>/api/2.0/mcp/sql"
# Establish connection to the MCP server with OAuth authentication
async with streamablehttp_client(
url=mcp_server_url,
auth=DatabricksOAuthClientProvider(workspace_client),
) as (read_stream, write_stream, _):
# Create an MCP session for making tool calls
async with ClientSession(read_stream, write_stream) as session:
# Initialize the session before making requests
await session.initialize()
# Create the tool call request with warehouse_id in _meta
request = CallToolRequest(
method="tools/call",
params={
# Tool name for executing SQL queries
"name": "execute_sql",
# Dynamic arguments - typically provided by your AI agent
"arguments": {
"query": "SELECT * FROM my_catalog.my_schema.my_table LIMIT 10"
},
# Meta parameters - specify which warehouse to use
"_meta": {
"warehouse_id": "a1b2c3d4e5f67890" # Your SQL warehouse ID
}
}
)
# Send the request and get the response
response = await session.send_request(request, CallToolResult)
return response
# Execute the async function and get results
response = asyncio.run(run_dbsql_tool_call_with_meta())
Limitations
- Aucun contexte sémantique. Le serveur exécute le SQL qui lui est fourni. Il ne résout pas les termes métier, les définitions de métriques ou les relations de table ; un agent doit donc les déduire uniquement à partir des schémas. Pour les questions d’analytique posées en langage naturel, utilisez le serveur MCP Genie One, qui base les réponses sur la Genie Ontology.
- Taille des résultats. Le serveur tronque les jeux de résultats volumineux dans les réponses des outils afin d'éviter d'épuiser la fenêtre de contexte du modèle. Renvoyez moins de lignes et de colonnes, ou effectuez une agrégation en SQL, pour maintenir les résultats dans la limite autorisée.
- Exécution asynchrone. Les queries ne renvoient pas de résultats de manière synchrone. L’agent start une query, puis interroge jusqu’à ce qu’elle soit terminée ; il doit donc gérer les états en cours.