MCP-first data layer

Your AI feature does not need a connector, it needs a tool

Every endpoint exposed as an MCP tool, so the model calls the data directly.

Propalt Team · For PropTech platforms

When you add an AI feature to a property platform, the model is only as useful as the tools it can call. Ask an assistant about a specific property and, without live data, it will produce a plausible answer rather than a correct one. The usual fix is to build a connector: wrap each endpoint in a function, describe it to the model, handle the call and marshal the result. That connector layer is real work, and it has to be maintained every time the endpoint or the model changes.

The fair caveat is that MCP is a young standard, and betting a feature on a standard still settling is a legitimate concern. The counter is that MCP is where the major assistants have converged: Claude and ChatGPT both call tools through it, so an MCP-first data layer targets the interface those models already speak rather than a proprietary one you would have to re-wrap per platform. You are not betting on a niche protocol; you are integrating against the one your AI features are most likely to use anyway.

Every endpoint is already a tool

The Propalt data layer exposes each endpoint as an MCP tool, described the way a model expects to receive it. get_property and get_comparable are not just REST routes you have to wrap; they arrive as tools your assistant can select and call directly. The tool definitions carry the schema and the parameters, so the model knows what to send and what it will get back without a translation layer you wrote and now own. Dropping the data layer into an in-product AI feature is configuration rather than connector code.

The REST API and the OpenAPI 3.1 spec are still there underneath, for every part of your platform that is not an assistant. That is the point worth keeping in view: MCP-first does not mean MCP-only. Your batch jobs, your property pages and your back-office tools call the same endpoints over plain REST, while your AI features reach them as tools, and both paths resolve against the same data. You choose the access pattern per surface instead of maintaining two separate integrations.

The mapping above is illustrative. The consistent part is that every surface reaches the same endpoints, whichever pattern suits it.

Build the feature, not the plumbing between the model and the data

The value of an MCP-first layer is where your engineers spend their time. Without it, a meaningful share of an AI feature is connector code: wrapping endpoints, describing them to the model, keeping the descriptions in step with the API. With the endpoints already exposed as tools, that share collapses, and the work becomes the behaviour of the feature: what the assistant is for, how it responds, where it fits your product.

When the data layer is already a set of tools, the AI feature is the prompt and the product, not the plumbing.

That matters most as your platform's AI surface grows. A second and third assistant feature reuse the same tools rather than each needing its own connector, so the marginal cost of the next AI feature falls instead of repeating. An MCP-first data layer is not a novelty for its own sake; it is the shortest path from a property dataset to a model that can act on it, across every AI feature you ship.

Give the model the tools and let your team build the feature.

Try the MCP-first data layer → · propalt.ai

Data is drawn across 29 million England and Wales properties from 8 authoritative UK registers plus the Propalt intelligence layer. Figures shown are illustrative. This article is general information for platform teams.