The Lofty MCP server is advertised as a way for outside AI systems to retrieve information and take authorized actions inside Lofty. Brokerage buyers therefore need to evaluate both access to records and authority to act. Lofty’s announcement describes those capabilities; it does not, by itself, demonstrate detailed permissions, auditability or operational results.

The company’s release carries a September 24, 2026 dateline, while its newsroom lists September 28. The wire announcement was published September 28 at 8:27 a.m. Eastern. Neither date establishes when customers first obtained access.

This assessment concerns Lofty’s own announced product. It reviews documentation and does not report a test of the server.

What the Lofty MCP server connection changes

MCP stands for Model Context Protocol. Its November 2025 tools specification describes how AI applications can discover and call functions exposed by another system, including functions that query data or invoke an application interface. That explains the mechanism; it does not establish which functions Lofty has implemented.

For leaders evaluating AI and automation in housing, the key procurement question arises where an answer becomes an action. A useful analysis can still lead to an unsuitable change if the assistant selects the wrong record, assignee or next step.

Evaluate three stages separately:

Lofty’s launch release describes retrieval, analysis and workflow initiation, but does not provide an operation-by-operation catalog. It should not be used to infer support for particular delete, messaging or administrative operations.

Separate retrieval from Lofty MCP write access

Consider a hypothetical pilot that identifies leads needing attention and then creates follow-up tasks. Assume Lofty confirms that the required operations are available for the brokerage’s account.

Reading lead history and producing a proposed task list can be evaluated before anything changes in the CRM. Creating the tasks introduces additional decisions: which lead each task belongs to, who receives it, when it is due and whether an equivalent task already exists.

Ask the provider to demonstrate those stages separately. First inspect the retrieved records and proposed changes. Then approve a limited action and compare the resulting CRM record with the proposal. Repeat the request to see whether the workflow recognizes work already completed.

That exercise tests a specific business process. A demonstration that an assistant can find a contact does not establish that it can safely manage a sequence of changes involving that contact.

Whose brokerage CRM permissions govern a connection?

The dated announcement refers to authentication controls and authorized actions, but does not identify the governing account or supply a permission matrix. The account model therefore remains unestablished by that document.

Before approving access, request a diagram showing the person using the assistant, the identity presented to Lofty and the permissions applied to each requested operation. Ask whether the connection can have narrower rights than that identity ordinarily possesses.

Use the intended operating role in the demonstration. If a pilot is designed for an individual agent, an administrator’s successful demonstration does not answer whether the agent’s connection respects record ownership and team boundaries.

Permission to perform an operation also differs from approval of a particular use. Even an authorized task creation may have the wrong recipient or due date. Decide which actions require a person to review the proposed change.

What implementation work remains with the brokerage?

Lofty says the connection does not require custom integration code. That is a statement about connectivity; it does not establish the work needed to deliver a brokerage-specific process. September 28 wire release

As with other brokerage technology, assign technical ownership before committing to a custom Lofty AI integration. The implementation scope should identify who selects and configures the assistant, manages credentials, defines allowed actions, handles failures and maintains the workflow when either system changes.

An operations manager must also define the business task precisely. In the hypothetical follow-up pilot, “find neglected leads” needs an agreed interpretation of recent activity and prior contact. Ask for the underlying records so reviewers can distinguish a sound recommendation from an attractive explanation.

Include testing of risks when AI reads external material in that scope. Specify how the workflow should behave when a retrieved note contains instructions that conflict with the brokerage’s intended task.

Which access and audit details need evidence?

The dated launch release does not specify granular access settings, log contents or retention, credential revocation timing, or recovery from an incorrect action. These omissions describe the limits of the announcement; they do not prove the product lacks those controls.

Request concrete evidence before production approval:

The MCP tools specification recommends human oversight and asks AI clients to provide confirmation for sensitive operations and logging of tool use. Assign those responsibilities explicitly across the client and server. These protocol recommendations do not establish Lofty’s implementation.

Make the next purchasing milestone a limited pilot with explicit acceptance criteria. Measure useful work completed, incorrect or duplicate changes, and staff time spent reviewing and correcting results. Expand access when the workflow and its controls meet those criteria.