Multi-tool MCP chaos: one revenue definition

This is a composite story. Details are anonymized and combined from patterns we see when teams wire several MCP tools into the same assistant. No company names.

The week three tools disagreed

A head of data opened Slack to a familiar fight. Finance had one quarterly revenue figure. A sales ops bot had another. An internal “ask the warehouse” agent had a third. All three answers had been produced in the last twenty-four hours. All three sounded precise.

The assistant stack had grown the usual way. One MCP server exposed a SQL runner. Another wrapped a BI extract API. A third called a metrics microservice that still accepted free-form measure names. Each tool could answer “what was revenue last quarter?” None shared a definition.

The agents were not malicious. They were helpful. Helpful plus SQL access is how you get three revenues.

What actually broke

The failure was not model quality. It was request shape.

• The SQL tool let the model invent joins and filters. Sometimes refunds were excluded. Sometimes not. Sometimes the join to accounts multiplied rows.
• The BI tool returned a saved tile that finance trusted - but only for the filters baked into that tile. The agent paraphrased the question and hit a different tile.
• The metrics service accepted a string that looked like a metric name and resolved it with best-effort matching. Close names were close enough until they were not.

Governance, such as it existed, was a post-filter: check the result, argue in thread, maybe open a ticket. By then the number had already been pasted into a leadership update.

Trust did not fail all at once. It failed every time someone asked which bot to believe.

The reset: one certified definition

The fix was not “better prompts.” It was removing the ability to invent revenue.

The team authored revenue once in a YAML semantic model - entity grain on orders, measure as sum of amount, certified metric named revenue, filters for completed orders encoded in a curated view. Transforms stayed in the warehouse. The semantic layer stayed thin.

They published the model as an immutable artifact with access rules and a cost ceiling. Then they changed how agents connect:

• Agents received a role that grants the revenue metric, not raw tables.
• MCP exposure was limited to the six semantic tools: list_catalog, describe_metric, run_semantic_query, drill_down, refine_semantic_query, and list_dimension_values.
• Those tools neither accept nor return SQL. The agent selects metric and dimension names from the catalog and sends a structured Semantic Query.

Finance’s dashboard and the agent started sending the same object: metrics × dimensions × filters. datahashi compiles fan-out-safe SQL and runs it in the warehouse. Callers never invent joins.

The SQL-runner MCP tool was taken out of the assistant’s tool list for revenue questions. Not because SQL is bad - because SQL is the wrong interface for a number that must match across humans and agents.

What trust looked like afterward

The useful test was boring. Someone asked the agent for quarterly revenue with the same filters as the finance dashboard. The numbers matched. They asked again with a region breakdown. Still matched. Metering showed which agents called revenue and how often - observability on a single definition, not a debate across three pipelines.

Disputes moved upstream, where they belong: change the YAML, validate, publish a new version. Pin consumers if you need a stable cut. No mid-flight rewrites under the old name.

The lesson for heads of data

Multi-tool MCP chaos is what you get when every tool can answer the question and none of them own the definition. One certified metric restores trust because governance is the request shape. Agents can still be wrong about which question to ask. They can no longer be confidently wrong about how revenue is computed.

If your assistant can see three paths to revenue, it will eventually use all three. Give it one.