MCP in the Real World: Why Internet Apps and Databricks-Native Apps Need Different Designs

In practice, MCP solves different problems depending on where your UI lives.

The image above captures the two most common enterprise realities:

1. An internet-facing application (Lovable / Web)

2. A Databricks-native application (internal, governed)

Same concept.
Very different responsibilities.

Let’s walk through both — step by step — using only the flows shown in the diagram.

Case 1: Internet-Facing MCP Flow (Lovable / Web)

This is the top flow in the image.

Here, your UI is public-facing — running on the open internet.

That single fact changes everything.

What this environment looks like

You are dealing with:

• Untrusted clients

• OAuth / SSO boundaries

• Network exposure

• Audit and compliance requirements

• The need to strictly control what can touch data

In this world, MCP is not optional — it becomes a hard architectural boundary.

The actual flow

What’s really happening here

• The UI never talks to the Agent directly

• The UI never touches tools

• The Agent never touches data systems

The MCP Server acts as a gateway:

• It authenticates requests

• Enforces permissions

• Executes tools

• Audits everything

• Returns only safe results

This is why internet-facing systems often end up with domain-specific tools like:

• execute_query_sales

• execute_query_finance

• search_pdf_sales_docs

Not because it’s elegant — but because explicit separation is safer than implicit trust.

In this setup, MCP is a security and execution layer, not just a protocol.

Case 2: Databricks-Native Managed MCP Flow

Now look at the bottom flow in the image.

Here, everything lives inside Databricks.

That changes the role MCP needs to play.

What this environment looks like

• The UI is a Databricks App

• The Agent runs inside Databricks

• Identity, permissions, and access are already governed

• Unity Catalog enforces data access

There is no untrusted client crossing the perimeter.

The actual flow

What’s different here

• The UI can safely call the Agent

• The Agent can safely request tool execution

• The Managed MCP Server executes tools inside the same trust boundary

• Unity Catalog enforces access at query time

You don’t need:

• Domain-split tools

• Multiple gateways

• Custom permission logic per tool

Instead, you get generic tools like:

• execute_sql

• vector_search

And governance happens below the tool, not inside it.

Here, MCP is not a security gateway — it is a clean execution contract.

The Rule That Explains Both Flows

Everything in this post collapses into one rule:

The Agent is the brain.
MCP is the hands.
The UI talks only to the brain — never to the hands.

And one more:

The Agent never touches data systems directly.
Only MCP tools touch data systems.

The difference between the two flows is not MCP itself —
it’s how much responsibility MCP must carry.

Why This Distinction Matters

If you ignore this distinction:

• You over-engineer internal systems

• You under-secure internet-facing ones

• You blur reasoning and execution

• You create audit and blast-radius problems later

If you design MCP correctly:

• Your architecture scales from chat → agent → multi-tool systems

• Security becomes composable

• Governance becomes declarative

• The system remains explainable to humans

Final Thought

MCP is not “another AI framework.”

It’s an architectural contract that answers one question clearly:

Who is allowed to touch reality?

Once that is clear, everything else falls into place.