Click for Takeaways
- MCP defines how an AI client discovers and calls tools. It says nothing about whether the data behind those tools is consolidated, mapped, or permissioned.
- A homebuilt connector rarely fails loudly when a source schema changes. It returns a partial total that flows into a report nobody re-checks.
- Permissions enforced inside an AI client are advisory. Only enforcement at the data layer survives an export or a direct API call.
Someone on the engineering side points out that the protocol is open and the specification is short, and both of those things are true. A prototype connecting an AI client to a database is a small piece of work. The cost lands later, in the parts nobody scoped: the mapping, the permissions, the schema change nobody was watching for, and the question of who owns the thing when the engineer who built it moves teams. These questions cover that second half.
MCP is an open standard, so what stops me building my own server?
Nothing stops you, and a first working prototype comes together quickly, building a finance data connector this way is straightforward at first. MCP is deliberately simple: it defines how an AI client discovers and calls tools, and says nothing about what those tools should return. The substance behind them, meaning mapped, consolidated, permission-aware financial data, is the part you would be building. The protocol is the easy half.
What does a finance data connector have to do beyond authenticating?
Authentication is the smallest part of it. Production work also includes:
- Incremental sync with retries, backoff, and rate limit handling
- Schema mapping into a consistent account structure
- FX translation at the correct rate type for each balance
- Period-close awareness, so drafts are never served as actuals
- Reconciliation checks that catch a sync which half-completed silently
- Each one is the difference between data that ties and data that looks like it ties.
What happens to a homebuilt connector when a source system changes its schema?
It usually keeps running and returns the wrong answer. A renamed field or an added dimension rarely throws an error. It produces a null or a partial total that flows into a report nobody re-checks. Vendors absorb this with monitoring across every customer at once. In-house, the failure surfaces when somebody notices a number looks off.
Where do metric definitions live if I build my own finance data layer?
You have to build a semantic layer for them, or they stay in spreadsheets and in people’s heads. Definitions need versioning, a named owner, and enforcement at query time so every tool returns the same ARR. Most in-house projects handle the pipes well and stop short of this, which leaves the model free to invent a definition. That is the exact failure the project was meant to fix, the same gap covered in why AI picks the wrong metric definition on its own
How do I enforce permissions and audit trails on an AI query?
At the data layer, never in the AI client, because the client is not a trusted enforcement point. That means user identity carried through the query, row and field-level rules applied before results are returned, and a log capturing who asked, what was asked, what came back, and when. Built to a standard an auditor will accept, this is a security project, not a connector.
What does a homebuilt finance data pipeline cost to maintain once engineering moves on?
The build is the small number. Ongoing cost is connector maintenance across every source, schema-change firefighting, semantic layer upkeep as definitions evolve, and periodic access reviews. The larger exposure is ownership. These pipelines are usually one engineer’s side project, and when that engineer changes teams, finance inherits a system it cannot maintain and cannot replace mid-year. The protocol authors are explicit about this. The MCP specification states that MCP cannot enforce consent or authorization at the protocol level, and leaves that to implementors.
The build-versus-buy conversation we have most often is rarely about whether the team can do it. It turns on what happens after. Connector maintenance across every source, a semantic layer nobody scoped, and a pipeline that becomes one engineer’s side project. Engineering teams almost always have higher-priority work, and finance rarely has the patience to wait out the queue.
What does Datarails maintain that a homebuilt MCP server would not?
Datarails FinanceOS® is a governed data layer with 600+ maintained source connectors, a versioned semantic layer holding your metric definitions, and role-based access enforced at the data layer, all exposed to any MCP-compatible AI client. Connector maintenance, schema monitoring, and audit logging sit with the vendor.
Should I build it or buy it?
The prototype will work. That was never in question. Eighteen months from now the live questions are who noticed when a source system renamed a field, where the definition of ARR lives and who versioned it, whether an AI query can be shown to have respected permissions, and who maintains any of it once the engineer who built it has moved teams. Those are the parts that took vendors years rather than a weekend. If your engineering team is scoping this, it is worth seeing the finished version before committing, and worth asking, separately, whether that AI layer should sit inside one vendor’s product or connect to whatever your team already uses
A FinanceOS demo covers the connector estate, the semantic layer and the audit trail in roughly the time the prototype took to build.
