constellation1-mcp-server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@constellation1-mcp-serverfind active properties in Seattle under 1 million"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Constellation 1 MCP Server
A Model Context Protocol (MCP) server that provides comprehensive access to Constellation 1 real estate data APIs. This server enables LLMs to perform property searches, agent research, market analysis, and media retrieval through RESO (Real Estate Standards Organization) standardized interfaces.
Features
π Comprehensive Real Estate Data - Access to Properties, Agents, Offices, Media, and Market Analytics
π Advanced Property Search - Full OData querying with filtering, sorting, and field selection
π€ Agent & Office Discovery - Complete MLS member and brokerage information
πΈ Media & Marketing Assets - Property photos, videos, virtual tours, and documents
π Market Analytics - Days on market, pricing trends, and historical data
π Enterprise Security - OAuth2 authentication with automatic token management
π Rich Resources - Built-in field reference and query examples accessible via MCP
β‘ Performance Optimized - Dynamic metadata parsing, intelligent caching, and response optimization
Related MCP server: Repliers MCP Server
Quick Start
1. Get Constellation 1 API Credentials
Contact your RESO API provider to obtain Constellation 1 API access
Obtain your client credentials (client_id and client_secret)
Ensure you have access to the required RESO endpoints
2. Configure MCP Client
Add the server to your MCP client configuration:
Cursor
Add to your Cursor MCP settings (~/.cursor/mcp.json or through Command Palette > Open MCP Settings > New MCP Server):
{
"mcpServers": {
"constellation1": {
"command": "npx",
"args": ["-y", "constellation1-mcp-server"],
"env": {
"CONSTELLATION1_CLIENT_ID": "your-client-id-here",
"CONSTELLATION1_CLIENT_SECRET": "your-client-secret-here"
}
}
}
}Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"constellation1": {
"command": "npx",
"args": ["constellation1-mcp-server"],
"env": {
"CONSTELLATION1_CLIENT_ID": "your-client-id-here",
"CONSTELLATION1_CLIENT_SECRET": "your-client-secret-here"
}
}
}
}Other MCP Clients
# Set environment variables
export CONSTELLATION1_CLIENT_ID="your-client-id-here"
export CONSTELLATION1_CLIENT_SECRET="your-client-secret-here"
# Run the server
npx constellation1-mcp-serverAvailable Tools
Real Estate Data
reso_query- Query RESO entities with full OData supportreso_help- Get field references, examples, and best practices
Usage Examples
Find Active Properties in Seattle
{
"tool": "reso_query",
"arguments": {
"entity": "Property",
"filter": "StandardStatus eq 'Active' and City eq 'Seattle'",
"select": "ListingKey,ListPrice,BedroomsTotal,BathroomsTotal,UnparsedAddress,PublicRemarks",
"orderby": "ListPrice asc",
"top": 25
}
}Get Property with Marketing Photos
{
"tool": "reso_query",
"arguments": {
"entity": "Property",
"filter": "StandardStatus eq 'Active' and PhotosCount gt 0",
"expand": "Media($filter=MediaCategory eq 'Photo' and Permission ne 'Private';$orderby=Order asc;$top=5)",
"select": "ListingKey,ListPrice,UnparsedAddress,PhotosCount",
"top": 10
}
}Find Real Estate Agent
{
"tool": "reso_query",
"arguments": {
"entity": "Member",
"filter": "MemberFullName eq 'John Smith'",
"select": "MemberMlsId,MemberFullName,MemberEmail,MemberDirectPhone,OfficeName,MemberDesignation"
}
}Get Market Analysis Data
{
"tool": "reso_query",
"arguments": {
"entity": "Property",
"filter": "StandardStatus eq 'Closed' and CloseDate ge 2024-01-01",
"select": "ListingKey,ClosePrice,CloseDate,BedroomsTotal,LivingArea,City,DaysOnMarket",
"orderby": "CloseDate desc",
"top": 100
}
}Get Help and Examples
{
"tool": "reso_help",
"arguments": {
"topic": "examples"
}
}Configuration
Environment Variables
CONSTELLATION1_CLIENT_ID(required) - Your Constellation 1 OAuth client IDCONSTELLATION1_CLIENT_SECRET(required) - Your Constellation 1 OAuth client secret
Optional Configuration
CONSTELLATION1_BASE_URL(optional, default:https://listings.cdatalabs.com/odata) - API base URLCONSTELLATION1_AUTH_URL(optional, default:https://authenticate.constellation1apis.com/oauth2/token) - OAuth token endpoint
Alternative Environment Variable Names
The server also supports these alternative environment variable names:
CLIENT_ID/CLIENT_SECRETRESO_CLIENT_ID/RESO_CLIENT_SECRET
API Quotas and Usage
This server accesses RESO-compliant real estate data through the Constellation 1 API. Monitor your API usage and ensure compliance with your RESO API provider's terms of service.
Resources
The server provides built-in MCP resources with documentation and examples:
constellation1://docs/field-reference- Comprehensive RESO field reference guideconstellation1://docs/quick-start- Common query patterns and examples
Access these through your MCP client's resource interface.
Error Handling
The server returns structured errors with helpful context:
{
"error": {
"code": "AUTH_FAILED",
"message": "OAuth2 authentication failed: 401 Unauthorized",
"context": {
"endpoint": "https://authenticate.constellation1apis.com/oauth2/token",
"status": 401
}
}
}Common error codes:
INVALID_ENTITY- Unsupported RESO entity typeAUTH_FAILED- OAuth2 authentication failedAPI_ERROR- RESO API request failedSKIP_LIMIT_EXCEEDED- Pagination skip limit exceededMETADATA_FETCH_FAILED- Unable to load RESO metadata
Security
API credentials are never logged or exposed in responses
Input validation prevents injection attacks through Zod schemas
OAuth2 tokens are securely cached and automatically refreshed
All API communication uses HTTPS with proper certificate validation
Development
Building from Source
git clone https://github.com/david-pivonka/constellation1-mcp-server.git
cd constellation1-mcp-server
npm install
npm run buildTesting
npm testUsing MCP Inspector
npm run build
CONSTELLATION1_CLIENT_ID="your-client-id" CONSTELLATION1_CLIENT_SECRET="your-client-secret" npx @modelcontextprotocol/inspector ./dist/index.jsContributing
Contributions are welcome! Please submit pull requests to our GitHub repository.
License
MIT License - see LICENSE file for details.
Available Tools
2 toolsreso_helpA
Get comprehensive RESO field reference documentation, query examples, and best practices. This tool provides instant access to field guides, entity descriptions, filter patterns, and common use cases for effective RESO API usage.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Help topic to retrieve. Options: entities, fields, filters, enums, expand, examples, performance, images, metadata, overview |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does convey that the tool returns documentation and reference content rather than performing mutations or executing queries. However, it does not disclose details like whether it returns one topic at a time, how output is formatted, or any limitations such as lack of rate limits or auth requirements. For a simple help tool, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the two sentences are somewhat redundant: 'RESO field reference documentation, query examples, and best practices' overlaps with 'field guides, entity descriptions, filter patterns, and common use cases.' Phrases like 'instant access' and 'effective RESO API usage' are filler rather than informative. It could be tighter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single enum parameter and no output schema, the description provides enough context to understand what the tool returns and its general scope. It covers the purpose and content areas, while the schema fully enumerates the selectable topics. It does not explain return structure, but that is less critical given the simple, documentation-oriented nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and enumerates all valid topics with a clear enum. The description adds general context about what kinds of help are available but does not meaningfully expand on individual parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a reference/help resource for RESO: 'Get comprehensive RESO field reference documentation, query examples, and best practices.' The verb 'Get' plus the specific resource type makes the purpose concrete, and it is naturally distinguished from the sibling reso_query, which presumably executes queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent needs RESO documentation, examples, or best practices, but it does not explicitly state when to choose this tool over reso_query. There is no direct 'use this when...' or 'use reso_query instead for...' guidance, leaving the usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reso_queryB
Query the RESO (Real Estate Standards Organization) API for comprehensive real estate data. This tool provides access to MLS (Multiple Listing Service) data including property listings, agent information, office details, media files, and market analytics. Perfect for real estate research, market analysis, property searches, and lead generation. Supports advanced filtering, sorting, and field selection with standardized RESO field names for consistent data access across different MLS systems.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum number of records to return (1-1000). Use 10-50 for quick searches, 100-1000 for analysis. | |
| skip | No | Number of records to skip for pagination. Skip limits: Property (1M), Office/Member (500K), Media (50K) | |
| entity | No | RESO Entity to query. Options: Property (listings), Member (agents), Office (brokerages), Media (photos/videos), OpenHouse (events), Dom (days on market), PropertyRooms (room details), PropertyUnitTypes (unit info), RawMlsProperty (raw MLS data) | |
| expand | No | Include related entities. Examples: "Media", "Media($filter=Permission ne 'Private')", "Media,OpenHouse,Dom" | |
| filter | No | OData filter expression. Examples: "StandardStatus eq 'Active'", "ListPrice ge 200000 and ListPrice le 500000", "City eq 'Seattle'" | |
| select | No | Comma-separated list of fields to return. Leave empty to get all available fields. Common Property fields: ListingKey, StandardStatus, ListPrice, BedroomsTotal, City, PublicRemarks | |
| orderby | No | Sort order. Format: "FieldName [asc|desc]". Examples: "ListPrice desc", "City asc, ModificationTimestamp desc" | |
| nextLink | No | Use @odata.nextLink URL from a previous query response to get the next page of results. When provided, other parameters (except ignorenulls/ignorecase) are ignored. This enables efficient server-side pagination for large result sets. Example: use the @odata.nextLink value from a previous reso_query response. | |
| ignorecase | No | Enable case-insensitive text matching for filters. Default: false. | |
| ignorenulls | No | Exclude null/empty fields to reduce payload size. Default: true. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only says 'Query' and 'data access.' It does not explicitly state the operation is read-only, mention authentication/rate-limit implications, or clarify how nextLink/pagination behaves, which is important for a 10-parameter API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but contains filler phrases like 'Perfect for' and 'comprehensive' and repeats the MLS/RESO concept across multiple sentences. It is acceptable but not tightly edited.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich input schema covers parameters, but there is no output schema and the description does not describe response shape, pagination behavior, or how results are returned. It identifies data categories and use cases, making it minimally adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds high-level color about filtering, sorting, and field selection, but does not provide significant meaning beyond the schema, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Query the RESO API') and the resource domain (MLS property, agent, office, media, and analytics data), making the tool's purpose easy to grasp. It does not explicitly distinguish itself from the sibling reso_help, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers broad intended-use context ('Perfect for real estate research, market analysis, property searches, and lead generation') but no explicit conditions for when to use this tool instead of reso_help, nor any exclusions. The guidance is implied rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.0.0-dev- First observed
reso_help - First observed
reso_query
TDQS
Scored across 2 tools
reso_query is the execution tool for actual data retrieval and filtering, while reso_help provides documentation, field references, and query examples. There is no functional overlap, so an agent can clearly choose between acting and learning.
Both tools use the consistent reso_ prefix followed by a clear action word, creating a predictable pattern. Even though the set is small, the naming is uniform and easy to infer.
Two tools is a minimal surface for a broad RESO API domain. Both tools earn their place, but the server feels slightly thin rather than fully fleshed out for the range of data it claims to access.
The read-only query workflow is well covered: reso_query handles all entity searches, filtering, sorting, and field selection, while reso_help provides the necessary reference and examples. There are no obvious missing operations for the stated purpose.
Maintenance
Related MCP Connectors
AI-native real estate discovery with structured property search and market intelligence.
Zillow MCP for AI agents: property data, Zestimates & listings β 300+ fields per home. Free tier.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI applications to search and analyze UNLOCK MLS real estate data through Bridge Interactive's RESO Web API, supporting natural language property searches, market analysis, and agent discovery.2-
- AlicenseNot gradedqualityDmaintenanceProvides tools to access the Repliers API for real estate listings, property search, market analytics, and AI-powered data through natural language queries.205 npmMIT
- AlicenseNot gradedqualityFmaintenanceEnables LLMs to search and retrieve Japanese real estate data through unified access to the MLIT Real Estate Information Library API, supporting over 25 geospatial datasets for interactive queries.186MIT

Repliers MCP Serverofficial
AlicenseNot gradedqualityBmaintenanceProvides AI assistants access to real-time MLS data via the Repliers API, enabling natural language property search, market statistics, and listing details.205 npm17MIT