HOUSE 'N' STARS Real Estate Discovery
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.
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.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored. Lowest: 3.8/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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful context about the dataset's AI-native nature and scope limitations, but the core behavioral traits are already covered by annotations.
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 concise (two sentences), front-loaded with purpose, and includes usage guidance and exclusions without any redundant or vague language.
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?
Given zero parameters, comprehensive annotations, and simple functionality, the description fully covers the tool's purpose, usage context, and limitations. No output schema is needed for this overview 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?
There are no parameters, so the baseline is 4. The description does not need to add parameter-specific meaning, and it does not repeat schema information.
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 states the tool's purpose: explaining what the HOUSE N STARS ChatGPT connector provides as a read-only dataset. It distinguishes from siblings by explicitly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (e.g., when user asks about dataset scope, read-only nature, markets) and what it does not do (e.g., no listing search, no report retrieval). This helps the agent choose correctly among siblings.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld), the description specifies exact input requirements (numeric ID or slug) and output handling (summarize, omit technical details). No contradiction.
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?
Two sentences, no filler. The first sentence states purpose; the second provides usage guidelines. Every word earns its place.
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 simple read tool with one parameter and annotations, the description covers purpose, input requirements, output handling, and references to sibling tools. Complete.
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 covers 100% of the parameter with a description. The description adds that the ID/slug must be exact and references sibling tools that return such values, adding context.
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 states the tool retrieves a single HOUSE N STARS property by exact numeric ID or slug, using a specific verb and resource. It distinguishes from sibling search tools which 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance to summarize the property cleanly for user-facing answers and instructs to avoid technical details unless explicitly asked. It implies when to use this tool versus 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds no behavioral context beyond the annotation's implied safety.
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?
Single sentence, no wasted words. Front-loaded with purpose.
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?
Simple tool with no parameters or output schema; description covers the essential purpose. Could mention expected return type, but not required.
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?
No parameters; schema coverage is 100%. Description doesn't need to add parameter info. Baseline 4 for zero parameters.
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?
Description clearly states the tool checks API reachability, using specific verb ('Check') and resource ('HOUSE N STARS WordPress property API'). Distinguishes from siblings that retrieve data.
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?
No explicit guidance on when to use or not use this tool vs alternatives. Context implies it's a health check before other calls, but not stated.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds essential behavioral details: server-side search, raw feed values, no automatic unit addition, and detailed response rules that prevent incomplete or technical answers. No contradictions.
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 comprehensive but verbose, containing many response rules that could be condensed. Front-loaded with purpose and key usage, but excess sentences on formatting rules reduce conciseness.
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?
Without an output schema, the description covers parameter usage, response presentation rules, and caveats (e.g., no automatic get_property calls). It is fairly complete for a complex search tool with 8 parameters.
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 coverage is 100%, but description adds value: e.g., query should not contain sale/rent intent; transaction_type must be exact 'Sale' or 'Rent'; price_display with 'Price on request' should be presented as POA. These enhance the schema meaning.
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 states it is the 'Preferred HOUSE N STARS property search tool' and specifies it searches real luxury real estate listings using server-side WordPress search across the full HNS database. It is distinct from siblings like search_properties.
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?
Provides explicit guidance on using transaction_type for Sale/Rent, avoiding sale/rent intent in query, and using price_display and location for user-facing fields. However, it does not contrast with sibling tools like search_properties to indicate when not to use this one.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds extra behavioral context: it uses the same server-side WordPress search, formatting, POA handling, EUR/AED inference, location cleanup, and result table output. This enriches understanding beyond annotations, though return format is not fully detailed.
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 a single paragraph that is concise and to the point, front-loading the legacy nature and recommendation. It covers key points without extra fluff, though could benefit from slight structural separation.
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?
Given the complexity (8 parameters, no required, no output schema), the description adequately covers purpose, usage, and behavioral traits. The only minor gap is lack of detail on the return structure, but 'result table output' gives a basic idea.
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?
With 100% schema description coverage, the description still adds value by providing examples (e.g., 'sea view, garden' for query) and explicit usage rules (e.g., 'Do not use query for sale/rent; use transaction_type'). This enhances the schema descriptions.
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 states it is a legacy search tool for HOUSE N STARS properties and differentiates from the sibling search_hns_properties by explicitly recommending the newer tool for sales/rental searches.
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 explicitly advises to prefer search_hns_properties for new searches, especially for sale/rent, and explains the reason (transaction_type parameter). It also notes the tool is for backward compatibility, providing clear when-to-use 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!