CRE MCP Servers: Vendor vs Custom, 4 Options Compared

By Jude Lee · September 30, 2026 · Custom

Why brokerage software vendors are suddenly announcing “MCP servers”

If you saw the HousingWire item that Lofty launched an MCP server for brokerages and had no idea whether it mattered to you, you’re in good company. Lofty is residential-focused, and the precise scope of what that server exposes is worth reading in the announcement and in Lofty’s own developer documentation rather than taking from a secondhand summary. The direction of travel is the point: instead of building a chatbot inside their own app, vendors are exposing their data and actions through a standard protocol so your AI assistant can use them. Commercial platforms will follow.

MCP is an open specification — originally released by Anthropic and documented publicly at modelcontextprotocol.io — that defines how an AI client discovers and calls tools and data sources. It is not a product and not a lock-in. Think of it as a socket. A vendor building an MCP server is saying: “here are the specific things an outside AI is allowed to look at or do in our system, with your credentials and your permissions.”

What an MCP server actually does in brokerage terms

Without MCP, getting an AI to answer “which of my office listings have had no tour activity in 30 days?” means someone exports a CSV, pastes it into a chat window, and hopes the columns survived. With MCP, the assistant calls a tool — list_active_listings, get_tour_activity — gets structured data back, and reasons over it. Add write tools and it stops being a research assistant and starts being an agent: log the call, update the stage, draft and queue the owner email.

The important nuance: an MCP server defines the surface area. Read-only tools mean the agent can never overwrite a deal record. Scoped tools mean it can update pipeline stage but not commission splits. That granularity is the whole governance story, and it’s why this topic belongs to an ops manager and not only a developer.

The four ways to get an AI agent onto your data

1. Manual exports and copy-paste

The baseline. Someone pulls a report, drops the file into Claude or ChatGPT, asks the question. Zero engineering, zero new vendor risk, and genuinely fine for one-off analysis — a single rent roll, a one-time comp set, a pitch prep. It breaks when the task is recurring, when freshness matters, or when the answer requires joining CRM records to email history to a deal folder. It also leaves data handling to individual judgment, which is how ungoverned AI use quietly takes root in a brokerage.

2. Vendor-shipped MCP servers and built-in AI features

Your CRM or listing platform exposes an MCP endpoint, or ships its own AI assistant inside the app. Lowest effort, vendor-maintained, and cost is usually bundled into a subscription you already pay. The limits are structural: the tools are the ones the vendor chose to build, the data is only that vendor’s data, and you’re on their roadmap.

One caveat that gets glossed over — permissions do not automatically inherit from the roles you’ve already set up. A vendor MCP endpoint authorizes through OAuth, and the token scope it grants can be broader than the in-app role of the user who approved it (read-all-records rather than read-my-team’s-records, for example). Before you treat vendor permissions as “already governed,” read the consent screen and the vendor’s scope documentation, and test with a restricted user account.

3. Connector platforms (Zapier, Make, n8n)

These now offer MCP-style access to hundreds of apps. Broad coverage, no code, fast to stand up. The trade-off is that generic connectors expose generic actions — “create record,” “send email” — not brokerage concepts like “advance this listing to call-for-offers and notify the tour list.” They also meter on runs, which gets expensive at high volume. We compared the economics in Zapier vs Make vs n8n vs a custom MCP agent.

4. A custom MCP server over your own systems

You build a thin server that defines tools in your firm’s vocabulary and talks to whatever sits behind them — CRM API, document store, commission spreadsheet, county assessor lookups. Highest control, highest maintenance burden, and it only pays off when the workflow is repeated, spans systems, and follows firm-specific rules.

Those hour figures are planning placeholders, not measured benchmarks — swap in your own scoping estimate and your own rate. The point is that a custom server has two cost lines (build and upkeep), and teams routinely budget the first and forget the second.

A worked example: the Monday pipeline question

Here’s a representative one, of the kind an investment-sales desk asks every week: “Which active listings have a call-for-offers date inside 21 days, no signed NDA from a top-ten buyer in that asset class, and no broker touch in 10 days — and draft the follow-ups.”

• Manual: three exports, a spreadsheet, an hour of an analyst’s Monday.
• Vendor MCP: answers the listing and activity parts if all of it lives in that CRM. Silent on NDAs sitting in your data room.
• Connector platform: can be wired, but you’re assembling five generic steps and maintaining the glue.
• Custom MCP server: one tool call each to listings, NDA status, and activity log; the agent joins them and drafts emails into a review queue.

Two things stay human in every version. First, sending — drafting is cheap and reversible; an unreviewed email to a principal is not. Second, and less obvious: agents answer confidently from stale or partially-synced fields. If a broker logged a tour in their inbox but never in the CRM, or a nightly sync failed, the agent will report “no touch in 10 days” with total assurance. The countermeasure is to require every agent answer to cite record IDs and last-modified timestamps, so a reviewer can spot-check two or three rows against the source of truth before anything goes out. That’s the same autonomy boundary we mapped in agent autonomy levels.

Further reading: our CRE CRM comparison is a reasonable proxy for what each platform is likely to expose, since a vendor can only surface what it already stores.

Why percentage-based AI trust rules don’t survive contact with a deal

You’ll see a “30% rule” for AI circulated online — sometimes meaning “only trust AI for about 30% of the judgment,” sometimes “never let AI touch more than 30% of a deliverable unreviewed.” There is no standard-body definition behind it. Treat any confident version as opinion, including ours. The operational substitute we’d suggest: write down, per workflow, what the agent may do unattended (read, summarize, draft), what requires a named reviewer (anything client-facing, anything with a dollar figure), and what it may never do (send offers, alter commission records). That’s enforceable; a percentage isn’t.

Whether any of this replaces brokers

The honest read: agents are very good at retrieval, structuring, drafting, and never forgetting a date. They are bad at the parts brokers get paid for — reading a principal’s real motivation, pricing judgment in a thin comp set, and being the person whose name is on the recommendation. What’s genuinely exposed is task volume in coordination roles, which is why ops teams should be designing these agents rather than waiting to be designed around.

How to decide

1. Write the five questions you actually ask every week

   If four of five can be answered inside one platform, a vendor MCP server or built-in AI is probably enough.
2. Count the systems each question touches

   Cross-system questions are the signal for a custom server. Single-system questions almost never justify one.
3. Separate read from write

   Start read-only. Add write tools one at a time, each with an audit trail and a named reviewer.
4. Model the payback with your own numbers

   Annual value = hours per week on the task × loaded hourly rate × 52. Annual cost = your build estimate (use the 60-hour placeholder above until you’ve scoped it) × blended dev rate, plus quarterly upkeep hours × the same rate, plus model and hosting spend. Then ask the harder question: do the recovered hours go to pipeline work, or just disappear?
5. Pilot on one desk for a month

   Compare agent output to what the team would have produced. Keep a log of misses — that log is your spec for version two.

The practical answer to “which AI tool is best for commercial real estate” is that the model matters less than the connection. A strong assistant with no access to your listings is a writing tool. A mediocre one wired correctly to your CRM, inbox, and document store is an operations hire. Vendor MCP servers make that wiring cheaper to start; custom ones make it match how your firm actually works. Most brokerages will end up running both.

Related guides

Custom Oct 12, 2026

What Data Can Your CRE AI Agent Use? 4 Sources Compared

Licensed market data, public records, your own CRM, or the open web — a vendor-neutral comparison of what commercial real estate data an AI agent can actually use.

Read guide →

Custom Sep 21, 2026

AI Agent Skills for CRE: 4 Ways to Standardize Them

Open-source AI agent skills for commercial real estate are multiplying. Compare prompt libraries, vendor AI, borrowed skill packs, and custom skills + MCP.

Read guide →

Custom Aug 20, 2026

JLL GPT vs Your Own CRE AI Agent: What to Copy

AI JLL GPT explained honestly — what enterprise CRE AI actually does, and how mid-size brokerages compare off-the-shelf tools vs a custom MCP agent.

Read guide →