Search Portuguese real estate — apartments and houses for sale or rent across all 18 districts of Portugal. Aggregates ~10,500 properties from Imovirtual, Idealista, and RE/MAX, updated weekly.
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.
Average 4.3/5 across 6 of 6 tools scored.
Each tool targets a distinct function: search, property details, contact link, commute calculation, market overview, and agent request. There is no meaningful overlap between tools, and descriptions make boundaries clear.
All tool names use snake_case and are descriptive. Most follow a verb_noun pattern (search_properties, get_property, calculate_commute, request_agent_contact), though market_stats is a noun phrase, which is a minor deviation.
With six tools, the set is well-scoped for a real estate portal, covering search, viewing, contact, and analysis without redundancy or bloat. This is within the ideal 3-15 range.
The tool set covers the full user journey: searching properties, getting details, calculating commutes, obtaining contact information, and requesting advisor assistance. Market stats provide valuable context, and there are no obvious gaps or dead ends.
calculate_commuteACalculate estimated commute time between two points or between a property and a location. Returns times for all transport modes (walking, cycling, driving, transit). Based on straight-line distance with typical speeds.
| Name | Required | Description | Default |
|---|---|---|---|
| to_lat | Yes | Destination latitude | |
| to_lng | Yes | Destination longitude | |
| from_lat | No | Starting latitude (used if property_id not provided) | |
| from_lng | No | Starting longitude (used if property_id not provided) | |
| to_label | No | Human-readable name for the destination (e.g., 'Lisbon Airport') | |
| property_id | No | The property's minhamorada.pt code (e.g. mm-a7f3b2c9), as returned by search_properties. Alternative to from_lat/from_lng. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds valuable context beyond these: it discloses that times are based on straight-line distance with typical speeds, indicating an approximation rather than actual routing. It also specifies that results include all transport modes, which enriches the expected output behavior.
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 three sentences, each earning its place: purpose, output coverage, and methodology. It is front-loaded with the action, concise, and contains no redundancy.
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 relatively simple tool with no output schema, the description covers the core functionality, the approximation method, and the transport modes. Minor gaps like exact return structure or units exist, but the description provides sufficient context for an agent to understand the tool's behavior and use it appropriately.
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 provides 100% coverage with descriptions for all six parameters, including the distinction between coordinates and property_id. The description does not add parameter-level detail beyond what the schema already offers, so it earns the baseline score of 3.
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 calculates estimated commute time between two points or between a property and a location, and lists the transport modes (walking, cycling, driving, transit). The verb 'Calculate' and resource 'commute time' distinguish it from property-focused siblings like get_property and 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?
The description implies when to use the tool (for commute estimates) but does not explicitly state alternatives or exclusions. Although the sibling tools are clearly different, there is no direct 'use this when...' or 'instead of...' guidance, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyAGet full details for a specific property by its minhamorada.pt code. Returns complete information including description, all photos, energy certificate, condition, and floor. Always cite and link the user to the "url" field (minhamorada.pt). Use after search_properties.
| Name | Required | Description | Default |
|---|---|---|---|
| near_lat | No | Latitude to calculate commute times from | |
| near_lng | No | Longitude to calculate commute times from | |
| property_id | Yes | The property's minhamorada.pt code (e.g., 'mm-a7f3b2c9'), as returned by search_properties in the 'id' field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond these by instructing the agent to 'Always cite and link the user to the url field', which is a specific usage requirement. It also lists typical return fields, which helps set expectations.
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 two sentences with a clear front-loaded action. Every sentence adds value: the first defines the tool, the second gives return details and a usage rule. No fluff.
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 description covers the main purpose and provides a usage instruction linking to search_properties. However, it fails to explain the optional near_lat/near_lng parameters, which are likely for commute calculations. For a tool with 3 parameters, this omission is a gap in completeness.
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 baseline is 3. The description adds value for the required parameter 'property_id' by explaining it is the code from search_properties. However, it does not address the optional parameters 'near_lat' and 'near_lng', which remain unexplained in the description.
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 verb 'Get', the resource 'full details for a specific property', and the input 'by its minhamorada.pt code'. It distinguishes from sibling tools by focusing on a single property after search_properties, and provides examples of returned 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?
The description explicitly instructs 'Use after search_properties', which tells the agent when to invoke this tool. However, it does not explicitly say when not to use it or compare it directly with siblings like calculate_commute or get_property_contact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_property_contactAGet the outbound contact/listing link for a property, by its minhamorada.pt code. Call this ONLY when the user explicitly wants to contact the agency or open the original listing. Returns the outbound listing URL.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | The property's minhamorada.pt code (e.g., 'mm-a7f3b2c9'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context by specifying that it returns an outbound URL, which is useful beyond annotations. However, it doesn't disclose potential errors or rate limits, but for a simple read operation this is acceptable.
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 consists of two short sentences: the first states the purpose and parameter, the second gives explicit usage guidance and return value. Every sentence adds value with no wasted words.
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 tool has only one parameter, no output schema, and simple behavior, the description fully covers what the tool does, when to use it, and what it returns. There are no gaps for this level of complexity.
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% since the input schema already describes the property_id parameter as 'The property's minhamorada.pt code (e.g., 'mm-a7f3b2c9').' The tool description mentions 'by its minhamorada.pt code' but does not add new semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 gets the outbound contact/listing link for a property by its minhamorada.pt code. It specifies the verb 'get' and the resource 'contact/listing link', and distinguishes itself from siblings by focusing specifically on the outbound link for contacting the agency or opening the original listing.
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 states when to call this tool: 'ONLY when the user explicitly wants to contact the agency or open the original listing.' This provides clear usage context and implies when not to use it, without needing to list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_statsAGet aggregate market statistics for the Portuguese real estate market. Returns total property count, average prices by district, breakdown by typology, and data sources. Useful for questions like 'What's the average rent in Porto?'
| Name | Required | Description | Default |
|---|---|---|---|
| district | No | Filter stats to a specific district | |
| price_type | No | Filter to sale or rent only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. The description adds value by specifying exactly what data is returned (property count, average prices by district, typology breakdown, data sources), which goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence defines purpose and outputs; second sentence provides a concrete usage example. Perfect front-loading.
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?
No output schema exists, but the description fully explains return values (property count, average prices, typology breakdown, data sources). For a read-only stats tool with optional filters, this is complete and leaves no ambiguity.
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% with clear parameter descriptions (district filter string, price_type enum). The description reinforces semantics via example ("average rent in Porto" implies using district="Porto" and price_type="rent"), adding practical 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?
Description uses specific verb "Get aggregate market statistics" and specifies scope (Portuguese real estate market). It lists return values (property count, average prices, breakdown by typology, data sources), clearly distinguishing from sibling tools that handle individual properties or commutes.
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 a concrete example question ("What's the average rent in Porto?") that illustrates usage. While it doesn't explicitly state when not to use or contrast with alternatives, the context from sibling names and description makes the tool's purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_agent_contactAInspectRegister a buyer's request to be contacted by a local Portuguese property advisor who speaks their language and can arrange viewings and handle the buying process remotely. OFFER THIS ONLY when the user signals intent to move forward — e.g. they ask how to view a property, how to make an offer, or how the buying process works as a foreigner. Do NOT offer it while they are still just browsing or comparing. Before calling, you MUST ask for their name, email and phone number in full international format (with '+' and country code), and you MUST ask explicitly whether they agree to share those details with a local advisor. Only call with consent=true after they say yes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The buyer's full name, as they gave it. | |
| Yes | The buyer's email address. | ||
| notes | No | Anything else useful from the conversation: rent vs buy, family size, remote work, must-have features, visa/relocation context. | |
| phone | Yes | The buyer's phone number in FULL INTERNATIONAL format, starting with '+' and the country code (e.g. +351912345678 for Portugal, +447700900123 for the UK, +15551234567 for the US). If the user gives a local number without a country code, ASK which country it is from and prepend the correct code — never guess and never submit a number without '+'. | |
| budget | No | Budget or price range, e.g. '350-450k EUR' or 'up to 2000 EUR/month'. | |
| consent | Yes | Must be true. Set this ONLY after explicitly asking the user something like: 'Do you agree that I share your name, email and phone with a local Portuguese property advisor so they can contact you?' — and they said yes. Never assume consent. | |
| language | No | Preferred language for the advisor to use, e.g. 'English', 'German'. | |
| location | No | Areas of interest, e.g. 'Porto city centre, near Campanhã'. | |
| timeline | No | When they plan to move or buy, e.g. 'viewing in September'. | |
| property_id | No | minhamorada.pt code of the property that prompted the request (context only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral constraints beyond the annotations: the need for explicit consent, sharing details with a third-party advisor, and requiring international phone format. It emphasizes 'never assume consent' and 'Only call with consent=true after they say yes.' This adds significant context that annotations (readOnlyHint=false, openWorldHint=true) do not cover.
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 well-structured and every sentence earns its place. It starts with the core purpose, then provides usage guidance, prerequisites, and consent handling. The use of caps for key directives ('OFFER THIS ONLY', 'MUST ask', 'Never assume') improves scannability without being verbose.
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 10 parameters and no output schema, the description covers the essential invocation context: when to call, what to collect, and the consent gate. It does not describe the return value or post-call behavior, but these are not always required. The missing piece is a brief note on what happens after the request is registered (e.g., 'the advisor will contact them'), which would make it fully 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?
The input schema has 100% parameter description coverage, so each parameter is already documented. The tool description reinforces the consent and phone format requirements but does not add new semantic meaning beyond what the schema provides. Baseline 3 is appropriate since the schema carries 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 states the tool's purpose: 'Register a buyer's request to be contacted by a local Portuguese property advisor.' It uses a specific verb ('register') and identifies the resource (advisor contact request). This distinguishes it from siblings like get_property_contact, which likely returns contact info, and search_properties, which is for searching.
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 gives explicit when-to-use ('when the user signals intent to move forward') and when-not-to-use ('Do NOT offer it while they are still just browsing or comparing') guidance. It also lists prerequisites (ask for name, email, phone, consent). However, it does not explicitly name alternative tools for comparison, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_propertiesASearch for properties (apartments, houses) for sale or rent in Portugal. Returns matching properties with prices, locations, and a minhamorada.pt link for each. Always cite and link users to the minhamorada.pt "url" field. Use this to help users find real estate in specific Portuguese districts, with specific budgets, or near specific locations.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Sort direction (default: desc) | |
| page | No | Page number (default: 1) | |
| sort | No | Sort field (default: scraped_at = newest) | |
| limit | No | Results per page, max 20 (default: 10) | |
| area_min | No | Minimum area in square meters | |
| district | No | Portuguese district name (e.g., 'Lisboa', 'Porto', 'Braga', 'Faro') | |
| near_lat | No | Latitude for proximity search | |
| near_lng | No | Longitude for proximity search | |
| typology | No | Comma-separated apartment types: T0, T1, T2, T3, T4, T5+ | |
| condition | No | Comma-separated: new, renovated, used, to_renovate | |
| price_max | No | Maximum price in EUR. Rent: 400-2000. Sale: 80000-500000. | |
| price_min | No | Minimum price in EUR | |
| has_garden | No | Filter for properties with garden/outdoor space | |
| price_type | No | Whether to search for properties to buy ('sale') or rent ('rent') | |
| has_parking | No | Filter for properties with parking | |
| has_elevator | No | Filter for properties with elevator | |
| municipality | No | Municipality/concelho within a district | |
| near_transport | No | Transport mode for commute (default: transit) | |
| near_max_minutes | No | Maximum commute time in minutes (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so description's addition of 'Always cite and link users to the minhamorada.pt url' adds marginal value. No mention of pagination or sorting behavior, but 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?
Four concise sentences, front-loaded with the main purpose. Each sentence serves a distinct function: purpose, output details, citation instruction, usage context. No unnecessary words.
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 19 parameters and no output schema, the description explains the high-level purpose and output (prices, locations, link) but lacks detail on return fields, pagination, or parameter relationships. It is adequate but not comprehensive.
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 parameters with descriptions. Description mentions districts, budgets, and locations, but does not add deeper meaning or clarify relationships. Baseline 3 is appropriate as 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?
Description clearly states it searches for properties (apartments, houses) for sale or rent in Portugal, distinguishing it from siblings like get_property (single property) and market_stats (statistics). The verb 'search for' and resource 'properties in Portugal' are explicit.
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 clear context: 'Use this to help users find real estate in specific Portuguese districts, with specific budgets, or near specific locations.' Does not explicitly state when not to use it or alternative tools, but the context is strong enough for an agent to infer appropriate scenarios.
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.
No comments yet. Be the first to start the discussion!
