Audience
Leaders of mid-size enterprises
Large language models are good at reasoning over data and bad at getting it. Most "AI for finance" bridges that gap by pasting spreadsheets into a chat window, which loses the structure the numbers live in and every control that governed them. The Model Context Protocol is the open standard that lets an AI client query a system the way a governed user would — through named tools, with the caller's own permissions, audited. This article explains what MCP is, what EAConnect's embedded server exposes to Claude, Cursor and custom agents, and how the governance holds.
A protocol, not a product. It standardises how an AI client discovers and calls the tools a system chooses to expose.
The Model Context Protocol (MCP) is an open specification, published in late 2024 and now supported by the major AI clients, for connecting language models to external systems. A system runs an MCP server that publishes a list of tools — each with a name, a description and a typed input schema — and the AI client calls them over a simple JSON-RPC exchange. The model never touches a database; it asks a tool, the server runs the tool under whatever rules it enforces, and the result comes back as data the model can reason over. The consequence for finance is that "AI access to the plan" stops meaning "export and paste" and starts meaning "the same read path a user has, with the same permissions and a log".
Claude Desktop, Cursor, an in-product chat, a scheduled agent, or a script. It discovers tools, decides which to call, and reasons over what comes back.
Publishes named tools with JSON schemas; validates input; runs each call as an authenticated caller; returns typed results; records the call.
planning.read_data, query.aggregate, reports.run. Coarse enough to be auditable, specific enough that the model cannot wander.
A P&L is not a table. It is a set of measures at the intersection of dimensions with hierarchies, versions and access rules. A model that sees only a flat extract cannot reason about any of that.
Ask a chat assistant "why is EMEA operating income below budget in Q2" and it needs to know which entity members roll into EMEA under the current hierarchy version, which scenario is the budget, which version of the forecast is approved, which accounts constitute operating income and with what sign, and whether the asker is allowed to see the UK subsidiary at all. None of that is in a CSV. All of it is in the planning model's metadata — and MCP is how a model reads the metadata first, then the data, in the same governed way a report does.
Figure 1. Two paths. The paste path is fast and leaves the numbers, their meaning and their governance behind. The MCP path is a governed read, in place.
The server runs in-process inside EAConnect Planning and publishes roughly thirty-two internal tools in named packs. Each pack is gated separately, and nothing is exposed until an administrator turns it on.
| Tool pack | What it does | Gate | Status |
|---|---|---|---|
| meta.* | Discover analytics workspaces: tables, columns, relationships, time intelligence | Workspace mcp_exposed | Shipped |
| query.* | Aggregate and filter analytics data; a constrained SQL variant for read queries | Workspace mcp_exposed | Shipped |
| reports.* | List and run saved reports programmatically | Per-report mcp_runnable | Shipped |
| planning.* | Read the planning model: list models and their details, measures, dimensions and dimension trees, hierarchy nodes, tables — and read data at an intersection | Per-model mcp_exposed + RBAC | Shipped — ten read tools |
| planning_variables.*, analytics_variables.* | List, parse and resolve planning and analytics variables — the central rates and member sets | Model gate for planning; open read for analytics | Specified (BUILD-SPEC-176) |
| workflow.* | Start and monitor workflow apps; mutations require a confirmation token | Per-app exposure flag | Shipped — eight tools |
| insights.* | Submit and resolve insight findings | Agent runtime only — hidden from chat and external hosts | Shipped |
| external.{slug}.* | Tools from registered third-party MCP servers, namespaced | Admin registration; trusted or approval-per-call | Shipped |
Tool counts and status are as documented in June 2026. The absence of a general write tool is deliberate: chat and external hosts read; the only writes are insight submissions by agents and confirmed workflow actions.
The design principle behind the list is that a tool should map to something a user can already do in the interface, so that exposing it to an AI client adds a caller, not a capability. The model reads what a user can read, through the same services, and nothing that was previously impossible becomes possible because a language model asked.
The question a CFO should ask of any AI integration is not "what can it do" but "what stops it". Here is the sequence every MCP call passes through, as documented.
Figure 2. The control sequence. A finance leader can verify each stage from the administration screens: which objects are exposed, which keys exist and whose they are, what the audit log recorded.
Because every MCP caller is a user — a person in chat, an API key owned by a person, an agent running as a person — the organisation's existing access model already covers AI access. There is no separate "AI permissions" question to answer. If Priya cannot see the UK entity, neither can Claude when Priya asks, nor the agent Priya configured, nor a script using Priya's key.
What actually happens when an FP&A lead connects Claude Desktop to the planning model and asks a variance question. Tool names are the documented ones; the question and answer are illustrative.
Figure 3. Metadata first, then data, then the answer. The hierarchy read is what lets the model use "EMEA" and "operating expense" correctly; the version read is what stops it mixing a working draft with the approved forecast.
Two details in the sequence are the whole argument for doing this through a protocol. The model discovered that the caller cannot see the UK entity and said so in the answer, rather than silently reporting a partial number as a total. And the answer carries the tool, model, version and period range it was built from, which is what makes it checkable in the same screens a controller would use.
MCP is symmetric. Just as EAConnect exposes a server to external clients, it can register external servers and offer their tools inside its own chat and agents.
An administrator registers a third-party MCP server — a ticketing system, a source-code host, an internal tool — by URL and credential. EAConnect fetches its tool list, caches it, and presents the tools namespaced as external.{slug}.{tool} next to the internal ones. The chat orchestrator merges the two catalogues each turn. Servers default to untrusted, which means a person approves each call until an administrator marks the server trusted; an optional allowlist limits which of a server's tools are federated at all; credentials are encrypted at rest.
Correlating a plan variance with the tickets or releases behind it; letting an agent read an approved external source alongside the planning data; reaching enterprise systems that publish their own MCP endpoints.
Replacing analytics workspaces as the home of core FP&A data, or bypassing internal access control — external tools run with the server's stored credential, not the user's, so what they return is only as governed as that credential.
An earlier dedicated chat adapter for the EAConnect integration platform was retired; chat now uses internal tools and generic external federation. Integration flows are run through processes and workflow tools, not through a chat-specific bridge.
The same server, three callers, three governance profiles — which is why the audit log records which kind of caller made each call.
| Caller | How it connects | Typical use | Governance note |
|---|---|---|---|
| In-product chat | Built in; the orchestrator holds the session | A planner asks a question of the model or a saved report during a review | Read-only; workflow actions need a confirmation token; roughly eight tool rounds per turn |
| External AI client | Claude Desktop, Cursor or a custom agent over Streamable HTTP at /api/mcp, authenticated with a personal API key | An analyst works in their preferred assistant with live access to the plan; a script prepares a narrative from the approved version | The key inherits its owner's permissions and can never add any; shown once at creation; revocable; default 90-day expiry |
| Scheduled agent | Runs inside the platform as a named user on a cron schedule | Standing surveillance: variance, headcount, readiness — the subject of the agents article | The only caller allowed the insights.* write tools; team-scoped datasources |
The external-client route is the one leaders most often underestimate: it lets the organisation's analysts use whichever AI assistant they already work in, against governed planning data, without a copy of that data leaving the platform.
Opinions from people who have connected AI clients to financial systems and reviewed the results. Not product claims.
The first question for any AI-in-finance proposal: does the model read the system, or a copy of it? A copy has no permissions, no versions and no audit trail, and it is out of date the moment it is made.
Default-off is the right default. Start with one model and one report exposed, for one team, and read the audit log for a month before opening more. What the log shows people actually ask is a better guide to exposure than any policy document.
Chat as the person, keys owned by a person, agents running as a person. If a vendor's AI integration uses a service account with broad access, your access reviews no longer cover it — and neither does your audit.
Letting a model read the approved forecast is low-risk and high-value. Letting it change a number is neither. The confirmation-token pattern — the model proposes, a person confirms, the token is single-use — is the right boundary for anything with a side effect.
A good answer names the model, version and period it read. A model that can cite its tool calls can be checked; one that cannot is an opinion with confident formatting.
Registering an external server is granting a credential. Review it as you would any integration: what it can reach, who trusted it, and whether the tool allowlist is as narrow as the use case.