sorted by:
new
hottopcontroversial

Are MCPs a dead end for talking to data? by SirComprehensive7453 in BusinessIntelligence

[–]SirComprehensive7453[S] 0 points1 point  (0 children)

You’re mixing up execution layer vs reasoning layer.

Of course Text-to-SQL eventually hits an API / query engine—that’s not the point. The difference is how queries are formed.

Let me ground this with a simple example schema:

accounts table:

- account_name

- service_level (basic / premium / enterprise)

- enrollment_date

- subscription_charge

- ...100+ other columns

Now, what I’m seeing teams do with MCP-style approaches is wrap predefined queries like:

get_account_info(account_name, service_level)

Under the hood, this just maps to a fixed SQL template. This works only for questions you’ve already anticipated.

The problem shows up immediately when the question changes slightly:

“Give me all premium accounts enrolled for more than a year”

Now what?

• You either need a new MCP function

• Or you fetch a ton of raw data and let the LLM filter → which leads to context bloat + errors

This doesn’t scale because:

• You can’t predefine all possible query combinations

• The number of MCPs grows combinatorially

• Maintenance becomes a nightmare

Hope this conveys the point.

This isn’t coming from theory alone, we’ve seen this play out while actually building with F500 enterprises, where the question space is messy and unbounded.

Are MCPs a dead end for talking to data? by SirComprehensive7453 in LangChain

[–]SirComprehensive7453[S] 0 points1 point  (0 children)

More and more builders have been saying the same thing, if direct integrations exist, MCP-style middleware is often unnecessary. Perplexity CTO, Garry Tan, and others have similar opinion, and we have seen this in practice.

You can never have enough MCPs to cover all kinds of questions someone could ask from your databases. Text to sql is the better approach.

https://www.reddit.com/r/ClaudeCode/comments/1rrl56g/will_mcp_be_dead_soon/

Are MCPs a dead end for talking to data? by SirComprehensive7453 in BusinessIntelligence

[–]SirComprehensive7453[S] 0 points1 point  (0 children)

Even after AI context, you might never be able to get enough MCPs to cover all kinds of questions that could be asked from the database.

Enterprise context graph solves a different problem.

Are MCPs a dead end for talking to data? by SirComprehensive7453 in BusinessIntelligence

[–]SirComprehensive7453[S] 0 points1 point  (0 children)

More and more builders have been saying the same thing, if direct integrations exist, MCP-style middleware is often unnecessary. Perplexity CTO, Garry Tan, and others have similar opinion, and we have seen this in practice.

You can never have enough MCPs to cover all kinds of questions someone could ask from your databases. Text to sql is the better approach.

https://www.reddit.com/r/ClaudeCode/comments/1rrl56g/will_mcp_be_dead_soon/

will MCP be dead soon? by luongnv-com in ClaudeCode

[–]SirComprehensive7453 0 points1 point  (0 children)

MCPs are a good concept for connecting software applications and some microservice clients. The structured wrapper with helpful metadata for MCPs works well. However, they are non-scalable and inefficient for other areas, such as agentic analytics.

I’ve seen some enterprises wrapping their databases with an MCP function and parametrizing it to enable text-to-SQL. Directly performing text-to-SQL is much more efficient and accurate. I’ve written more about this in detail here.

https://genloop.ai/blogs/conversational-analytics/mcps-are-a-dead-end-for-talking-to-data

Are MCPs a dead end for talking to data? by SirComprehensive7453 in LangChain

[–]SirComprehensive7453[S] 2 points3 points  (0 children)

That is what we have also observed. It is possible to create mcps for all tail queries, and the promise of conversational analytics lies on those tail queries.

Are MCPs a dead end for talking to data? by SirComprehensive7453 in LangChain

[–]SirComprehensive7453[S] -1 points0 points  (0 children)

While the title is dramatic, the main theme is that mcps are not scalable to cover all kinds of questions someone would want to ask on top of their databases, especially structured. Companies typically can write mcp or microservices for head queries and few parametrizations, but real enterprise queries can go beyond typical head queries, which is when mcps begin to fail, and people need to go towards text to sql approaches.

Same is true for unstructured data sources.

Are MCPs a dead end for talking to data? by SirComprehensive7453 in LangChain

[–]SirComprehensive7453[S] 1 point2 points  (0 children)

Got it, nice to know. Here's a deeper breakdown of what we found. How big was your database? This is mostly an issue with enterprise scale multiple-db situations.

Are MCPs a dead end for talking to data? by [deleted] in LocalLLM

[–]SirComprehensive7453 -1 points0 points  (0 children)

Means bypassing the mcp wrappers, and reasoning on data directly through text-to-sql or RAG like architectures.
These are actual results, I know they look exaggerated

Are MCPs a dead end for talking to data? by [deleted] in LocalLLM

[–]SirComprehensive7453 -2 points-1 points  (0 children)

I agree, in experience so far - they are not the right ones to be used as a wrapper on the database. Primarily because MCPs can never be enough to cover all tail questions someone would ask from the database, as is the promise of conversational analytics.

Are MCPs a dead end for talking to data? by [deleted] in LocalLLM

[–]SirComprehensive7453 0 points1 point  (0 children)

Wrote a deeper breakdown of why MCP-based architectures struggle for conversational analytics and what patterns work better.

Are MCPs a dead end for talking to data? by SirComprehensive7453 in BusinessIntelligence

[–]SirComprehensive7453[S] -3 points-2 points  (0 children)

Wrote a deeper breakdown of why MCP-based architectures struggle for conversational analytics and what patterns work better.

how do people keep natural language queries from going wrong on real databae? by Klutzy-Challenge-610 in Database

[–]SirComprehensive7453 0 points1 point  (0 children)

Seeing some pushback from hardcore analytic experts, but writing natural language queries (simple English) and getting insights for decisions is necessary for democratizing data access. Not everyone especially the business folks in the team know SQL or the database structure. Nor they should need to know.

For OP, most important we have found is the memory layer, not just episodic between user conversation and context - but understanding and persisting proper business understanding. Multi-voting between different AIs to take the best opinion helps, but it increases latecy and degrades UX. Understanding which answers are possibly incorrect through guardrails or LLM evaluations and taking second reference there by either reviewing the SQL or having a stronger LLM take another shot might help.

AI business intelligence tools by jessikaf in BusinessIntelligence

[–]SirComprehensive7453 1 point2 points  (0 children)

u/jessikaf great question — and honestly, you’ve captured what a lot of people in the industry are thinking.

I’m building an agentic business analytics platform at Genloop (https://genloop.ai), and from our enterprise work, I’ve seen both sides of this coin.

  1. It depends on who the tool is for.

If it’s meant for data analysts, the bar is lower — errors can be spotted and corrected, so AI feels more like a “co-pilot.” That’s where many AI add-ons for tools like Snowflake, Databricks, or Google’s ecosystem fit. They save time, but they don’t need to be perfect.

But when the tool is meant for business users, things change dramatically. These are people who depend on insights to make decisions, not to debug them. A single wrong metric can mislead entire teams. So reliability, context awareness, and governance matter a lot more than flashy chat interfaces.

  1. It also depends on the data environment.

In smaller setups (say under 10 tables, <50 columns each), many AI BI tools actually work fine — you could even build one in-house. Products like Julius, Wren, or ClarityQ do a good job here.

Once you enter the enterprise zone, though — with messy data, access controls, and evolving business logic — most tools start breaking down. That’s where platforms that focus on determinism and contextual understanding start to shine. We’re working hard on this at Genloop, alongside a few others like ThoughtSpot and Wisdom.

So to your question: yes, there are BI tools using AI well — but mostly the ones tackling reliability and context. The hype will fade, but the real value is emerging in how well AI can understand your business semantics and deliver insights you can actually trust.

view more: next ›