Who Builds MCP Servers and AI Agent Systems for Real Estate Firms?

The Short Answer

Four kinds of firms will offer to build your MCP servers and AI agent systems, and they are not interchangeable. Strategy firms write the roadmap and stop before anything connects. Offshore dev shops build whatever you spec but bring no judgment on what is worth building and no real estate feel. Product vendors sell you their own cloud, which is right when your job is standard and wrong when your edge is a workflow only you run. Implementation partners do both jobs: they advise on what to build, then connect your systems, build the agents, enforce the governance, and hand you a system your own team can run. For a firm whose edge is a specific workflow across its own systems, the implementer seat fits, and you test any candidate by asking to see a live agent connected to a real system before you sign.

Why "Who Grants Access" Is the Wrong Question

A lot of buyers start by asking who can give them access to MCP, as if it were a gated platform. It is not. MCP is an open standard. Anthropic introduced it and open-sourced it, OpenAI adopted it across its products in March 2025, and Google said it would support it in its Gemini models in April 2025, with Demis Hassabis calling it a good protocol that is rapidly becoming an open standard for the AI agentic era (TechCrunch). When the three largest model providers all back the same standard, nobody owns the gate.

So the real question is not who grants access, it is who connects it. The protocol being open means the scarce thing is the implementation: wiring your CRM, data room, and reporting stack to an agent, building governance so it is safe with investor data, and handing over something your team can operate. If MCP itself is still fuzzy, our guide to MCP for real estate firms covers the mechanics. This piece is about who you hire.

The Four Delivery Models, Side by Side

Every provider you talk to sits in one of four archetypes. The differences are not about talent; they are about which parts of the job the model is built to do. Read the table by asking which columns you need filled, because a firm that only writes roadmaps and a firm that only builds to spec will each leave you holding a different half of the work.

No archetype is wrong in the abstract. A strategy firm is the right call when you genuinely do not know what to do and need an internal case built. A dev shop is right when you have a strong product owner and a locked spec. A product vendor is right when your need is a standard job their product already models well, which is a real and common situation we treat honestly in MCP versus off-the-shelf proptech AI. The implementer seat earns its keep specifically when your edge is a firm-specific workflow that spans systems only you run together, and you want the advice and the working system from the same accountable party.

Why the Split Matters More in Real Estate

This taxonomy is not academic, because real estate AI has a brutal finishing problem. In JLL's 2025 Global Real Estate Technology Survey of more than 1,500 senior decision-makers, 88% of investors, owners, and landlords had started piloting AI, running an average of five use cases at once, yet only 5% said they had achieved all their program goals (JLL). Starting is easy; finishing is where firms fall down.

The seats that only do half the job are a big part of why. A strategy engagement produces a roadmap that never gets wired in. A product pilot demos well on the vendor's data and then stalls when it meets your actual pipeline. A dev shop builds exactly what the spec said, which was not what the deal flow needed, because nobody in the room understood the deal flow. The 5% who finish had someone accountable for the whole arc, from what to build through a system running on their own infrastructure. That end-to-end accountability is the implementer seat.

How to Tell a Builder From an Advisor

Everyone in this market now claims to do strategy and implementation, so the label on the tin is useless. Here is the test that cuts through it.

• Ask to see a live agent on a real system. Not a slide, not a scripted demo on fake data. A working agent reading from an actual system it is connected to. Firms that only advise cannot produce one.
• Ask where it runs and who holds the keys. The answer you want is your infrastructure, under your governance, with no lock-in. A vendor whose answer is their cloud is selling you a product, which may be fine, but you should know that is what it is.
• Ask how writes are gated. A serious builder gates irreversible actions behind human review and can explain exactly where those checkpoints sit. Vagueness here means they have not built enough of these.
• Ask who maintains it after launch, in writing. A system nobody on your side can run is a dependency you rent. The handover should be a deliverable, named and dated.

"Ask to see a live agent connected to a real system before you sign. Everyone can talk about agents now. The firms that have actually built them can show you one running against real data in the room, and the ones that cannot will change the subject." Lucas Eschapasse, NextAutomation

We hold ourselves to the same test. The proof we point to is systems running, like the off-market deal sourcing engine we built, not a roadmap or a reference call. The full framework for evaluating a partner lives in our guide to AI consulting for real estate.

When the Implementer Seat Is Not the Answer

Honesty is the whole pitch here, so it cuts both ways. If your bottleneck is a standard job an existing product already solves well, hire the product vendor and skip the custom build. If you have deep in-house engineering and a crystal-clear spec, a dev shop is cheaper and perfectly adequate. If you are genuinely at zero and need an internal case before spending, a strategy engagement might be the honest first step. The implementer seat is the right answer for one specific situation: your edge lives in a workflow across your own systems, no product models that workflow, and you want one accountable party to advise, build, deploy on your infrastructure, and hand it over.

The deeper build-or-buy decision underneath this, whether your firm should commission a custom MCP server at all, deserves its own read, and we lay it out in should your firm build a custom MCP server. If the answer there is yes, the standing owner of the program, accountable for what gets built, how it is governed, and whether it keeps delivering, is a fractional Chief AI Officer.

Where to Start

You do not need to pick an archetype before you understand your own situation. The first step is a scoping conversation about which systems hold the data that matters, which one workflow would pay for itself first, and whether your need is a standard job or a firm-specific one. If an off-the-shelf product covers you, we will say so and you will have saved a year. If your edge is a workflow spanning your own systems, you will leave knowing what to build first and how to tell a real builder from a slide deck. Book a scoping call and we will start with your systems and your governance, not a pitch.

Frequently Asked Questions

Who builds MCP servers and AI agent systems for real estate firms?

The market splits into four seats. Strategy firms write you a roadmap and stop before anything connects. Offshore dev shops build to spec but carry no view on whether the thing is worth building and no real estate judgment. Product vendors sell their own cloud, right when your job is standard and wrong when your edge is a workflow only you run. Implementation partners both advise and deploy, connecting your systems, building the agents, enforcing governance, and handing over a system your team can run. For a firm whose edge is a specific workflow across its own systems, the implementer seat is the fit.

Do I need special access or a license to use MCP?

No. MCP is an open standard, not a product you license. Anthropic introduced it and open-sourced it, and OpenAI and Google have both adopted it, so the connection layer is available to anyone. That changes the question you are shopping for. You are not buying access to MCP; you are hiring someone to connect your specific systems to it, build the agents that use it, and enforce the governance around it. The scarce skill is the implementation and the real estate judgment, not the protocol.

What is wrong with just hiring a general software development shop?

Nothing, if you already know exactly what to build and why. A capable dev shop will build what you spec. The gap is judgment: they carry no view on whether the workflow you asked for is the one worth automating, no feel for how a deal actually moves through a real estate firm, and usually no governance model for investor data. You end up owning the requirements risk and the real estate thinking yourself. That works when you have a strong internal product owner and fails when you were hoping the partner would bring that thinking.

How do I tell an advisor from a builder when they all claim to do both?

Ask to see a live agent connected to a real system, not a slide deck or a sandbox demo on fake data. An advisor who only advises cannot show you one. Then ask where the system would run, who holds the keys, how write access is gated, and who maintains it after launch, in writing. Builders answer these concretely: your infrastructure, your governance, human checkpoints on consequential writes, a named maintenance owner. Firms that only strategize get vague. The live-system test separates the two faster than any credential.

Why do so many real estate AI projects stall at the pilot stage?

Because piloting and finishing are different problems, and most partners are only equipped for the first. In JLL's 2025 survey of more than 1,500 senior decision-makers, 88% of investors, owners, and landlords had started piloting AI, running an average of five use cases at once, yet only 5% said they had achieved all their program goals. The pilots stall because nobody connected them to the firm's real systems and nobody owned the governance and handover. That connection-and-handover work is exactly what the implementer seat exists to do.

What should the partner hand over at the end?

A system your own team can run, on infrastructure you control, with no lock-in to the partner's platform. That means the MCP servers run in your environment, the governance and access model are documented, and someone on your side can operate and audit the system without the builder in the room. If what you get is a dependency that only works while you keep paying the vendor who built it, you rented a capability rather than acquiring one. Insist on the handover before you sign.