live wire
▸Snowflake’s Cortex Agent quickstart routes metrics and transcripts with prompt rules—but documents no authorization boundarySnowflake▸Oracle Select AI generates SQL/PGQ for property graphs—but errors if one AI profile mixes graphs with tables or viewsOracle▸Domo’s data team standardizes MCP builds with shared scaffolding; beta toolkits inherit user permissionsDomo▸Databricks proposes five outcome signals for agentic BI—and says dashboard counts and license usage miss decision qualityDatabricks▸One vibe-coded database app needed 56+ human test hours and three repair rounds despite AI Studio’s verification claimsMancas & Mancas / arXiv▸BigQuery AI.IF’s default cost mode trains a local model for most rows—and drops row-error thresholdsGoogle Cloud▸AWS’s multi-tenant data-agent pattern gives the broker Lambda no data permissions; Cognito roles carry Lake Formation scopeAWS Big Data Blog▸Amazon OpenSearch’s optimized engine adds nested agent traces, but AWS reserves it for log analytics—not vector searchAWS▸Two interpretation-based provenance semantics cannot express SQL bag difference, new theorem showsKolaitis / arXiv▸Databricks Feature Views reuse one definition for training and live scoring, but online lookup still returns latest available stateDatabricks▸Databricks Genie’s Slack and Teams previews default channel answers to public, even when viewers lack source-data accessDatabricks▸Snowflake’s two-tool GraphRAG agent beat a seven-tool graph setup 70% to 60% on 22 ontology questionsSnowflake Engineering▸Semantix opens an Apache-2.0 semantic-first data-agent stack, but labels the project WIP and has no release or adoption yetGitHub / icosmos-space▸Confluent defines Streamhouse as shared current state for agents and apps, but says broader semantics and governance are still to comeConfluent▸Snowflake’s Cortex Agent quickstart routes metrics and transcripts with prompt rules—but documents no authorization boundarySnowflake▸Oracle Select AI generates SQL/PGQ for property graphs—but errors if one AI profile mixes graphs with tables or viewsOracle▸Domo’s data team standardizes MCP builds with shared scaffolding; beta toolkits inherit user permissionsDomo▸Databricks proposes five outcome signals for agentic BI—and says dashboard counts and license usage miss decision qualityDatabricks▸One vibe-coded database app needed 56+ human test hours and three repair rounds despite AI Studio’s verification claimsMancas & Mancas / arXiv▸BigQuery AI.IF’s default cost mode trains a local model for most rows—and drops row-error thresholdsGoogle Cloud▸AWS’s multi-tenant data-agent pattern gives the broker Lambda no data permissions; Cognito roles carry Lake Formation scopeAWS Big Data Blog▸Amazon OpenSearch’s optimized engine adds nested agent traces, but AWS reserves it for log analytics—not vector searchAWS▸Two interpretation-based provenance semantics cannot express SQL bag difference, new theorem showsKolaitis / arXiv▸Databricks Feature Views reuse one definition for training and live scoring, but online lookup still returns latest available stateDatabricks▸Databricks Genie’s Slack and Teams previews default channel answers to public, even when viewers lack source-data accessDatabricks▸Snowflake’s two-tool GraphRAG agent beat a seven-tool graph setup 70% to 60% on 22 ontology questionsSnowflake Engineering▸Semantix opens an Apache-2.0 semantic-first data-agent stack, but labels the project WIP and has no release or adoption yetGitHub / icosmos-space▸Confluent defines Streamhouse as shared current state for agents and apps, but says broader semantics and governance are still to comeConfluent
nl2sql.ai
newsMCP compatibility

GoodData’s MCP server stops advertising every tool up front

Tool search becomes the default on September 17, changing discovery behavior for clients that inspect tools/list before deciding what they can call.

MCP server discovery changes from full upfront listing to search-first access.
Side by side: what changed
By The News Desk· Sep 17, 2026the quick take — two AI hosts go live when you do

GoodData changed the default discovery behavior of its MCP server on September 17. Instead of returning every available capability in the initial MCP tool list, the server now exposes search_tools and call_tool as the primary discovery path. The underlying tools have not been removed and can still be invoked directly by name. GoodData release notes

The change matters most for integrations that treat tools/list as a complete capability inventory. GoodData explicitly warns that those integrations may need adjustment: clients should either search for the appropriate tool and then call it through call_tool, or invoke known tools directly by name. GoodData says off-the-shelf clients with tool-search support should continue working without changes. GoodData release notes

Why the tool list is changing

GoodData’s MCP documentation describes a split between always-on core tools and additional tools that clients discover on demand. Tool search matches a client’s intent against tool names and descriptions, allowing the server to offer a larger capability set without loading every definition into the initial exchange. The same discovery system applies to GoodData’s manually defined tools and generated wrappers for selected GoodData v1 API operations. GoodData MCP documentation

That design also creates a clear compatibility boundary. GoodData says clients without tool-search support see only the always-on core tools; dynamically generated tools are available only to clients that support discovery. In practice, a client may still establish an MCP connection while exposing only part of the server’s capability set. GoodData MCP documentation

The available surface is broader than conversational analytics alone. GoodData documents tools for workspace metadata, governed metric creation, data-source scanning and logical-model generation, alerts, scheduled exports, AI search, and execution of saved visualizations. Generated API tools are workspace-scoped and exclude PUT, PATCH, DELETE, action endpoints, and organization- or admin-scoped operations; they also enforce the permissions of the underlying GoodData API. GoodData MCP documentation

What operators should test

Teams running custom MCP clients should verify two separate behaviors: whether the client supports tool search, and whether any orchestration logic assumes that the first tools/list response is exhaustive. A successful connection is not enough to prove that all GoodData operations remain discoverable.

GoodData had already offered the new behavior through an Early Access setting called Extended MCP Tools. With the September 17 default now in effect, the practical migration check is straightforward: search for a non-core capability, call the returned tool, and separately test any direct-by-name calls the application depends on. GoodData release notes

sources

Filed by The News Desk. Corrections: desk@nl2sql.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk