The Demo and the System: Implementing and Governing Natural-Language Query

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

Natural-language query is two different things that go by one name, and the one I have watched stood up at "a number of companies" is the one that cannot carry what is later put on it. Asked what a business has to have in place before it puts a question box in front of its data, I separated the two before I answered. The first needs almost nothing:

For a bare minimum MVP or PoC, however, the only thing that’s truly necessary is an LLM NLQ system tied into a data repository. I’ve seen this stood up at a number of companies as a ‘hey, look what we can do, now give us funding!’ PoC.

A model, a connection and a store of data. Nothing in that list is about the business. There is no agreement about what any of its words mean, no layer that writes such an agreement down, and no record of which customers are real. The demonstration works anyway, in the sense that it answers, because a current model will write plausible SQL against almost any schema it is shown. What it demonstrates is the model. It does not demonstrate that the organisation knows what its own numbers mean, and What the Model Cannot Infer set out last week why that knowledge has to come from somewhere other than the model. I will not argue that again. This piece takes it as settled and asks the two questions that follow from it: what has to be built to turn the demonstration into a system people can rely on, and what keeps that system trustworthy once everyone in the company can ask it things.

The distinction matters, because the demonstration and the system are not two points on one road. The demonstration is not an early version of the system. It skips the parts of the system that take longest to build and are hardest to see, and it is persuasive precisely because it skips them.

Why the demonstration gets built

It is cheap, and it is convincing in the room it is built for. A sentence goes in and a chart comes out, in front of the people who sign budgets. The interesting question is why so many organisations are building one now, and my own record has an answer that has little to do with natural-language query as such. Every project I see is now expected to show some AI in its deliverables, as evidence that it is in line with where the industry is heading. I have been in discussions about rationing master data management's own use of AI, because a programme that touches that many records would exhaust its token budget if it sent every one of them through a model. A project under that pressure needs something visible to point at, and a question box over a database is the quickest visible thing there is.

Gartner, writing about agentic AI rather than about query interfaces, describes the same pressure from the outside. Its analyst put it this way: "Most agentic AI projects right now are early stage experiments or proof of concepts", which are "mostly driven by hype and are often misapplied" [1]. That is a forecaster's characterisation, not a count, and it is about agents, but the mechanism it names is the one I am describing: experiments driven by hype.

The trouble is not that a proof of concept is built. I am in favour of proving things early. The trouble is what this one proves. What I have got sceptical funding bodies to accept as evidence of value is the results of proofs of concept that cut the effort of the people downstream; cutting a process from days to hours is the kind of result even a sceptic accepts. That is a claim about work, and it can be checked against the work. The funding demonstration makes a claim about capability and asks for money on its strength before anyone outside the demonstration has used it. It has not yet cut anyone's effort, because nobody has done their job with it.

It also inverts the one sequence I have seen work for a project that starts without a sponsor. The only projects I have seen gain one after they began were built by someone without the authority to start a project, on their own initiative, and almost always won the executive blessing only well after they were running in production and delivering value (Nobody Wins a Sponsor in Flight carries that argument). The funding demonstration asks for the blessing first and plans to perform later. RAND's interviews with 65 data scientists and engineers put the general version of this among the root causes of failed AI projects: in some cases a project fails because "the organization focuses more on using the latest and greatest technology than on solving real problems for its intended users" [2]. RAND's summary also repeats the estimate that "more than 80 percent of AI projects fail", which it attributes to other estimates rather than measuring itself [2], and I would not lean on the number. The root cause is the useful part.

Where the demonstration dies

In the same answer I described the ending I have watched:

It looks great on paper and gets the Executives all excited. However, it frequently dies when brought to the broader audience because the foundation was never laid properly and the costs skyrocket when every employee in the company is using it to help them write emails.

Two causes are in that answer, and they are different in kind. One is about meaning: the foundation was never laid. The other is about money: the costs rise because the audience changes what the tool is used for. A programme that fixes one and not the other still loses the system.

A disclosure first, because from here the argument assesses vendors' products. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on master data management being bought at all. That interest runs toward praise of the category, and it runs the same way as this piece's argument that a natural-language system needs mature master data underneath it: our revenue would like you to accept that argument. Weigh it below my criticism of the category, and weigh anything favourable I say about the category the same way. Profisee is aligned with Microsoft's data platform, so the same interest runs toward Microsoft's products; weigh what I say in their favour with that in mind. Snowflake, Databricks and Google sell data and analytics platforms that compete with Microsoft's, and Salesforce's Tableau competes with Power BI, which gives me a reason to be hard on all four; discount my criticism of them accordingly. dbt Labs sells the semantic layer whose documentation I cite, and has its own interest in how that layer is described.

The questions change

The executives in the demonstration ask the questions the demonstration was prepared for. The broader audience asks its own, in its own words, and those words are where the foundation shows. Microsoft's guidance for preparing a Power BI model for Copilot gives the standard example: "How are sales performing?" might refer to "revenue, order volume, growth, or margin", and the guidance tells the model's author: "Define a default interpretation, or instruct Copilot to ask for clarification" [3]. Somebody has to decide which. If nobody has, the model decides each time it is asked, and a demonstration built without agreed definitions has, by construction, nobody who decided. Last week's piece named the version of this that disqualifies an organisation outright: two groups each claiming one word, refusing either to standardise or to coexist. Put a model in front of that and it serves one group's meaning to the other.

The forecasters point at the same two causes I named. Gartner predicted in July 2024 that at least 30% of generative AI projects "will be abandoned after proof of concept by the end of 2025", and gave as reasons "poor data quality, inadequate risk controls, escalating costs or unclear business value" [4]. In February 2025 it predicted that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" [5]. Neither release publishes a method for its prediction, both are about AI projects in general rather than query interfaces, and a prediction is not a count. I cite them because the causes they list are the two in my answer, data first and cost second, and not because the percentages measure anything about natural-language query.

The meter does not know what the question was for

The second cause is the one budgets notice first. That the current question boxes are metered rather than licensed was the subject of The Vocabulary Outlived the Interface; the point here is narrower. Microsoft's billing documentation for Copilot in Fabric says: "Each Copilot interaction is metered by the number of tokens processed". It charges input at 100 capacity-unit seconds per thousand tokens and output at 400, and works an example in which one request of 2,000 input and 500 output tokens costs 400 capacity-unit seconds [6]. Snowflake prices its natural-language analyst the other way. "The credit rate usage for Cortex Analyst is based on the number of messages processed"; "Only successful responses (HTTP 200) are counted"; and unless it is invoked through Cortex Agents, "the number of tokens in each message does not affect cost", with warehouse charges on top when the generated SQL runs [7].

Those are two different shapes of bill, and they share one property. Neither asks what the question was for. A per-token meter charges every request by its tokens, whatever it asks. A per-message meter fixes what the analyst charges for each question (the warehouse still bills for running the SQL it writes) and leaves the number of questions to the audience. Either way, the total is set by volume, and volume is exactly what changes when the demonstration is opened to everyone. My observation about what the broad audience does with the box is the uncomfortable half of my answer. Most of the people who query data for a living already do it in SQL, Python, R or a spreadsheet, a point I have made before (The Vocabulary Outlived the Interface quotes it), so the conversational interface concentrates its analytical value on the executive floor. What the rest of the company brings to a box that will answer anything is everything else it needs help with.

The security community has a name for the extreme form of this. OWASP's list of risks for language-model applications calls it unbounded consumption, and its "denial of wallet" variant is an attacker "initiating a high volume of operations" to "exploit the cost-per-use model of cloud-based AI services" [8]. Nobody in a company is attacking its own budget, but the controls OWASP recommends do not care about intent: "rate limiting and user quotas", and monitoring "to detect and respond to unusual patterns of resource consumption" [8]. A company that tells every employee to use AI to be more productive will get, as I have said before, an explosion in usage and the token burn that goes with it (Ideally, Nothing). The demonstration had no need of those controls, because its audience was the executive suite.

The bare minimum, part by part

From here the argument rests on my own record more than on anything measured: what I count as the minimum for the system, and what each part of it asks of the people who build it.

The answer I have been quoting opened with the minimum, in one sentence that names a Model Context Protocol (MCP) server:

I’ve already suggested what I would consider to be the bare minimum to have a quality system—full agreement on definitions and a properly populated MCP server with a valid and approved semantic model on top of a mature MDM system.

Read from the bottom, because "on top of" gives the order. Mature master data is the floor. On it sits a semantic model that is valid and approved. Full agreement on definitions is what makes approval possible, and it has to exist before anyone can approve anything. And a properly populated MCP server is how the approved model reaches whatever asks it a question. Four parts, and the demonstration had none of them.

"Bare minimum" is a floor, not a plan. Each part below takes work that a demonstration never asks for, and most of it is not technical in the way a demonstration is.

Mature master data underneath

The chain I gave last week puts the semantic layer over master data, with reporting and AI reading at the same end of it, and that piece carries the argument for the order (What the Model Cannot Infer). The word that this answer adds is "mature", and the answer does not define it. The chain supplies a narrow test, and it is this article's reading rather than a definition I gave: mastering is mature for this purpose when the records the semantic model counts are the records the business recognises: the count of active customers that comes back from the model is the count the mastered data gives, not the sum of three source systems' copies. A mastering project still in flight fails that test however good its design, because the model is being defined over records nobody has finished deciding about.

There is a second, smaller reason that runs the same way. I have argued that de-duplication and mastering applied at source and in batch reduce the volume of records that reach any downstream AI process, and so the tokens it burns. In a query interface the effect is weaker, because the model writes a query instead of reading every record, but wherever a model summarises the rows a query returns, fewer duplicates means fewer rows to read.

Agreement on definitions, in full

"Full agreement" reads at first as if every word must have one meaning. Read with the readiness tell from last week, it need not. Two definitions of customer, each named for what it is and reconciled with the other, are agreed: everyone knows which is which, and the semantic model can carry both under their names. What is not agreed is a word that two groups each claim for their own definition. The minimum is that no such word remains in anything the system's audience can ask it, and an audience of the whole company asks, in its own words, about the whole business.

When the groups will not agree, I have said who settles it: the person who holds the authority and can enforce it decides, and the others live with the decision (Rules of Decreasing Strictness and What the Model Cannot Infer both carry that answer). For an implementer the practical consequence is scheduling. In this article's reading it is the item with the longest lead time in the stack, and the semantic model cannot be finished before it is. Microsoft's own guidance makes the same demand in different words: for each question users commonly ask, "define the expected measure, grouping, date basis, filters, and validated result" [3]. Every item in that list is a business decision, and the guidance assumes someone has already made it.

A semantic model that is valid, and approved

Asked, well before this piece, whether semantic layers solve problems or create them, I put the weight on how they are built:

Whether they solve or create problems is entirely down to how well they are implemented and how complex the transformations they are asked to incorporate. They only really cause problems when they provide conflicting information to downstream consumers who compare notes — assuming they are implemented properly according to the documented business rules, which is another source of fun.

The last clause is the one that matters for governance, and it contains two separate tests: "assuming they are implemented properly according to the documented business rules". Valid means the model does what the documented rules say, and that is only testable if the rules were documented, documented correctly, and read by whoever built the model. Approved means someone with the authority to say so has said that the model encodes the business's decisions and not the builder's guesses. The first is a test of the build. The second is a test of the organisation, and it fails for the reason the previous section gave: nobody can approve a model whose definitions are still contested.

The vendors now ship ways to record both, and they are worth using because they put a name and a date on approval. Snowflake's verified query repository holds "a collection of questions and corresponding SQL queries to answer them", which Cortex Analyst "leverages ... when answering similar questions", and each entry can record who verified it and when, in fields the documentation marks optional [9]. Its suggestion feature proposes new verified queries "based on user behavior" [9], which is useful and is not verification: a suggestion becomes an approved answer only when a person signs it. Power BI lets an author mark a semantic model "approved for Copilot", after which "the standalone Copilot agent doesn't apply any friction treatment to answers from that model" [10]. Databricks' benchmarks let an author "create a set of test questions that you can run to assess Genie's overall response accuracy", compared against a provided SQL answer in one mode and graded by an "LLM judge" in another, and recommend "between two and four phrasings of the same question" [11].

None of those decides who should approve. They record approval; the organisation still has to say whose it is. And approving a model does not approve every answer drawn from it. Microsoft says plainly that its preparation features "can't ensure a specific output every time. AI behavior is nondeterministic" [10]. So validity is not established once. It is a test set that is run, and run again.

That test set is the part I would write first. Asked once how I would approach decision intelligence, I said I would name the success and failure metrics before tracking anything and build backwards from the output, much as test-driven design does (More Coherent Either Way carries that answer). The same discipline fits here. For a natural-language system the output is a list: the questions the business will ask, each with the answer it should get and the phrasings people will use to ask it. Written before the model is built, that list is the definition of done. Written after, it is a description of whatever the model happened to do.

An MCP server, properly populated

Where MCP came from. MCP is an open protocol that Anthropic introduced in November 2024 as "a new standard for connecting AI assistants to the systems where data lives" [12]. A disclosure belongs beside that: Anthropic's model, Claude, helps draft this publication, so weigh what this piece says in the protocol's favour with that in mind. Anthropic laid the groundwork, and much of the industry has since adopted it: OpenAI's Agents SDK and Microsoft's Copilot Studio both connect to MCP servers [28][29], and when Anthropic contributed the protocol to the Linux Foundation's new Agentic AI Foundation in December 2025, the foundation's release could say it had "been adopted by Claude, Cursor, Microsoft Copilot, Gemini, VS Code, ChatGPT and other popular AI platforms" [30]. That adoption is why the protocol matters to this argument: the assistants a broad audience is likely to use were already on that list, so the server is where what they can reach gets decided.

MCP's specification defines hosts (the applications a person uses), clients inside them, and servers that offer three kinds of thing: resources, prompts and tools, the last defined as "Functions for the AI model to execute" [13]. For a semantic model, MCP is a way for one approved model to be served to every agent and assistant in the company without each of them being wired to it separately.

The vendors have built the servers. dbt Labs' MCP server exposes its Semantic Layer through tools including list_metrics ("Retrieves all defined metrics.") and query_metrics [14], and dbt says the server "ensures consistent, governed access to models, metrics, lineage, and freshness across your AI tools" [15]. Snowflake's managed server can "serve Cortex Analyst, Cortex Search, and Cortex Agents as tools" [16]. Databricks provides managed servers in its system.ai schema; the documentation's description of one reads: "Answers questions with Genie One, grounded in Genie Ontology" [17]. Microsoft documents an authoring server that reads and writes Power BI semantic models, and names Fabric IQ as the consumption layer that "answers natural language questions grounded in your semantic models and ontologies" [18]. Google documents using Looker's semantic layer, through its MCP toolbox, to give its Gemini command-line agent "secure, governed, and on-demand access to trusted data" [19], and Tableau publishes what it calls "Tableau's official MCP Server" [20].

"Properly populated" is the phrase that turns that list into a requirement. The answer does not define it either, and the reading this article takes is built from the vendors' own tool lists. The same servers that offer the governed semantic tools offer, beside them, tools that reach the tables without passing through the model. Snowflake's managed server lists "SQL execution" alongside Cortex Analyst [16]. Databricks lists, next to Genie One, a server that "Runs specific SQL queries for development and data engineering on a SQL warehouse, using the caller's Unity Catalog and warehouse permissions" [17]. Both are governed for access: Snowflake grants each tool separately [16], and Databricks runs the query under the caller's own permissions. What neither passes through is the approved model. Those are legitimate tools for the people who build the model. Exposed to the broad audience's agents, they are the separate road from the AI system to the tables that last week's chain says should not exist, and nothing obliges a model that can choose between the approved metric and its own SQL to choose the metric. A properly populated server, for the broad audience, offers the approved model's tools and nothing that routes around them. OWASP's guidance on excessive agency says the same in general terms: "Limit the extensions that LLM agents are allowed to call to only the minimum necessary" [21].

Properly populated also means the server acts as the right person. The query the agent runs should run as the person asking, with that person's permissions. OWASP asks that actions be "executed ... in the context of that specific user, and with the minimum privileges necessary" [21], and the MCP specification forbids a server from passing a client's token straight through to the system behind it: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" [22]. The vendor pages show how easily this goes wrong. Microsoft's documentation for its earlier remote Power BI server warns: "Row-level security (RLS): Currently not enforced when using Service Principal authentication." A service principal, it adds, "has access to all data the principal is authorized to access" [23]. Microsoft says the current consumption layer, Fabric IQ, "respects the permissions, row-level security, and object-level security already defined on those models" [18]. The same overview puts the general point in one line: "An MCP server doesn't expand data access, but it does move data" [18]. One of the two roles that can call Snowflake's analyst, CORTEX_USER, "is granted to the PUBLIC role" by default [7], which is a default someone has to decide about. Databricks lists the Genie space endpoint under legacy endpoints that "bypass Unity Gateway" and "do not support MCP-level Unity Catalog grants, policies, or guardrails", though access to them is still "controlled by permissions on the underlying resources" [17]. Each of those is a sentence in a vendor's documentation. In a deployment, each is a decision that has to be made on purpose.

Nor is the protocol itself settled ground. Radosevich and Halloran showed that "the current MCP design carries a wide range of security risks for end-users", including leading models being coerced through MCP tools into compromising a developer's system by running malicious code and stealing credentials [24], and Microsoft advises a security review of any system that integrates with its MCP servers because "MCP is a new standard" [18]. The protocol is the replaceable part of the requirement. If it were superseded tomorrow, the function would remain: one approved model, served through one governed route, to everything that asks.

Can it go live on part of the layer?

The strongest objection to all of this comes from the vendors' own build guidance, and it sounds like permission to skip most of it. Databricks tells authors to "start as small as possible, with minimal instructions and a limited set of questions to answer" ("Aim for five or fewer tables"), and to refine "over time, rather than aiming for perfection initially" [25]. Microsoft's guidance reads: "Start with questions about totals, comparisons, rankings, and trends that the semantic model supports. Add more complex questions after Copilot answers the initial set consistently" [3]. Read quickly, that is a recipe for going live on whatever part of the semantic layer is defined and growing it in production.

That question was put to me directly: is a complete semantic layer the gate, or can a system go live on a partial one? My answer was the two tiers above, and it offered no third. I hold to that, and the vendor guidance, read slowly, does not contradict it. It is advice about how to build and test. Databricks' page says: "You should be your agent's first user." And: "Keep testing and editing until you're getting reliable responses" [25]. It also says an agent "should answer questions for a particular topic and audience, not general questions across various domains" [25]. None of those pages advises releasing a partly defined model to every employee and finishing it later. Snowflake's modelling guidance draws the line itself. It says to "begin with 5–10 tables for an initial proof of concept to keep debugging manageable", and it keeps a separate "Production-ready checklist" whose testing items are "recommended before deployment", the first of them "An evaluation set has been created." [26]

And starting small cannot shrink the foundation. Five tables are not where it lives. The records they count are mastered, or not, for the whole organisation, and the definitions they encode have to hold for every word the eventual audience can ask, which, once the box is opened to everyone, is the whole company asking about the whole business. A small pilot inherits whatever state the organisation is in. A narrow pilot over a foundation that was never laid is still the first tier, however carefully its tables were chosen. Build small, by all means; it is good advice for building. What the minimum rules out is opening that part-built model to the whole company with a plan to finish it in production, which is the demonstration with a launch date.

Keeping it approved

Governing a natural-language system after it goes live is mostly a matter of keeping the four parts true while the business changes underneath them. Five things do most of that work.

A change to a definition reopens approval. When the decider changes what a word means, every verified question that used the word is stale, and the record of who verified it and when, made mandatory by policy because the vendor leaves it optional, is how you find them [9]. A definition change that does not trigger re-verification turns an approved model back into a guessed one without anyone noticing.

The test set runs on every change. A new table, a new measure, a changed relationship, a new model version from the vendor: each is a reason to run the questions again, with several phrasings of each, because the same input does not always produce the same output [10][11]. The test set is the only instrument that says whether the system still does what it was approved to do.

A token budget, validated before the broad release. The question I would ask of any AI roadmap is whether it carries a budget for tokens and a phase, before full implementation, that validates that budget (Reinforce Is the Wrong Word carries it). For a question box that phase is a limited release to a real cross-section of the company, metered, with OWASP's quotas and monitoring in place [8], so that the cost of the broad audience is measured before it is incurred. And keep the box to its job. A system that offers only the approved model's tools is not a writing assistant, and if the company wants a writing assistant, it should buy one as such and meter it on its own line, where its cost can be seen and argued about.

The agent acts as the person asking. Permissions, row-level security and least-privilege scopes belong to the person, not to a service account that can see everything [23][22]. The MCP specification's own security guidance lists "wildcard or omnibus scopes" among the common mistakes [22].

The interface will be replaced, and the governed parts should not care. Microsoft is retiring Power BI's Q&A in February 2027, after which "existing reports that contain Q&A visuals will display an error in place of the visual", and one of the replacements it names is its prep-data-for-AI features [27]. The definitions, the approved model and the mastered records outlast every question box built on them; The Vocabulary Outlived the Interface traced that across fifty years. A governed server between the model and its readers is what lets the next box be plugged in without approving everything again.

What the demonstration was demonstrating

The funding demonstration is not worthless. It gets attention, and attention is how projects get started. But it demonstrates the model's fluency, and fluency was never the scarce part. What the broad audience needs is the business's own decisions: which records are real, what each word means and who said so, which answers have been checked, and one route by which every agent reaches them. None of that is in the demonstration, and all of it is in the minimum.

Implementing natural-language query, then, is mostly building the things underneath the model, in the order the minimum gives them, and governing it is mostly keeping those decisions current and the route to them single. Fund the demonstration if it is the only way to get the conversation started. Spend the money it raises on the foundation, and let the rest of the company meet the system, not the demonstration.

References

[1] Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," press release, 25 June 2025 (Anushree Verma quoted). Read 2026-10-12. A prediction about agentic AI; cited only for the analyst's characterisation quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[2] James Ryseff, Brandon F. De Bruhl and Sydne J. Newberry, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI," RAND, RR-A2680-1, 13 August 2024. Read in full 2026-10-13 (the report PDF). Interviews with 65 data scientists and engineers. Cited for the root cause quoted in the body; the "more than 80 percent" figure is attributed by RAND to other estimates and is not relied on. https://www.rand.org/pubs/research_reports/RRA2680-1.html

[3] Microsoft, "Optimize your semantic model for Copilot in Power BI," Power BI documentation, Microsoft Learn, updated 29 September 2026. Read 2026-10-12. Vendor documentation (Microsoft is aligned with our partner). Cited for the passages quoted in the body. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-evaluate-data

[4] Gartner, "Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025," press release, 29 July 2024 (Rita Sallam). Read 2026-10-12. A prediction; the release states no method. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

[5] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," press release, 26 February 2025 (Roxane Edjlali). Read 2026-10-12. Cited only for the prediction quoted in the body; the release's survey figure is not used, because the page gives two different sample sizes for it. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

[6] Microsoft, "Copilot consumption, usage, and billing in Fabric," Microsoft Learn, updated 11 June 2026. Read 2026-10-12. Vendor documentation. Cited for the metering sentence, the per-thousand-token rates and the worked example. https://learn.microsoft.com/en-us/fabric/fundamentals/copilot-fabric-consumption

[7] Snowflake, "Cortex Analyst," Snowflake documentation. Read 2026-10-12 (cost considerations and access control). Vendor documentation. Cited for the billing passages and the default role grant. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst

[8] OWASP GenAI Security Project, "LLM10:2025 Unbounded Consumption," OWASP Top 10 for LLM Applications 2025. Read 2026-10-12. Cited for the denial-of-wallet description and the mitigations quoted in the body. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/

[9] Snowflake, "Cortex Analyst Verified Query Repository," Snowflake documentation. Read 2026-10-12. Vendor documentation. Cited for the repository's description, its verified-by and verified-at fields and the suggestion feature. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst/verified-query-repository

[10] Microsoft, "Prepare your data for AI to improve Copilot results (preview)," Power BI documentation, Microsoft Learn, updated 30 May 2026. Read 2026-10-12. Vendor documentation. Cited for "approved for Copilot" and the nondeterminism passage. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai

[11] Databricks, "Test and monitor a Genie Agent," Databricks documentation, updated 17 September 2026. Read 2026-10-12. Vendor documentation. Cited for the description of benchmarks, the two grading modes and the phrasing recommendation. https://docs.databricks.com/aws/en/genie/benchmarks

[12] Anthropic, "Introducing the Model Context Protocol," 25 November 2024. Read 2026-10-12. Cited for the date and the sentence quoted in the body. https://www.anthropic.com/news/model-context-protocol

[13] Model Context Protocol, "Specification" (current version; schema 2026-07-28). Read 2026-10-12. Cited for the definitions of hosts, clients, servers and server features quoted in the body. https://modelcontextprotocol.io/specification/latest

[14] dbt Labs, "Available tools" (dbt MCP server), dbt Developer Hub, updated 12 October 2026. Read 2026-10-12 (the Semantic Layer tools). Vendor documentation. https://docs.getdbt.com/docs/dbt-ai/mcp-available-tools

[15] dbt Labs, "dbt Model Context Protocol server," dbt Developer Hub, updated 23 July 2026. Read 2026-10-12. Vendor documentation (dbt Labs sells the Semantic Layer it describes). https://docs.getdbt.com/docs/dbt-ai/about-mcp

[16] Snowflake, "Snowflake-managed MCP server," Snowflake documentation. Read 2026-10-12. Vendor documentation. Cited for the tools the server can serve and the two access-control passages. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp

[17] Databricks, "Databricks-provided MCPs," Databricks documentation, updated 8 October 2026. Read 2026-10-12. Vendor documentation. Cited for the system.ai servers quoted and the legacy Genie space endpoint's limits. https://docs.databricks.com/aws/en/generative-ai/mcp/managed-mcp

[18] Microsoft, "Power BI MCP servers overview," Power BI documentation, Microsoft Learn, updated 24 September 2026. Read 2026-10-12. Vendor documentation. Cited for Fabric IQ, the authoring server, and the security passages quoted in the body. https://learn.microsoft.com/en-us/power-bi/developer/mcp/mcp-servers-overview

[19] Google Cloud, "Use the MCP Toolbox for Databases," Looker documentation, undated. Read 2026-10-12. Vendor documentation. Cited for the sentence quoted in the body. https://docs.cloud.google.com/looker/docs/connect-ide-to-looker-using-mcp-toolbox

[20] Tableau (Salesforce), "tableau-mcp," GitHub repository (About description). Read 2026-10-12. Vendor repository; cited only for the existence of Tableau's official MCP server ("Tableau's official MCP Server"). https://github.com/tableau/tableau-mcp

[21] OWASP GenAI Security Project, "LLM06:2025 Excessive Agency," OWASP Top 10 for LLM Applications 2025. Read 2026-10-12. Cited for the two mitigations quoted in the body. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

[22] Model Context Protocol, "Security Best Practices," specification (current version). Read 2026-10-12. Cited for the token-passthrough requirement and the scope mistakes quoted in the body. https://modelcontextprotocol.io/specification/latest/basic/security_best_practices

[23] Microsoft, "Remote Power BI MCP server tools," Power BI documentation, Microsoft Learn, updated 13 May 2026. Read 2026-10-12. Vendor documentation for the earlier consumption server, which [18] says is still documented for existing integrations. Cited for the service-principal row-level security warning. https://learn.microsoft.com/en-us/power-bi/developer/mcp/remote-mcp-server-tools

[24] Brandon Radosevich and John Halloran, "MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits," arXiv:2504.03767, 2 April 2025. Read in full 2026-10-13 (the arXiv PDF and HTML editions). Cited for the phrase quoted in the body and the findings summarised beside it. https://arxiv.org/abs/2504.03767

[25] Databricks, "Curate an effective Genie Agent," Databricks documentation, updated 11 September 2026. Read 2026-10-12. Vendor documentation. Cited for the build guidance quoted in the body. https://docs.databricks.com/aws/en/genie/best-practices

[26] Snowflake, "Best practices for modeling semantic views," Snowflake documentation. Read 2026-10-12. Vendor documentation. Cited for the proof-of-concept sizing advice and the production-ready checklist quoted in the body. https://docs.snowflake.com/user-guide/views-semantic/best-practices-modeling

[27] Mohammad Ali (Power BI team), "Power BI Q&A retirement reminder: February 2027 timeline update," Microsoft Fabric Community blog, September 2026. Read 2026-10-12. Vendor post. Cited for the retirement date, the passage quoted and the named replacements. https://community.fabric.microsoft.com/blog/fbc_pbiupdatesblog/power-bi-qa-retirement-reminder-february-2027-timeline-update/5365841

[28] OpenAI, "Model context protocol (MCP)," OpenAI Agents SDK (Python) documentation, undated. Read 2026-10-13. Vendor documentation. Cited for the SDK's MCP support ("The Agents Python SDK understands multiple MCP transports."). https://openai.github.io/openai-agents-python/mcp/

[29] Microsoft, "Extend your agent with Model Context Protocol," Copilot Studio documentation, Microsoft Learn, updated 26 August 2026. Read 2026-10-13. Vendor documentation (Microsoft is aligned with our partner). Cited for Copilot Studio's MCP support ("Copilot Studio currently supports MCP tools and resources."). https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp

[30] Linux Foundation, "Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF), Anchored by New Project Contributions ...," press release, 9 December 2025. Read 2026-10-13. Cited for Anthropic's contribution of MCP to the foundation and the adoption sentence quoted in the body; the release also lists Google, Microsoft and OpenAI among the foundation's platinum members. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation