RESO has built or retooled several new products for our members to make accessing, analyzing and certifying MLS data feeds easier. They include a Desktop Client (an application that is installed on your computer and runs locally) and a Web Client (a version that runs in your browser and offers the same core tools).
There is also a RESO Reference Server, new Data Dictionary site and Client SDK with supporting libraries (including Add/Edit and EntityEvent support).
RESO CTO Joshua Darnell walked through these tools in a recorded webinar.
Note: RESO Tools are in community preview, and the new certification suite for Data Dictionary 2.1 and Web API Core (2.0.0 and 2.1.0) is in final testing. Organizations seeking immediate certification should continue to use the RESO Certification Utils for Data Dictionary 2.0 and the RESO Commander for Web API Core 2.0.0 until notified otherwise. Contact dev@reso.org with any questions.
During the webinar, several questions were asked in the live chat. The Q&A is reproduced below.
Q: Which open source license are RESO tools distributed under?
A: The RESO tools are in community preview today under the RESO EULA. The SDK packages and CLI tools will continue under that license. The Desktop Client, Web Client and Data Generator will move to a non-redistributable model – licensing for those can be arranged by contacting dev@reso.org.
Q: Where is the new Data Dictionary site located?
A: dd.reso.org
Q: Where can we provide feedback for feature requests?
A: Open new tickets on GitHub or email dev@reso.org.
Q: Does the RESO Desktop Client automatically update if there are newer updates?
A: Until the app is signed, you will get a notification and need to reinstall manually. Once signed, the app will update automatically. RESO is waiting on Apple for review and signing. The signed Windows version will follow once testing wraps, which is expected mid-May 2026.
Q: On a Mac, I’m getting a message that says the RESO Desktop Client is damaged and can’t be opened.
A: The apps are not signed yet, so macOS will block them by default. You will need to allow them via Gatekeeper – instructions are in the release notes.
Q: Should RESO be only used for MLS, or is it also recommended for custom platforms and off-MLS listing sites like Airbnb?
A: RESO started for the MLS industry and now develops data standards for any organization in the real estate space. See transport.reso.org for available specifications. Airbnb has not adopted RESO standards. Either Airbnb or a provider integrating with their data could write a translator into RESO Common Format, a lightweight JSON representation of the Data Dictionary.
Q: The reso-mcp-server exposes tools for AI agents. How does it handle authentication scoping when an AI agent is querying sensitive listing data, and is there a permission model beyond OAuth2 client credentials?
A: From the RESO MCP Guide: AI agents never touch provider APIs directly. The MCP Server sits between the AI and the data. The agent forms queries and interprets results, while RESO’s certified OData Client handles all API communication and authentication.
The MCP Server connects via the RESO Client and inherits whatever auth the underlying Web API supports – bearer tokens or OAuth2 client credentials. The destructiveHint annotation gives clients a tool-level scoping signal, so they can require user confirmation before write operations. Providers shape access through their own credentialing (e.g., IDX-only vs. Back Office, or granting or withholding Add/Edit). The RESO Cloud MCP Server adds another auth layer on top.
Q: Are there any plans to support natural-language querying on top of the OData layer? For example, letting an agent or end user ask something like “Show me all listings over $500K in Saskatoon with a garage” and having it auto-translate to a valid $filter expression?
A: The RESO MCP Server does this today. The example in the question – “show me listings over $500K in Saskatoon with a garage” – is exactly the workflow it supports. A user types or speaks plain language; the MCP Server combined with the RESO Client translates the request into a valid OData query – filtering, ordering, fetching the top results, pulling in related resources like Media, and other OData operations. The user does not need to know OData.
Q: After a search, can you export results to a .json file or maybe directly to .xlsx?
A: Export to JSON (and to .xlsx, including media) ships with v0.11.
Q: Does the Add/Edit endorsement (RCP-10) require two separate API calls, one to validate and one to commit, or can a single request handle the full write operation?
A: Under RCP-10 (Add/Edit) alone, validation is reactive – the client posts and the server returns any errors, so behavior depends on the provider’s rules. A single request can handle the full write when the provider also exposes its rules through RCP-19 (RESO Validation Expressions), which lets clients evaluate before sending. More providers support RCP-10 than RCP-19 today, so a robust client supports both.
Q: Do you have a Reference Server for Data Dictionary 1.7?
A: Yes, RESO can spin up a 1.7 Reference Server, but DD 1.7 has been superseded by 2.x, which is a superset of 1.7 and includes additional standard data elements. If you have specific 1.7 testing needs, contact dev@reso.org.
Q: Is the ID number advertised based on the MLS platform storing the data, the vendor that will be using the data or the API that’s transmitting the data?
A: RESO recognizes three identifiers at the organization level: the Provider UOI (Unique Organization Identifier), the Provider USI (Unique System Identifier) and the Recipient UOI. The Recipient UOI is usually an MLS but can also be a vendor, brokerage, pooled platform or commercial system. Records can also carry OriginatingSystemID, OriginatingSystemName, SourceSystemID and SourceSystemName – not all systems populate these, but when present they are set by the publishing system and travel with the data.
Q: How can you dig down into individual fields and see enumerations and compliance and look at the metadata?
A: The Server Explorer in the Desktop Client surfaces this. More info can be found in the RESO Desktop Client Guide.
Q: Why is the IDX payload so different between vendors (e.g., 62% vs. 100%)?
A: Vendors expose different fields based on what each MLS supports in its system. The provider certifies the MLS’s implementation and produces a report the MLS reviews and approves. Industry Alignment Reports and RESO Insights help both sides identify opportunities to adopt more standard data elements, including in the IDX Payload. MLSs should consult both during the certification review. Providers and MLSs can contact dev@reso.org for more info.
Q: As an MLS, How do I find information for our system?
A: To view your certification reports, open the Organizations section of the Desktop Client, find your org, and click View Summary. If you are not using the new RESO Desktop Client, you can search for your organization at certification.reso.org. Approved results appear as Certified.
Q: Will the certification information still be available online or will the desktop client be a requirement to get data? Will the desktop client ever be hosted instead?
A: The certification results will always be available online at certification.reso.org. The Desktop Client previews the new Cert UI today; reports and variations review migrate to certification.reso.org in a Phase 1 release covering the endorsements list, summary and detail reports, and account settings. Running certification tests stays local – providers need to pass local tests before starting cloud jobs. Connection Manager and Server Explorer may follow online if there is demand.
Q: Is there a way to view the vendor’s field mapping from the source? Basically, what field from the source was mapped to the vendor’s RESO standard field? This can be confusing in debugging (e.g., City/PostalCity/Township/etc.) It would be extremely helpful to know without having to open a ticket with each vendor in each situation.
A: Source-to-RESO mappings are internal to each vendor and not currently exposed in a standard way over the Web API. The Variations Review in the RESO Desktop Client surfaces fields that diverge from the Data Dictionary, which helps spot ambiguous mappings without contacting each vendor.
Vendors who want to publish their mappings today can use the DD reference sheets with an added column for the native source field name, type and constraints. Vendors can also convey this through the standard Field and Lookup resources by adding local fields to those resources. If demand for a standard mapping mechanism grows, RESO could potentially discuss standardization.
Q: Is everyone’s test results available as an open book to view or just the tests we run on our own data?
A: Test results are not public until both the provider and the certification recipient – typically an MLS – review and approve them. Approved results appear at certification.reso.org. Performance results can be opted out, though both parties always see them. During the webinar, RESO connected to other systems with the same credentials used for certification testing. Contact your vendor for credentials or use your existing ones.
Q: Will MCP answer questions only related to RESO metadata? What if you ask for market stats for a city?
A: The MCP Server queries data, not just metadata. A request like “show me listings under $500K in Sacramento with a garage” turns into an OData query against the provider’s Property Resource, without the user needing to know OData.
The AI agent can summarize what comes back, so simple aggregate questions like “average price in Austin” work as long as the underlying data is accessible.
Local fields outside the Data Dictionary work, too, especially when they have meaningful names or OData annotations. The RESO Client returns all annotations the server publishes. Standard Data Dictionary fields give the AI more context to work with. The RESO Client understands the Data Dictionary’s definitions, types and allowed values, so queries against standard fields tend to be more precise.
Q: Is there a compliance validation hook that runs before a record is committed?
A: Under RCP-10 (Add/Edit) alone, validation is reactive – the client posts, the server returns any errors. Under RCP-19 (RESO Validation Expressions), the server publishes its business rules in a form the client can read, so the client can check a record before sending it. RCP-19 is the pre-commit option; RCP-10 is the fallback when a provider has not yet published rules.
Q: Having a human in the middle would be nice to add to the MCP server tools. Is that a possibility?
A: Yes, and the MCP Server already supports this. Destructive tools (writes, deletes) are flagged with a destructiveHint, so the AI client can require user confirmation before invoking them. An agent attempting a write surfaces a “do you want to proceed?” prompt to the human before anything happens. Read-only tools are flagged separately, so the client can skip the check on safe queries.
Q: What is the Data Generator?
A: The Data Generator produces realistic test data that links together correctly – a listing’s agent points at a real estate agent record, an open house at a real estate listing and so on. It is available as a command-line tool, a programmatic library and a panel inside the RESO Desktop Client.
It works in two modes. Pointed at an existing RESO Web API server, it generates test data against the live system – the server does not need to be certified, only to publish valid metadata. Pointed at a metadata report alone, it stands up a complete server populated with realistic data. Use it to fill a Reference Server, support integration testing or produce disposable records for AI agent testing.
Q: Should I contact RESO to get the bearer key?
A: Yes, contact dev@reso.org.
