Summary
Would the maintainers be open to a small addition to databricks_mcp that handles the query_space_{id} → poll_response_{id} state machine for Genie Space managed MCP servers? Today every consumer reimplements the same poll loop, and I'd like to contribute a shared helper — but I wanted to check direction before writing a PR.
Motivation
DatabricksMCPClient exposes call_tool / acall_tool at the MCP primitive level, which is the right shape for most managed MCP servers. Genie Space servers are a special case: the initial query_space_* call returns a pending status plus poll identifiers (conversation_id, message_id), and callers must then loop on poll_response_* until the status transitions to a terminal state.
very similar boilerplate shows up in:
Consolidating this would reduce duplication and give the Genie-over-MCP path a consistent response schema.
Proposed API (sketch, open to redesign)
from databricks_mcp import GenieSpaceClient # built on DatabricksMCPClient
client = GenieSpaceClient(
workspace_client=ws,
genie_space_id="...",
poll_interval_s=2,
poll_timeout_s=120,
)
response = await client.aquery("What were Q3 sales by region?")
# response.status, response.result_text, response.content (sql/table/text),
# response.conversation_id, response.message_id
Questions for maintainers
- Is this a direction you'd accept upstream, or would you prefer this live as a separate package that depends on databricks_mcp?
- If upstream, which module: databricks_mcp directly, or a new databricks_ai_bridge.genie submodule?
- Any constraints I should know about around the Genie API surface (e.g., fields expected to change)?
Happy to open a draft PR once there's directional alignment. I have a working implementation I can adapt.
Summary
Would the maintainers be open to a small addition to databricks_mcp that handles the query_space_{id} → poll_response_{id} state machine for Genie Space managed MCP servers? Today every consumer reimplements the same poll loop, and I'd like to contribute a shared helper — but I wanted to check direction before writing a PR.
Motivation
DatabricksMCPClient exposes call_tool / acall_tool at the MCP primitive level, which is the right shape for most managed MCP servers. Genie Space servers are a special case: the initial query_space_* call returns a pending status plus poll identifiers (conversation_id, message_id), and callers must then loop on poll_response_* until the status transitions to a terminal state.
very similar boilerplate shows up in:
Consolidating this would reduce duplication and give the Genie-over-MCP path a consistent response schema.
Proposed API (sketch, open to redesign)
Questions for maintainers
Happy to open a draft PR once there's directional alignment. I have a working implementation I can adapt.