A
licenseA
qualityD
maintenanceAI-powered property intelligence for instant zoning analysis, buildability assessments, ADU eligibility, flood risk, and development feasibility reports for any US address.
Last updated
5
1
MIT
HOUSE 'N' STARS Real Estate Discovery
Ownership verified
Server Details
AI-native real estate discovery with structured property search and market intelligence.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4/5.0
Tool DescriptionsA
Average 4.4/5 across 5 of 5 tools scored. Lowest: 3.8/5.
Server CoherenceA
Disambiguation3/5
Most tools have distinct purposes, but the two search tools (search_hns_properties and search_properties) have overlapping functionality, creating ambiguity for agents. The other three tools are clearly separated.
Naming Consistency3/5
Tools generally follow a verb_noun pattern, but hns_api_status breaks this pattern, and the prefix 'hns' is used inconsistently (present in some tools, absent in others). The naming is readable but not fully consistent.
Tool Count4/5
5 tools is a reasonable number for this domain, covering overview, single property retrieval, search (two variants), and status check. The redundancy between the two search tools is a minor flaw, but overall the count feels well-scoped.
Completeness4/5
The tool set covers the core read-only workflows: overview, search, and detail retrieval. Missing features like listing images or advanced filters are minor gaps given the stated purpose of a read-only luxury real estate dataset.
Available Tools
5 toolsget_hns_dataset_overviewGet HOUSE N STARS dataset overviewARead-onlyInspect
Explain what the HOUSE N STARS ChatGPT connector provides as a read-only AI-native luxury real estate dataset. Use this when the user asks what HOUSE N STARS covers, what data the app can access, whether it is read-only, which markets are represented, or why the connector is useful inside ChatGPT. This tool summarizes dataset scope and limitations; it does not search individual listings and does not retrieve archival HNS research reports unless dedicated tools are added later.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces the read-only nature and adds behavioral context: it summarizes dataset scope and limitations, and explicitly states it does not perform searches or retrieve reports. This adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and followed by usage guidance. Every sentence earns its place; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description fully covers what the tool does and when to use it. It also addresses limitations and distinguishes from sibling tools, making it complete for an overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. Baseline is 4, and the description does not need to add any parameter semantics. It correctly focuses on the purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains the HOUSE N STARS ChatGPT connector as a read-only AI-native luxury real estate dataset. It specifies when to use it (e.g., user asks about coverage, read-only nature, markets) and distinguishes it from sibling tools by noting it does not search individual listings or retrieve archival reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (e.g., 'Use this when the user asks...') and what it does not do (does not search listings, does not retrieve reports). This provides clear guidance on when to choose this tool over alternatives like search_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyGet a HOUSE N STARS propertyARead-onlyInspect
Retrieve one real HOUSE N STARS property by exact numeric ID or exact slug. For normal user-facing answers, summarize the property cleanly. Never add Technical check, Result check, API check, connector check, structuredContent, diagnostics, endpoint details, or implementation notes unless the user explicitly asks for a technical verification.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | The property numeric ID or slug returned by search_hns_properties or search_properties. |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds specifics about exact matching and constraints beyond annotations (readOnlyHint, destructiveHint), and warns against adding technical noise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool without output schema, the description and annotations together provide adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds minimal new meaning beyond what the parameter description already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves one property by exact numeric ID or slug, distinguishing it from sibling search tools that return multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Advised to summarize for user-facing answers and avoid technical details unless asked, but does not explicitly compare to sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hns_api_statusCheck HOUSE N STARS API statusARead-onlyInspect
Check whether the HOUSE N STARS WordPress property API is reachable through the Render MCP server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about checking reachability, which is consistent. It does not introduce new behavioral traits but also does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, full annotations, no output schema), the description is complete enough. It clearly states what the tool does and its relationship to the server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter info. The baseline for zero parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check whether... is reachable') and the resource ('HOUSE N STARS WordPress property API'). It distinguishes itself from sibling tools, which deal with property data, by focusing on the API status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a preliminary status check but does not provide explicit when-to-use or when-not-to guidance. No alternatives or exclusions are mentioned, leaving the agent to infer context from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hns_propertiesSearch HOUSE N STARS propertiesARead-onlyInspect
Preferred HOUSE N STARS property search tool. Search real luxury real estate listings from HOUSE N STARS using server-side WordPress search across the full HNS property database. Use the explicit transaction_type parameter for Sale/Rent distinction: use Sale for properties for sale and Rent for rental properties. Do not express sale/rent intent only as query text. Use price_display for user-facing prices and location for user-facing location names. If price_display is Price on request, present it as POA/price on request. Surface values are raw feed values; do not add sq ft or sqm unless the unit is explicit in the listing text. PUBLIC RESPONSE RULE: for normal property-search answers, use the READY-TO-USE PUBLIC TABLE returned by this tool. Present ALL returned rows up to the requested limit in one compact markdown table. Do not call get_property automatically for each row. Never collapse the answer to only the first listing, never show only two listings, and never say there is only one clear match when more than one result is returned. Do not use image cards or expanded individual property sections for search-result lists because they can cause incomplete answers. Never add a final sentence or paragraph called Technical check, Result check, API check, connector check, tool check, debug note, implementation note, or similar. Do not mention API status, connector internals, filters, diagnostics, structuredContent, returned_count, found_posts, transaction_type, or implementation details unless the user explicitly asks for a technical verification. Present the listings cleanly as real HOUSE N STARS properties.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Maximum 20. | |
| query | No | Free text search, for example sea view, garden, penthouse, waterfront. Do not use this field for sale/rent intent alone; use transaction_type. | |
| bedrooms | No | Minimum number of bedrooms requested by the user. | |
| location | No | Location filter, for example Dubai, Abu Dhabi, Monaco, Nice, Èze. | |
| max_price | No | Maximum price as a number, without currency symbols. | |
| min_price | No | Minimum price as a number, without currency symbols. | |
| property_type | No | Property type, for example Villa, Apartment, Penthouse, Townhouse. | |
| transaction_type | No | Sale/Rent filter. Use exactly Sale for properties for sale and Rent for rental properties. Do not put rent/rental/for rent into query when this parameter is used. |
Tool Definition Quality
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description adds important behavioral context: raw feed values should not have units added unless explicit, and the public response rule dictates output format (compact markdown table, no automatic get_property calls, no technical mentions). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and contains a large public response rule section that, while useful, reduces conciseness. It is front-loaded with the main purpose but includes many detailed prohibitions that could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no required fields, and no output schema, the description provides substantial operational details (response format, data handling, prohibitions) that make the tool's behavior clear. It compensates well for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds extra usage context for transaction_type and notes about price_display and location, but price_display is not an actual parameter, which may cause slight confusion. Overall, adds moderate value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the preferred search tool for HOUSE N STARS properties, using server-side WordPress search across the full database. The title and description together provide a specific verb and resource, and it is distinguished from siblings by being the 'preferred' search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions for using transaction_type for sale/rent distinction and provides guidance on price_display and location. It also includes a detailed 'PUBLIC RESPONSE RULE' section for output formatting. However, it does not explicitly state when to avoid this tool or mention alternatives among the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_propertiesLegacy search HOUSE N STARS propertiesARead-onlyInspect
Legacy compatibility tool for searching HOUSE N STARS properties. Prefer search_hns_properties for new property searches, especially when the user asks for properties for sale or for rent because search_hns_properties exposes transaction_type as the official Sale/Rent parameter. This legacy tool remains available for backward compatibility and uses the same server-side WordPress search, price_display formatting, POA handling, EUR/AED inference, location cleanup and result table output.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Maximum 20. | |
| query | No | Free text search, for example sea view, garden, penthouse, waterfront. Do not use this field for sale/rent intent alone; use transaction_type. | |
| bedrooms | No | Minimum number of bedrooms requested by the user. | |
| location | No | Location filter, for example Dubai, Abu Dhabi, Monaco, Nice, Èze. | |
| max_price | No | Maximum price as a number, without currency symbols. | |
| min_price | No | Minimum price as a number, without currency symbols. | |
| property_type | No | Property type, for example Villa, Apartment, Penthouse, Townhouse. | |
| transaction_type | No | Sale/Rent filter. Use exactly Sale for properties for sale and Rent for rental properties. Do not put rent/rental/for rent into query when this parameter is used. |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds context about using the same server-side WordPress search, formatting, and handling (POA, EUR/AED inference, etc.), which goes beyond annotations, but does not fully detail all behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loads the key purpose and recommendation, and every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, legacy nature, no output schema), the description covers purpose, usage guidance, behavioral details, and processing equivalency, making it fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description does not add new parameter-level meaning; it only provides overall context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Legacy compatibility tool for searching HOUSE N STARS properties', using specific verb (search) and resource, and distinguishes itself from the newer sibling tool 'search_hns_properties'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends preferring 'search_hns_properties' for new searches (especially with transaction_type) and notes this legacy tool is for backward compatibility, providing clear when/why-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityBmaintenanceEnables structured real estate workflows including property search, agent/client management, market intelligence, mortgage calculations, valuation, investment analysis, and document ingestion, with offline-first capabilities and optional live data integrations.Last updatedAGPL 3.0
- Alicense-qualityBmaintenanceEnables AI agents to find vetted, daily-scored US residential real-estate investment deals with pay-per-request via USDC on Base.Last updated22MIT
Fabrica MCP Serverofficial
Flicense-qualityDmaintenanceGives AI agents access to tokenized real property data on the Fabrica protocol, enabling property search, lending market analysis, and portfolio exploration.Last updated