Get FP&A best practices, research reports, and more delivered to your inbox.
Last updated: July 2026
Model Context Protocol (MCP) is an open standard that lets AI assistants like Claude and ChatGPT query your business systems directly — live, permissioned, and logged — instead of reasoning over screenshots and pasted CSV exports. For a finance team, MCP for finance means the assistant pulls this morning's actuals from the same governed data layer your reports run on, respects the same user permissions you already administer, and leaves an audit trail behind every answer.
The standard was introduced by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, which is why it now works across Claude, ChatGPT, Microsoft Copilot, and Gemini rather than locking you into one assistant. In FP&A specifically, MCP support is splitting the market: Aleph, Datarails, Cube, Pigment, and OneStream have shipped public MCP servers, while Planful, Anaplan, and Workday Adaptive Planning have no published MCP endpoint as of July 2026.
Bottom line: MCP is how an AI assistant becomes an analyst on your live, governed financial data instead of a chatbot summarizing a stale export. If your FP&A platform exposes an MCP server, Claude and ChatGPT can answer from your real numbers with permissions and audit trails intact; if it doesn't, someone on your team is still the copy-paste layer.
What is MCP, in finance terms?
MCP (Model Context Protocol) is a standard way for an AI assistant to connect to an outside system — your planning platform, your data warehouse, your ERP — and ask it structured questions. The system runs an MCP server: a service that publishes a menu of specific, permissioned actions (the protocol calls them tools), such as "list available models," "pull this report," or "get revenue by segment for these periods." The assistant is the client: it reads the menu, decides which tool answers your question, and calls it.
The useful analogy for a finance audience is a governed API with a translator attached. Your systems already have APIs, but using them means engineering work for every system-and-assistant pairing. MCP standardizes that handshake once: any MCP-capable assistant can talk to any MCP server without custom integration. The official protocol documentation covers the mechanics, but the practical takeaway is simpler — the assistant never gets raw database access. It gets a controlled set of doors, each of which the server's owner defined, scoped, and can log.
That distinction matters because it's the difference between "we gave the AI our data" and "we gave the AI a permission-checked query interface to our data." The first is how file uploads work. The second is how finance systems are supposed to work.
Why does MCP matter for finance teams specifically?
Every function benefits from AI that can see live data, but finance has four problems that MCP addresses directly — and that file uploads make worse.
No more pasted exports. The default way finance teams use ChatGPT or Claude today is exporting to CSV, uploading, and asking questions. That workflow has a shelf life measured in hours: the moment actuals restate or a forecast version changes, the analysis is describing a company that no longer exists. It also scatters copies of financial data across chat histories and downloads folders. With MCP, there's nothing to export — the assistant queries the source at the moment you ask.
Governance carries through. A well-built finance MCP server enforces the same role-based permissions as the platform behind it. The analyst who can't see executive compensation in the planning tool can't see it through Claude either, because the query executes as them. Uploads have no equivalent — once a file is in the chat, whatever was in the file is in the conversation.
Every query is auditable. MCP tool calls are discrete, loggable events: who asked, what tool ran, what data came back. When an AI-assisted number ends up in a board deck, you can trace it to the query that produced it. That traceability is the property that makes AI output defensible in a close process or an audit conversation — and it simply doesn't exist for "I pasted the trial balance into a chatbot."
The semantic layer travels with the data. A semantic layer is the set of agreed definitions sitting on top of raw data — what counts as ARR, which accounts roll into gross margin, how FX is handled. When an assistant queries through an MCP server built on governed definitions, "what was net revenue retention last quarter" returns your NRR, computed the way your FP&A platform computes it, not the assistant's best guess from column headers. This is the quiet reason MCP answers are trustworthy in a way spreadsheet-upload answers aren't.
How does an MCP connection actually work?
You don't need to understand the protocol internals to run one, but you should be able to explain the flow to your controller and your security team. Here's what happens when a finance user asks a connected assistant a question:
- The platform hosts an MCP server. Your FP&A vendor (or data team) runs a service that exposes specific tools — list models, get dimensions, pull report data, query metrics. Nothing else is reachable.
- You connect the assistant. In Claude or ChatGPT, you add the server as a connector and authenticate, typically via OAuth with your existing platform login. The connection inherits your user's permissions — it isn't a shared service account.
- You ask in natural language. "Why did OpEx come in $340K over budget in May?" The assistant reads the available tools and plans which calls answer the question.
- Tool calls run with approval. The assistant requests the data it needs. Depending on configuration, you approve calls individually or pre-approve read-only tools; anything that writes or reaches outside typically requires explicit confirmation.
- The answer comes back grounded. The assistant reasons over the returned data and responds — with the underlying queries visible, so you can check what it actually pulled before the narrative goes anywhere.
Two design points are worth checking with any vendor. First, whether tools are read-only or can write back — read-only is the right default for a first rollout. Second, where the connection works: chat interfaces are the baseline, but finance work lives in spreadsheets, so an MCP setup that also functions inside Excel and Google Sheets — where the model you're building actually sits — removes the last copy-paste step rather than relocating it.
Which FP&A platforms support MCP today?
As of July 2026, five FP&A platforms have shipped public MCP support — Aleph, Datarails, Cube, Pigment, and OneStream — while Planful, Anaplan, and Workday Adaptive Planning have no published MCP endpoint. Here's the landscape:
A year ago this table would have had one or two "yes" rows; MCP support is rapidly becoming table stakes for the category, which means the useful comparison is no longer whether a platform has MCP but what the implementation gives you. Three questions separate them:
Where does it work? Most implementations connect a chat window to the platform. Aleph's MCP also runs inside Excel and Google Sheets — the Aleph MCP announcement covers this — so the AI can build a revenue model with live customer counts and cohort data in the workbook you already own, rather than producing analysis you then re-key into a spreadsheet. For teams whose deliverables are spreadsheets (that is, most finance teams), this is the difference between a demo and a workflow.
What's underneath? An MCP server is only as good as the data layer it exposes. If the platform's mappings are stale or metric definitions live in tribal knowledge, MCP gives your assistant fast access to numbers nobody fully trusts. Governed, source-traceable data isn't a nice-to-have here; it's the whole point.
Read, or read-write? Implementations that can refresh forecasts and update models are more powerful and demand more governance. Ask every vendor which tools write, and what the approval model looks like when they do.
What should finance teams check before connecting an AI assistant?
MCP narrows the attack surface compared to uploading files everywhere, but it introduces real considerations. Three deserve attention before rollout, not after.
Prompt injection — especially in spreadsheets. A prompt injection attack hides instructions inside content the AI reads, so the model treats attacker text as user intent. Anthropic explicitly flags this for spreadsheet work: its Claude for Excel documentation warns of "prompt injection attacks that hide malicious instructions in spreadsheet content (cells, formulas, comments, etc.)" — a template downloaded from the internet could carry hidden instructions to exfiltrate data or modify records. The mitigations are procedural: only open trusted files in AI-connected sessions, keep confirmation prompts on for actions that write data or reach external URLs, and treat "review before approve" as a control, not a formality. Our Claude and Excel guide for FP&A covers the safe-usage patterns in more depth.
Access controls that actually inherit. Confirm the MCP connection executes as the individual user, not a super-admin service account. Ask the vendor to demonstrate that a restricted user gets restricted answers through the assistant. Start read-only, start with a small pilot group, and review the query logs in week one — the logs are only a control if someone reads them.
What not to connect. Some data shouldn't be reachable by a general-purpose assistant at all, at least initially: payroll and compensation detail, bank and treasury credentials, M&A data rooms, and anything under legal hold. And no MCP server should have unsupervised write access to your system of record — the assistant is a narrative and analysis layer on top of governed numbers, not the place where the numbers get changed. Draw that boundary explicitly in your rollout doc.
Getting started: a first MCP rollout for a finance team
You can go from zero to a working pilot in a week if the data side is in order. The sequence that works:
- Pick one pilot use case with a deadline. Variance commentary for the monthly close package is the classic first win: bounded data, obvious time savings, easy to check the AI's work against your own.
- Get the data layer honest first. MCP amplifies whatever it's pointed at. If mappings, metric definitions, or entity structures are shaky, fix that before connecting anything — our data readiness checklist is the pre-flight list.
- Choose the assistant surface. Claude and ChatGPT both speak MCP; the practical differences are in reasoning quality on finance tasks, spreadsheet integration, and enterprise controls — our comparison of LLMs for finance teams breaks this down. Verify plan requirements with the assistant vendor; custom connectors generally require paid plans.
- Connect read-only, to two or three users. Authenticate with individual logins, pre-approve read tools only, and let the pilot group work a real close cycle with it.
- Set approval norms and review the logs. Agree on what requires human confirmation, then actually read the first month of query logs. You'll learn what people ask an AI when the data is live — which is also your roadmap for what to enable next.
- Expand deliberately. Add users, then use cases, then (if warranted) write-back capabilities — in that order. For patterns on what finance teams do once connected, how finance teams use Claude is a useful map of the territory.
Query your financial data from Claude and ChatGPT with Aleph
Aleph is a spreadsheet-native FP&A platform, and Aleph MCP connects its governed data layer — actuals, models, metrics, and mappings from your source systems — to Claude, ChatGPT, and the other AI tools your team already uses, in chat or directly inside Excel and Google Sheets. Answers trace back to source, permissions carry through, and the numbers the AI reasons over are the same numbers your board reporting runs on. If you want to see what a governed MCP connection looks like on your own data, book an Aleph demo.
Get FP&A best practices, research reports, and more delivered to your inbox.
