Predictable AI Costs at Scale: Why Exasol’s MCP Server Stands Out

More of our community is adopting the Exasol MCP server, and that raises the bar for us: users should get the best experience of any database MCP server, not just a working one. So rather than assume ours was the strongest option, we tested it. We ran it head-to-head against the other database MCP servers people commonly use (DuckDB, Postgres and Clickhouse) and measured the two things that decide whether this works in production: cost and accuracy. This is what we found.

Why This Matters: Predictability, Not Just Cost

When you connect an AI agent (like Claude) to a database through an MCP server, every question the agent answers spends tokens. Tokens are three things at once: money on your bill, time your user waits, and space in the model’s limited context window.

A critical metric for AI tooling is average token spend across real-world use cases. When you’re evaluating the efficiency of AI platforms, leaders are evaluating cost predictability: can you count on the token cost of an AI tool, or does it swing wildly from one run to the next?

Unpredictable AI costs breaks real systems in three ways:

• You cannot budget. If the same question costs 3,000 tokens one time and 40,000 the next, you cannot forecast spend or set a sane per-request limit.
• You cannot promise a response time. More tokens means a slower answer. A question that usually takes 15 seconds and occasionally takes 90 is a broken user experience.
• You can get wrong answers. When a server tries to cope with a large database by pouring the entire catalog into the model’s context, two bad things happen: a single question can consume hundreds of thousands of tokens and crowd out everything else, and the agent can get lost in the noise and miss data it should have found.

So the question this test answers is not just “which MCP server is cheapest,” it is “which MCP server can you actually rely on.”

How The Test Works

We connected four database MCP servers to the same AI agent (Claude Opus 4.8) and asked each one the same five plain-English questions, three times each. We measured two things per question: how many tokens it took to reach an answer, and whether the answer was correct.

The four servers:

• DuckDB (lightweight)
• Postgres (lightweight: one “run a SQL query” tool)
• ClickHouse (a few tools)
• Exasol (governed metadata: purpose-built tools to find and describe tables, plus query)

We ran everything twice: once against a toy database (4 tables) and once against a realistic database (300 tables across 10 business areas like finance, HR, logistics, sales, support, IoT).

What We Found

On a small, simple database, the lightweight MCP servers are great: fast, cheap, correct. By “lightweight” we mean a server with a minimal tool surface and no real discovery layer, just a single “run this SQL” tool and nothing to help the agent find or understand tables. DuckDB and Postgres are the clearest examples.

But a real business database is not a four clean tables, it is hundreds of tables across many areas. At that realistic scale, the lightweight approach tanks predictability. Cost starts swinging up to 10x run to run, one question spiked to nearly 300,000 tokens, and the lightweight servers began giving incomplete answers. The server built around governed metadata (Exasol) stayed steady and correct the whole time.

Testing with Real Analytics Questions

1. Find the hidden table. “Which table stores the history of employee salary changes?” The right table has a cryptic name with no hint of “salary” in it. The only clue is in the table’s description. Tests: can the agent find the right table when the name is no help?
2. Connect two business areas. “Which five customers opened the most support tickets, and what country is each from?” The answer requires joining support data to customer data, which live in different parts of the database. Tests: can the agent find and connect tables across domains?
3. Handle an ambiguous question. “What was our total revenue in 2025?” This is a trap on purpose: “revenue” exists in three different places (sales orders, the finance ledger, and marketing). Tests: does the agent notice the ambiguity and lay out the options, or does it quietly answer from the first thing it happens to find?
4. A normal analytics question. “What is total revenue by product category for completed orders in 2025?” We asked this exact question on both the 4-table and the 300-table database, to see how cost changes when the database gets bigger.
5. Explore and explain. “Which tables hold IoT sensor readings, and how do they relate to each other?” A pure discovery question with no single number as the answer.

How We Defined Pass and Fail

We generated the data ourselves, so we know the true answer to every question. We compared each agent’s answer to that known truth:

• Pass means the answer names the right table(s), the right numbers, or the right relationships.
• Fail means it named the wrong table, missed data it should have found, or (for the ambiguous revenue question) gave a single number without acknowledging it had quietly picked one of three possible meanings.

For the ambiguous revenue question specifically, pass required the agent to flag that “revenue” could mean several things and name at least two of the three sources.

Results: Predictability

Costs below are tokens to answer one question, on the realistic 300-table database.

Server	Tokens per question	Worst single run	Run-to-run swing
Exasol (governed metadata)	11k to 24k	~25k	steady, never more than 1.4x
DuckDB (lightweight)	8k to 47k	291k	up to 8x
Postgres (lightweight)	3k to 49k	~90k	up to 10x
ClickHouse	18k to 101k	~101k	steady but always expensive

Exasol’s MCP server is the only one whose cost you can reliably predict: it never varied more than 1.4x on any question and never exceeded ~25k tokens. The lightweight servers were sometimes cheaper, but the same question could cost 10x more on the next run with no warning, and one DuckDB run consumed 291,000 tokens on a single question, close to the model’s entire context window.

This is why an on-paper token saving can be a trap. A low token cost on simple testing hides the real-world runs that blow up. When you scale out your MCP server to serve an entire organization, those high-cost runs can significantly drive up overall token consumption and spend, in addition to making it harder to forecast.

What causes this unpredictability? With one generic “run a query” tool and hundreds of tables, the agent gambles every run on whether it writes a precise lookup or dumps the entire table catalog into its context. Exasol’s purpose-built “find” and “describe” tools remove that gamble.

What This Means for a Real Business

The whole reason to point an AI agent at your data warehouse is to answer real business questions against a real database: hundreds of tables, spread across finance, sales, support, operations, with names and structure that grew over years. That is the environment that matters, and it is exactly where the differences showed up.

Predictability was one half. The other half was accuracy. On the deliberately ambiguous revenue question, the two lightweight raw-SQL servers (DuckDB and Postgres) were the only ones that returned a genuinely wrong answer: they confidently reported sales revenue alone and never even found the finance ledger sitting among the 300 tables. The servers with a real discovery layer surfaced the ambiguity and pointed at the other source.

That is the quiet danger of the lightweight approach at scale. It does not just get expensive and unpredictable, it can hand you a wrong answer that looks completely confident. An MCP server that is going to run in a real business has to hold up as the database grows, on cost and on correctness. In this test the governed-metadata approach was the only one that did, which is exactly what we set out to verify about our own.

But That’s Not All: The Server Keeps Getting Leaner

But we’re not done! Our exploration revealed that repeated discovery round-trips contribute to token overhead, and resulting payloads balloon when an MCP server dumps rows or catalog into the model’s context. In the most recent release of Exasol’s MCP Server we’ve launched features that directly target reducing discovery token overhead.

• Batch describe. The describe tools now take a list of names and describe many tables, views, or functions in a single call. This means one tool call instead of many.
• A default row limit. A new default_row_limit setting caps the rows a query returns. This is the guardrail against the exact failure mode that punished the lightweight servers: a query that quietly pulls thousands of rows into the context window.
• Fewer tools by default. A new enable_dialect_tools setting hides the SQL-dialect helper tools when you do not need them, trimming the fixed per-request overhead (the “static tax”) that every question pays.
• Compact responses. Query, profile, and sample results now return a tabular {columns, rows} shape instead of repeating the column names on every row, so the same answer carries fewer tokens.

Every one of those changes either cuts tokens or makes them more predictable, which are the two things this benchmark measures.

Full detail is in the 2.1.0 release notes.

Repeatability

Everything here is reproducible and open to inspection. Nothing was hand-tuned or hand-edited; every number came straight out of the test harness.

• Same data everywhere. One generator builds the 300-table database from a fixed random seed, so anyone who runs it gets byte-identical tables. The same 4-table sales data lives inside it, so the small-vs-large comparison is genuinely like-for-like.
• The exact questions are held in a single file, unchanged across all four servers.
• The harness connects to one server, asks each question three times, and records tokens, tool calls, and the full answer text.
• Every raw answer and per-run number is saved, alongside a full technical write-up with per-question tables, run-by-run variance, and the exact grading of every answer against the known-correct result.
• The setup (how each database and MCP server was configured) is captured in config, so the whole test can be stood up and re-run from scratch.

Run details: Claude Opus 4.8 via Amazon Bedrock, three runs per question, prompt caching off. Three runs is enough to make the 6-10x swings obvious; more runs would only tighten the exact figures.