Why your finance agents need MCP

It's 8am on the third day of month-end close. The CFO wants a forecast update before tomorrow's board meeting. The ERP has actuals. The CRM has pipeline. Treasury has today's cash position. The operating model - the thing everyone actually trusts - lives in Excel, on someone's laptop, updated by hand.

None of these systems agree with each other automatically. Not on definitions, not on timing, not on who owns what number.

So the finance team becomes the integration layer. Export from the ERP. Update the Excel model. Copy pipeline data out of the CRM. Pull the bank position. Reconcile the differences. Figure out why "revenue" means three different things in three different systems. Rebuild it all into something a board will accept.

I've watched this happen at enough companies now to know it's not a data problem. There's no shortage of data. The problem is that the data lives in systems with different structures, different permissions, different refresh cycles and different business logic - and nothing sits across all of them.

This is exactly where most people's mental model of "AI in finance" breaks down. A chatbot that summarizes whatever file you upload is useful. It is not a co-worker. A co-worker needs to see the whole process, not fragments of it.

Without a shared context layer, AI in finance stays a clever chatbot or a pile of disconnected automations. With governed access to the systems where finance actually works, it can start acting like a real colleague.

That's the gap MCP - the Model Context Protocol - is built to close. And I want to be precise about what it does and doesn't do, because I think most of the content out there oversells it.

What MCP actually is

MCP is an open standard that lets an AI application connect to external systems through one consistent interface, instead of a custom integration for every tool. Those systems might be your ERP, your CRM, Excel, a banking platform, a planning tool, a data warehouse, a contract repository, a BI tool - whatever your finance stack actually looks like. An MCP server exposes tools, resources and prompts; the AI application discovers and uses them through that same interface every time.

For a finance audience, I'd put it more plainly:

MCP is the interface that makes a governed context layer possible: it lets finance agents pull the right data and actions from multiple systems, without someone building a bespoke integration for every new use case - as long as you build the governance around it.

Notice I didn't call it a "single source of truth." I used to describe it that way and I think it's the wrong framing. MCP doesn't replace your ERP or your CRM as the system of record. It doesn't reconcile anything on its own. What it does is make the relevant information discoverable and usable by an agent, while the source systems keep ownership of their own data.

Worth being precise about a term here, because I'll use it a lot for the rest of this piece: MCP itself is the protocol - the standardized interface. Governance - permissions, audit logs, approval routing - isn't something MCP hands you automatically. It's a layer you or your platform builds on top of MCP. I'll keep that distinction sharp from here on, including in the diagrams below.

If you want an analogy that actually holds up: the ERP is your system of record for transactions. MCP is the interface an agent uses to access the context it needs to interpret and act on those transactions - governed by whatever access, usage and logging rules you build around it. It's closer to a well-run control layer than to a ledger in that sense: a consistent interface through which access, usage and logging rules can be enforced by whoever builds the server and host around it.

Why finance specifically needs this

Finance is a brutal environment for agentic AI, and I say that as someone who builds this stuff for a living. The work is multi-system by nature, painfully sensitive to definitions, audit-heavy, gated by role-based access, full of reconciliations and adjustments, and still - despite everything - running largely on Excel. On top of that it's tangled up with legal, commercial, operational and banking data that has nothing to do with the general ledger but changes what the numbers mean.

Take something as basic as revenue. It shows up in the ERP, the forecast model, the CRM and the board pack - and each of those might be using a different date convention, a different currency, a different entity hierarchy, or a different recognition rule. An agent that just retrieves numbers from four systems and stitches them together can produce a confident, well-formatted, completely wrong answer. Not because it's a bad model. Because it never knew which source was authoritative, what "revenue" meant in this context, which period and entity applied, whether the number was actual or forecast or budget, what adjustments had already been made, or whether the person asking was even allowed to see it.

Why bolting on connectors doesn't scale

The first version of a finance agent usually has separate connectors: one for the ERP, one for the CRM, one for Excel, one for the bank feed. That's a fine way to ship a prototype. It's a bad way to run a CFO office.

Every agent ends up with its own connectors, built slightly differently. Business definitions get re-implemented, and re-argued, in every workflow. Audit trails end up scattered across five different logs instead of one. Every new use case means another custom integration project. And the person using the output still has to validate it manually, because none of these tools actually understood the full context.

I'm not saying direct connectors are useless - they're a legitimate starting point for a narrow prototype. But they don't scale past that. Direct connectors get you a demo. A governance layer built on top of MCP is what makes those connectors reusable, controlled and scalable across an entire finance function.

Architecturally, this works because MCP separates three things: the host application, the client connections, and the servers that expose approved capabilities. One host can coordinate several servers at once, and each client just manages the connection to its own server. That separation is what lets you add a new agent without rebuilding your integrations from scratch.

Before and after, in practice

Before a governed layer, your analysts are the integration layer. They export from the ERP, update the Excel model, copy pipeline out of the CRM, pull the bank position, and reconcile the gaps by hand. AI tools might help with individual steps along the way, but each one only sees its slice of the picture. Everything still needs heavy validation, because no tool in the chain knows which system is authoritative, which definitions apply, or who's allowed to see what.

After MCP is in place, agents stop needing a one-off integration for every workflow. They call governed capabilities - things like get_trial_balance, retrieve_pipeline, run_forecast, match_invoices, calculate_covenant - and the platform built on top of MCP decides what that user or agent is allowed to see, logs the interaction, and routes anything high-risk to a human for approval.

One thing I want to be honest about: MCP itself doesn't automatically guarantee permissions or auditability just by existing. Those controls have to be built by the host, the server, your identity layer, the source systems and the governance you put around all of it. The protocol standardizes the interface. It doesn't do your governance work for you.

Where this actually shows up in the CFO office

Four use cases, not five - I'd rather go deep on four than skim a catalogue of ten.

Month-end close. Today, analysts download trial balances and subledger reports, spread reconciliations across a dozen spreadsheets, run flux analysis after everything's finally assembled, and find exceptions late, if at all. A close agent with governed access to tools like get_trial_balance, get_subledger_balance, list_unreconciled_items, compare_periods and run_flux_analysis can run these checks in parallel, flag unusual movements, pull the supporting evidence, and hand controllers a ready-made exception queue. The point isn't just "the agent does reconciliation" - it's that the reconciliation is now connected to the ledger, the subledgers, prior-period movement, who owns which close task, and the actual explanation behind each number. I've seen close timelines quoted as dropping from 14 days to 3 in specific deployments - treat that as illustrative of what's possible, not a number you should expect out of the box.

Cash and AR/AP visibility. A cash agent that can see bank balances, open receivables and payables, payment runs, remittance data, supplier commitments and the treasury forecast can actually answer the questions people ask every day: was this invoice paid, which receipts are overdue, what's scheduled to go out this week, which suppliers are driving the biggest near-term cash need, what changed in the forecast since yesterday. The value here is mostly about killing the time spent chasing systems and fighting refresh-timing mismatches - and the agent should always cite its source and timestamp rather than hand you an answer with no receipts.

Forecasting and scenario modeling. Combine ERP actuals, CRM pipeline, Excel planning drivers, headcount assumptions, procurement commitments and treasury data, and a forecasting agent can run a base case, apply a pipeline conversion assumption, model a delayed launch, adjust for currency or pricing, and explain the delta between forecast versions. The hard part isn't the math - it's semantic consistency. Does "revenue" mean booked, recognized, invoiced, or pipeline value? If the agent doesn't know, neither does the answer.

Covenant monitoring. This is the use case I'd lead with if I had to pick one, because it shows why structured data alone was never going to be enough. A covenant agent needs credit agreements, amendments, side letters, covenant definitions, GL and treasury data, forecasts, procurement commitments, supplier concentration, FX and rate assumptions, and prior compliance certificates - all at once. Tools like get_active_covenants, retrieve_covenant_definition, calculate_leverage_ratio, compare_to_threshold and assemble_compliance_pack give it the pieces. But the agent shouldn't decide on its own that a breach occurred when the contract language is ambiguous. It should extract the relevant clause, confirm it's the active version, map the definition to the underlying data, calculate the metric, show the threshold and the headroom, flag any missing or disputed inputs, and route the whole thing to credit, legal or treasury for a human call.

That last one is the clearest version of the real argument here: finance agents don't just need access to numbers. They need access to the documents, definitions, exceptions and commercial context that decide what those numbers actually mean. Procurement data alone can explain a forecast miss or surface a risk that never shows up in this period's ledger - supplier concentration, committed spend, termination rights, input-cost exposure.

The architecture, without the jargon

I want to correct something people usually get slightly wrong here, myself included at first: the "MCP client" isn't the important finance-facing layer. It's plumbing.

The host is the AI application or agent runtime - the thing managing the user interaction, the model, the conversation, which servers are even available, consent and permissions, and how tool results get shown back to the user. Think of a finance-agent app, an enterprise assistant, an internal AI workspace.

The client is the connection component living inside the host. It talks to one specific server and passes requests and results back and forth. A host will typically run a separate client for each server it talks to.

The server is what actually exposes the useful stuff: tools (functions the agent can call), resources (data and reference material), and prompts (reusable workflow templates). A finance MCP server might expose ERP query tools, forecast retrieval, invoice matching, covenant calculation - plus resources like accounting policy, chart-of-accounts mappings, contract clauses, or approved metric definitions.

This is the part worth repeating to anyone worried about a six-month rip-and-replace project: this architecture sits on top of what you already have. It doesn't ask you to swap out your ERP, your CRM, Excel, your banking platforms or your contract repository before you can start. That said, I won't pretend it's free - every source still needs proper authentication, data mapping, error handling and clear ownership. MCP standardizes the interaction pattern. It doesn't do the implementation work for you.

Governance is the actual product here

I'd argue this section matters more than the architecture diagram, not less.

Split access into at least three tiers: read (retrieve data or documents), propose (calculate, draft, recommend, prepare), and execute (post, approve, send, modify, trigger something external). An agent might be allowed to read the trial balance and propose a journal entry, but never post it without a controller signing off.

A production finance agent should be logging: who initiated the request, which agent and model handled it, which tools and resources it touched, what source records came back, what it calculated, what it proposed, who approved or rejected it, and what actually happened as a result. If you can't answer all of those questions after the fact, you don't have an auditable system - you have a chatbot with extra steps.

And guardrails need to cover allowed tools, permitted entities and periods, materiality thresholds, segregation of duties, required evidence, confidence thresholds, human approval points, and anything explicitly off-limits. A good finance agent never just answers "yes" or "no." It separates out what's a source fact, what's a calculation, what's an inference, what's a recommendation, and what's still a human decision.

One more thing I'd push back on if I saw it in a vendor deck: MCP is not a security product. It's a standardized capability boundary that the rest of your security and governance architecture operates through. Authentication, authorization, consent, logging - all of that still has to be built and enforced by the host and the connected systems. MCP doesn't do it for you just by being present.

How to actually start

Pick one workflow. Something repetitive, cross-system, genuinely high-friction, measurable, and low-risk enough to run read-only at first. Close checks, vendor-spend analysis, renewal sweeps, cash visibility, forecast variance, covenant data prep - any of these work.

Map the real process before you build anything: which systems touch it, where the manual handoffs are, how terms are defined differently across teams, what the usual exceptions look like, how much time gets lost waiting, what controls already exist, where human approval currently sits, and what your baseline metrics are today.

Don't expose every API you have on day one. Define a small set of finance-oriented capabilities - get_actuals, get_open_items, retrieve_forecast, compare_periods, match_transactions, retrieve_policy, calculate_covenant - each returning structured results, a clear source reference, a timestamp, and a real error message when something's wrong.

Start read-only. Retrieval, reconciliation, calculation, drafting explanations, assembling evidence packs, building exception queues - that's plenty for a first release. Only once you trust the performance and the controls should you start talking about propose or execute permissions.

Then measure what actually changed: analyst hours saved, rework eliminated, exceptions caught earlier, close-cycle time, forecast prep time, reconciliations you no longer do by hand, how often the output was unsupported, how often a human overrode it, how fresh and complete the data actually was.

The question was never "did we deploy MCP." It's whether your finance team is spending less time stitching information together and more time actually deciding things.

From chatbot to co-worker

Back to that 8am on day three of close. The board meeting is still tomorrow. What's different is that nobody's spending the morning assembling information from scratch. The close agent already ran the reconciliation checks overnight. The forecast agent compared actuals against pipeline and updated the drivers. The cash agent flagged the overdue receipts and this week's scheduled payments. The covenant agent pulled the relevant contract clauses, ran the calculation, and laid out the evidence for someone to actually review.

MCP doesn't replace the ERP, the CRM, Excel, or your finance team. It gives agents a governed way to work across all of them at once. That shared context is what turns a pile of disconnected finance automations into something reusable and auditable - and gives AI an actual shot at operating where finance work really happens.

Finance agents don't fail because finance lacks data. They fail because the data, the definitions, the permissions and the workflows are fragmented across a dozen systems that were never built to talk to each other. MCP is the interface for bringing those pieces together under real governance. What you build on top of it is still on you.

How to actually implements this

We don't start with MCP servers and connectors. We start with the same foundation work described above, because a governed layer built on a broken foundation just gets you faster access to bad data.

Our approach follows the same three layers we use for every finance transformation: Foundation (clean, GL-anchored data across your ERP, CRM, and Excel models - the reconciliation work this whole piece assumes), Intelligence (the semantic layer and definitions that make "revenue" mean one thing everywhere), and only then Agents - the close, forecast, and covenant agents this piece describes, sitting on a governance layer we build and configure with you on top of MCP.

We've done exactly this for Base (BaseLinker) - building the finance data foundation their reporting and AI work now sits on, the same order of operations described here.

If you're looking at where MCP fits in your own finance stack - or whether your foundation is ready for it - that's the conversation we're set up to have. Talk to us →