Tracing Allocations with an MCP-Connected AI Agent

Once you’ve connected an AI agent to your workspace over the Model Context Protocol (MCP), you can ask it — in plain language — to trace cost through your allocation steps. You don’t run a report or write SQL: you ask a question, and the agent calls PlaidCloud’s allocation-tracing tools to find the model, explain a change, walk the chain, and answer what-if questions.

This works from any MCP-connected client — a chat agent (Claude Desktop, ChatGPT) or a coding agent (Claude Code, Cursor) — since they all reach the same tools over the MCP server.

Note

These tools read your allocation configuration and results — they don’t change anything. You can ask freely; nothing is written back to the project.

Prerequisites

• A project containing allocation steps (allocation_split, allocation_rules, or allocation_dim).
• An AI agent connected to your workspace over MCP — see Getting Started with AI Coding Agents.

What You Can Ask

Ask the agent …	What it does	Tool behind it
“What allocation models are in this project?”	Lists each model, its stages, and the result tables it produces	allocation_model_find
“How is cost_line_rev calculated?”	Shows the cost pool being split, the driver it is split by, and the target table	allocation_describe
“Why did cost_line_rev change from 2025 to 2026?”	Compares the two periods and attributes the change to the pool size versus the driver mix, with the top contributing accounts	allocation_root_cause
“What feeds cost_line_rev?”	Walks the upstream chain — drivers, source pools, and imports	allocation_lineage
“Where is revenue_by_line used as a driver?”	Lists every allocation that splits by that table	allocation_driver_usage
“What happens if US revenue rises by $1M?”	Splits the change across each affected result by its current share of the pool — additive across a fan-out, not a worst-case per table	allocation_forward_impact
“What if the Assembly cost centre’s headcount driver rose by 10?”	Reslices the fixed pool under the new driver weights — exact, showing which targets gain and which lose, netting to zero	allocation_driver_scenario

Worked Example

A finance analyst notices a revenue-driven cost line has fallen year on year and asks one question. The agent answers it end to end, calling several allocation tools behind the scenes.

You ask: Our revenue-based cost allocation (cost_line_rev) looks down in 2026 versus 2025. What happened, what is it built from, and what would a +$1M US revenue swing do?

The agent replies:

What it is. cost_line_rev is the revenue-driven stage of your Activity-Based Costing (ABC) model. It takes a cost pool (group_amount, limited to a set of P&L accounts) and splits it by revenue from revenue_by_line, weighted within each entity, year, and month.

Why it dropped (US, 2025 → 2026). US-allocated cost fell from $7.12M to $2.99M — a $4.13M drop (−58.0%). This is not a mix shift: the US share of the pool held steady at about 23% in both years. The driver is the total cost pool shrinking, concentrated in a few accounts:

Account	2025	2026	Change
700000	$2.58M	$1.09M	−$1.49M
701000	$1.85M	$0.77M	−$1.08M
610000	$1.71M	$0.72M	−$0.99M
670000	$0.68M	$0.29M	−$0.39M
702000	$0.30M	$0.13M	−$0.18M

Those five accounts explain essentially all of the move.

What feeds it. cost_line_rev is built from revenue_by_line (the split driver) and gl_pool_entity (the cost pool).

Heads-up — that driver is shared. revenue_by_line also drives cost_line_cs and cost_line_admin, so a revenue restatement ripples into all three.

Your +$1M US scenario. The $1M is spread across the results that share this driver by each one’s current share of the pool, so the per-table estimates add up to the change rather than each repeating the full $1M — you get a figure for cost_line_rev, cost_line_cs, and cost_line_admin that you can total. Narrow the question to a single target and the estimate is applied to just that slice.

The analyst gets a complete answer — the size of the change, the accounts behind it, the lineage, and the blast radius of a what-if — without opening a single table.

How Far to Trust an Answer

A fluent answer isn’t automatically a correct one. Every “why did this change” answer now comes with a plain-language read on how far to trust it, so a plausible-but-shaky number is flagged before you act on it rather than buried in the prose. Alongside the explanation, the agent tells you:

• A confidence level — high, medium, or low — reflecting how cleanly the change decomposes. A change driven by one clear cause reads high; one where several causes overlap, or where the figures don’t fully reconcile, reads lower. When a result is built from several allocation branches, the confidence weighs each branch by how much of the change it accounts for — so one small, shaky branch doesn’t drag down an otherwise-clean answer — but a branch whose number is itself in doubt (an unreconciled split, stale data, or something that can’t be attributed) still holds the whole answer’s confidence down.
• Caveats in plain words — for example: the cause is a mix of overlapping factors rather than a single one; the answer rests on the current hierarchy or driver weights; part of a change may be a data-completeness artefact (a period that hasn’t finished loading) rather than a real movement; the pool or driver feeding the allocation hasn’t been reloaded recently, so the figure may rest on out-of-date data; or a what-if figure can’t be added across targets.

When the agent can’t stand behind a precise cause, it says so and points you at the scope or filter that would let it answer cleanly — instead of inventing a confident story. And because the confidence and caveats are part of the answer, they travel with it: if you ask a follow-up agent to summarise, the trust signals don’t get quietly dropped.

Stale-data flagging is optional

The freshness caveat — lowering confidence when the underlying data hasn’t been reloaded within a set window — is off by default and turned on per workspace by your administrator, who also sets how recent counts as fresh (higher for data that’s only refreshed quarterly or annually). If your team deliberately works with older data, it stays out of the way until someone opts in.

Read the confidence, not just the number

A low or medium confidence isn’t a failure — it’s the agent being honest that the change has more than one plausible cause, or that something (a stale driver, an unfinished period) could be skewing it. Treat it as a prompt to add a period, a filter, or a breakdown dimension and ask again.

When a clean-looking total hides the story

Two whole-pool totals can read as clean growth but mislead, and the agent now catches both: when large ups and downs offset to a small net change (the single biggest mover is larger than the headline itself), and when most of a change is pass-through — cost the allocation carries straight through without splitting it by the driver — so the part the driver actually governs is only a sliver. In each case it lowers confidence, names how much the driver-controlled amount really moved, and points you at the member-level view.

Good to Know

Filtered allocations get a clean, whole-pool answer

When an allocation’s source rows are restricted (for example to a set of P&L accounts), the agent applies that filter automatically and still gives a clean, whole-pool attribution — you don’t need to add anything.

Dimension allocations

For an allocation driven by a dimension hierarchy — for example, splitting a cost centre across a reporting structure — the agent now explains the change: at the whole-total level it attributes it to the input pool, and when you filter to a specific target it separates the pool moving from that target’s share shifting. The one thing it can’t yet reconstruct is a cause that depends on point-in-time hierarchy history, which is a later release.

Cascaded allocations need a slice

When one allocation feeds another — a cascade — a project-wide “why” would mix the wrong rows, so the agent asks you to scope the question to a slice (a specific region, product, or cost centre) and then explains it.

Results built by more than one allocation

If a result table is produced by more than one allocation step, the agent won’t guess which one drove a change — it lists the candidate steps and asks you to name the one you mean. When your question narrows to rows that only one of those steps produced (for example a region it alone allocates), the agent recognises that and traces that step automatically, telling you it did so.

Value-change what-ifs use today's shares

“What happens if this pool goes up by …” answers split the change across a fan-out by each target’s current share of the pool, so the per-table figures add up rather than each being a worst-case envelope. They reflect the model’s shares as they stand today — a well-scoped estimate of where a change lands, not a precise forecast. Point one at a driver or basis table rather than the input pool and it’s handled as a driver what-if instead (below), since changing a driver reshuffles a fixed split rather than adding value.

Driver what-ifs are computed exactly

Ask what a change to a driver would do — “what if the Assembly cost centre’s headcount driver rose by 10?” — and the agent reslices the fixed pool under the new weights exactly, with no model re-run. It shows which targets gain and which lose, and the gains and losses net to zero as a built-in check. It sticks to what it can compute exactly: a single straightforward split with a simple driver. Anything more involved — a hierarchy-based or filtered/conditional allocation, adding a brand-new driver member, or a change that empties a group — is declined with the reason rather than estimated.

Is this change unusual?

Alongside the “why”, the agent judges whether a change is out of the ordinary — it compares this period’s movement against the model’s own history of period-to-period changes and calls it normal, elevated, or extreme, so a routine shift and a genuine spike read differently.

Concentrated changes are called out

When most of a year-on-year change comes from a single group — one entity or customer accounting for the bulk of the move — the agent’s summary flags it explicitly, so a change driven by one outlier isn’t mistaken for a broad-based shift. Add a breakdown dimension such as entity or account to your question to see this.

Tips

• Refer to tables by their name (cost_line_rev) or their id — both work.
• For a change question, name the periods to compare (for example 2025 versus 2026) and, where useful, a breakdown dimension such as account or entity.
• Start broad (“what allocation models are in this project?”) and drill in; the agent keeps the thread, so follow-up questions build on the same model.
• There are two kinds of what-if: a value change (“this pool rises by $1M”) is estimated by today’s shares and adds up across targets; a driver change (“reweight this driver”) is resliced exactly and nets to zero. Phrase the question for the one you mean.

Related

• Getting Started with AI Coding Agents — connect an agent to your workspace over MCP
• Why Allocations Are Useful — allocation concepts
• Troubleshooting — connection and authentication issues