Your AI Has an MCP Connection. Does It Have Enough to Be Right?

A family office asks its AI assistant a straightforward question:

"Do we have enough cash to meet next quarter's commitments?"

The answer arrives in seconds. It is clear, well structured and supported by a table.

But did the assistant see every relevant entity? Did it retrieve all the transactions or only the first page? Were the balances current? Did it distinguish unrestricted cash from money that cannot be deployed?

A convincing answer is not evidence of a complete investigation.

That was my biggest takeaway from "Not Every MCP is Created Equal," the ORCA × SumIt webinar I attended on 23 October 2026.

Alexandre Lin, Co-Founder and CEO of SumIt, and Tomas Hurcik, Co-Founder and CEO of ORCA, explored a question wealth managers, RIAs and family offices should ask before celebrating another AI connection:

What, exactly, have we connected—and what can we safely rely on it to do?

*Webinar observations throughout this article come from the presentation materials and my attendance notes. Vendor claims and usage figures are attributed, not independently verified.

A connection is a capability, not a guarantee

Model Context Protocol, or MCP, provides a standard way for AI applications to interact with external data and tools. MCP servers can expose tools, resources and reusable prompts.²

That can reduce the need to export files, copy information between applications or wait for a vendor to build a particular reporting feature.

But the protocol does not certify the completeness of the data, the correctness of the business logic or the safety of the resulting workflow. Its specification explicitly places implementation responsibilities around consent, privacy and tool safety on developers and operators.³

For a wealth-management firm, "we support MCP" should begin the due-diligence conversation—not conclude it.

1. Ask what the connection leaves out

One of the strongest distinctions in the webinar was between access to summary values and access to the underlying records.

A balance can answer:

"How much is in this account?"

It cannot, by itself, answer:

"Why did the balance change, which entries explain the movement, and were any subsequently corrected?"

SumIt reported that transaction-level requests accounted for 49% of its MCP data requests during the measurement period presented, 22 June to 13 October 2026. That is vendor-reported usage, not an industry benchmark, but it illustrates why detailed access matters. (Source: ORCA × SumIt webinar.)

For family offices, the same issue applies to ownership.

Today's ownership record cannot necessarily answer who owned an entity when a distribution was approved six months ago. That requires historical information.

I would be careful, however, about making "the AI can see everything" the objective.

Complete history does not guarantee complete business context. Nor should completeness override confidentiality.

The better requirement is: Give the workflow the information it needs—and make the boundaries of that information explicit.

That means identifying the entities, dates, filters, permissions and records covered, including whether more results remain.

A summary-only connection is not inherently inadequate. It becomes inadequate when a summary is used to answer a question requiring detail.

2. Keep authoritative calculations outside the conversation

The webinar distinguished model-generated analysis from calculations performed by the underlying software. SumIt described its approach as retaining accounting calculations in the system while giving AI detailed information for analysis. (Source: ORCA × SumIt webinar.)

For a trial balance, ownership roll-up or reconciliation, I want the calculation performed by tested system logic, with defined inputs and reproducible results.

The AI can request the calculation, explain it and help investigate exceptions. It should not be expected to improvise an authoritative number from a narrative.

But deterministic does not mean correct.

A calculation can reproduce the same wrong result if its inputs, classifications or rules are wrong.

Consider ownership and control. A precisely calculated percentage is not necessarily a complete assessment of control: the question may also require examination of voting rights and governing agreements.

My operating principle is:

• Use controlled calculations for exact numerical work.
• Preserve the evidence and assumptions behind them.
• Use AI to assist interpretation.
• Escalate conclusions requiring professional judgment.

The more consequential the decision, the less comfortable I am with a plausible answer that cannot be reconstructed.

3. A local connection is not necessarily a local AI workflow

ORCA and SumIt described different connection designs.

ORCA presented a desktop-based approach, with communication between applications on the same device. SumIt described a hosted, permission-aware connection, initially read-only, with request logging and controls over the information exposed. These are vendor descriptions, not independent security assessments. (Source: ORCA × SumIt webinar.)

The distinction matters, but neither "local" nor "hosted" is a sufficient privacy conclusion.

MCP separates the AI application, its client connections and the servers exposing data or tools. Understanding that architecture is necessary to understand where information travels.²

If a desktop application passes retrieved information to a cloud-hosted model, the local connection does not keep the entire workflow on the device.

I would ask a vendor to draw the complete journey:

Source application → connector → AI application → model provider → logs and retained outputs.

Then ask what information exists at each stage, who can access it and how long it remains.

MCP's authorization framework addresses access to protected MCP servers. That is important, but it is not a substitute for checking that an implementation preserves the firm's entity-, account- and document-level access rules.⁴

4. Verification should be part of the answer

Both speakers emphasised making it easy to return to the underlying records.

SumIt described results carrying counts, periods, totals and links back to the product. ORCA described exposing underlying rows and links to supporting entities and files. (Source: ORCA × SumIt webinar.)

This is the right direction.

A family-office principal should not need to trust a generated explanation simply because it sounds financially literate.

For a material result, I would expect the reviewer to establish:

• Which records supported it.
• What period it covered.
• Whether the retrieval was complete.
• Which system performed the calculations.
• How to inspect the supporting evidence.

A source link helps, but it does not prove that the AI interpreted the source correctly.

Verification needs both access to evidence and a way to check the reasoning applied to it.

That matters particularly when an answer combines accounting, portfolio and legal-entity information.

5. Read-only and write-enabled are different operating models

A tool that retrieves a ledger is not equivalent to one that posts an entry.

A draft KYC response is not equivalent to submitting it to a bank.

Preparing a payment instruction is not equivalent to releasing funds.

The webinar's discussion of staging environments, human approval and attribution was therefore more significant to me than another demonstration of a polished report. SumIt described approval before changes reach the books; the discussion also addressed identifying agent-generated changes. (Source: ORCA × SumIt webinar.)

Before enabling write-back, I would want:

• Clearly defined permitted actions.
• A preview of the proposed change.
• Approval requirements proportionate to its consequences.
• Validation before execution.
• A record of what changed and whether it succeeded.
• A recovery or correction process.

Attribution should capture more than a choice between the agent's name and the user's name.

Where relevant, the audit trail should distinguish who requested the action, which agent performed it, who approved it and which identity executed it.

Logging an agent does not make the agent accountable. Logging a human does not prove that person reviewed the action.

MCP changes integration. It does not eliminate it.

One of the more provocative observations in the webinar was that customers are beginning to use MCP connections to assemble cross-system workflows rather than waiting for vendors to build individual integrations. (Source: ORCA × SumIt webinar.)

There is something powerful here: a family office can build a useful workflow without waiting for every application provider to develop a bespoke feature.

But an MCP connection is not a data lake. The protocol provides access to exposed resources and tools; that is different from establishing a consolidated, governed data store.²

If the ledger, portfolio platform and legal-entity system describe the same structure differently, someone still needs to establish how those records relate.

For RIAs, the equivalent questions concern clients, households, accounts, advisors and reporting periods.

MCP can make information easier to reach. It does not remove the work of deciding what that information means.

Start with one workflow—and test its limits

The webinar's audience poll offered a useful reality check: 11 of 15 respondents had not yet deployed an MCP connection.

That is a small, self-selected audience—not a market adoption statistic. Nevertheless, the responses about security, trust and implementation reflected the practical questions raised throughout the session. (Source: ORCA × SumIt webinar audience poll.)

My recommendation is to choose one bounded, read-only workflow.

For example: prepare a draft monthly cash commentary from approved accounting records, with transaction support and links back to source.

Then test more than the successful case.

What happens when an account is missing? When permissions exclude an entity? When records are incomplete? When two systems disagree?

Does the assistant ask for clarification—or confidently fill the gap?

A workflow earns trust partly through the answers it refuses to manufacture.

Buy the operating discipline, not the acronym

MCP can give family offices and wealth-management firms more flexibility over how they use their software and build workflows around it.

That is worth being enthusiastic about.

But flexibility without clear boundaries can move reconciliation, privacy and operational risk into a conversational interface where those problems become harder to see.

Before approving a connection, I would ask:

What can this workflow see, what can it do, and how will we know when it is wrong?

The quality of those answers matters far more than the presence of MCP on a product roadmap.

Sources

1. ORCA × SumIt — "Not Every MCP is Created Equal," webinar, 23 October 2026. Speakers: Alexandre Lin, Co-Founder and CEO of SumIt, and Tomas Hurcik, Co-Founder and CEO of ORCA. Primary material: presentation text, audience-poll results and my attendance notes.
2. Model Context Protocol — "Architecture overview."
3. Model Context Protocol — "Specification," 25 November 2025 version.
4. Model Context Protocol — "Authorization," 25 November 2025 version.