Case Study 05
Portfolio build — a complete, working system built and measured by Altus Initiatives to demonstrate this capability. Performance metrics below are measured from the build; agency-impact figures are projected for a representative brokerage.
As real estate agencies adopt AI tools — internal assistants, client-facing agents, workflow automation — they run into a consistent barrier: the AI can reason fluently, but it can't access the business's actual data. It doesn't know who your clients are. It doesn't know your current listing inventory. It can't check your service process or answer questions about your fee structure. Every time the AI hits the edge of its general knowledge, it either guesses or says it doesn't know.
The standard workaround is to build a custom integration for each AI tool and each data source — one connector for an internal assistant, another for an automation workflow, another for a client-facing agent. Every new AI tool the business adopts means another custom integration to build and maintain. The cost and complexity compounds with every addition.
The deeper problem is rigidity. Hard-coded integrations break when systems change, can't adapt to new AI capabilities, and require developer intervention to modify. For a brokerage that wants to grow its AI capability over time, this approach doesn't scale.
A custom MCP server that acts as a universal, secure bridge between the agency's internal systems and any AI agent or platform that supports the Model Context Protocol — which includes Claude, ChatGPT, n8n, Make.com, and every other major AI platform.
Build the server once. Connect it to any AI tool, now and in the future, without rebuilding the integration.
One bridge, every AI tool
For a brokerage with multiple AI tools in use — or planning to adopt them — a custom MCP server eliminates the integration fragmentation that makes AI deployments expensive to maintain and brittle to change.
┌─────────────────────────────────────────────────────────┐
│ MCP Server │
│ │
│ Tools (dynamic) Resources (static) │
│ ├── Client & contact lookup ├── Agency knowledge base │
│ ├── Listing & service search └── Service catalog │
│ └── Time & scheduling │
│ │
│ Data sources: │
│ ├── contacts and client records │
│ ├── listing and service catalog │
│ └── policy and FAQ documentation │
└──────────────────┬──────────────────────────────────────┘
│
┌─────────┴─────────┐
│ │
▼ ▼
Local transport Remote transport
(direct AI (cloud platforms:
assistant) n8n, Make.com)
│
▼
AI Agent Workflow
(MCP client connection)
│
▼
Accurate responses
grounded in live business data
Full architecture documentation available upon engagement.
| Component | Tool |
|---|---|
| MCP server | Python MCP SDK |
| Local transport | stdio (subprocess) |
| Remote transport | SSE (HTTP) via Starlette + Uvicorn |
| Integration platform | n8n |
| Data sources | Structured files (contacts, listings, catalog, FAQ) |
| Protocol | Model Context Protocol (MCP) |
Tools for dynamic data, resources for static knowledge. The server exposes two distinct access types for a reason. Tools are used for data that requires querying — contacts and listings are searched by input parameters and return filtered results. Resources are used for reference material the AI reads in full — the FAQ and service catalog don't need filtering, they need to be available as complete context. Using the right access type for each data category keeps the server clean, predictable, and fast.
Tool descriptions as behavioral contracts. Each tool's description specifies not just what it does, but when to use it — giving the AI a decision rule, not just a capability label. Vague tool descriptions produce inconsistent tool selection. Precise, authoritative descriptions produce reliable behavior across every query type. This is a design principle applied to every tool-use implementation Altus builds.
Remote transport for platform independence. The remote configuration enables integration with cloud platforms that can't reach a local subprocess. Any platform that supports the MCP protocol — n8n, Make.com, or any future platform the agency adopts — connects to the same server without modification. The transport layer is swappable; the business logic underneath is unchanged.
Data in files, not code. All business data — contacts, listings, catalog, documentation — is stored in external files loaded at runtime rather than hardcoded into the server. Updating the agency's data requires editing a file, not modifying server code. The team that owns the data can maintain it without developer involvement.
A custom MCP server is the right investment for agencies in one of three situations:
Using AI tools internally but hitting data walls. Teams that have adopted an AI assistant workflow and find the AI can't access their internal systems — CRM data, listing inventory, client records, policy documentation. A custom MCP server gives every existing AI tool accurate access to real business data without rebuilding anything else.
Running AI agents that need to act on business data. Agencies with n8n or Make.com AI agent workflows that currently rely on hard-coded data feeds or manual inputs. An MCP server replaces brittle custom integrations with a standardized, maintainable capability layer the agent can call dynamically — and that any future agent can also use.
Deploying AI across multiple platforms simultaneously. Brokerages that want their data accessible across multiple AI tools — an internal assistant, a client-facing agent, and an automation workflow — without maintaining a separate integration for each one. One MCP server serves every platform.
This system is production-ready at the server logic level. A full client deployment includes the following standard additions:
This is the same architecture we build for clients. The first step is a 30-minute discovery call — no pitch, no commitment.
Book a discovery call