First-party Spanish, Portuguese and Italian property listings with notarial-verified prices.
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.4/5 across 13 of 13 tools scored.
Each tool has a clearly distinct purpose: structured search, free-form search, property detail, location lookup, market stats, valuation, agency listing, CRM contact management, leads, listings, and enquiries. The descriptions explicitly differentiate overlapping areas (e.g., area_market_summary vs. verified_valuation, search_properties vs. find_properties_by_description), so misselection is unlikely.
Most tool names follow a verb_noun pattern (create_contact, find_contacts, get_property, search_properties, submit_enquiry, etc.). Deviations exist: area_market_summary and verified_valuation are noun phrases, and my_leads/my_listings use a possessive prefix. These are somewhat consistent as a group but break the dominant verb-first style.
With 13 tools, the server covers a broad but focused domain—property search, market context, valuation, agencies, and agency CRM. Each tool serves a distinct function without redundancy or bloat. This is a well-scoped count for a real-estate platform.
The tool set covers the full user journey from location resolution and property search to obtaining detailed listings, market summaries, valuations, contacting agencies, and managing leads/contacts in a CRM. Missing features like updating contacts or managing listings are outside the apparent scope (it's a search-and-lead tool, not a full property management system). Overall, no critical gaps.
area_market_summaryAReturn aggregate market context for a Spanish area: number of active listings, median price, mean price, median €/m², and the count broken down by bedroom band. Filterable by property type and search type (for-sale / for-rent / holiday-rentals). Use this before recommending a price or commenting on whether a listing is good value.
If the place name is not one we hold, the response says so (error: location_not_found, location_match.matched: false) and returns no figures. Figures are NEVER nationwide fallbacks.
Price figures follow the search type and are labelled with price_unit: sale prices are totals, for-rent is per MONTH and holiday-rentals is per WEEK. median_price_per_sqm is reported for sales only.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Place name (city, suburb, or urbanisation). e.g. 'Marbella'. | |
| search_type | No | for-sale | |
| property_types | No | Optional comma-separated slugs: apartments, villas, penthouses, plots, townhouses. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| oracle | Yes | |
| location | Yes | |
| max_price | No | |
| min_price | No | |
| mean_price | No | |
| price_unit | No | |
| price_basis | No | |
| search_type | No | |
| median_price | No | |
| location_match | No | |
| property_types | No | |
| total_listings | Yes | |
| by_bedroom_band | No | |
| median_price_per_sqm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations, such as error handling when location is not found, assurance that figures are never nationwide fallbacks, and details on price units per search type. Annotations already indicate read-only and idempotent, so the description enriches this.
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 informative and well-structured, starting with the primary action and then adding important details. While it is slightly lengthy, every sentence serves a purpose; a bit more conciseness would be ideal.
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 presence of an output schema, the description provides necessary context: return values are explained, error cases are covered, and price units are clarified. It is complete for an agent to use correctly.
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 description explains the purpose of all three parameters beyond the schema's coverage (67%). It clarifies that search_type filters by rental vs sale and explains price unit implications, adding value over the schema alone.
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 that the tool returns aggregate market context for a Spanish area, including specific metrics like active listings, median price, etc. It distinguishes itself from sibling tools like search_properties by focusing on market summaries rather than individual listings.
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 using this tool before recommending a price or commenting on listing value, providing clear context. It does not explicitly state when not to use it, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
autocomplete_locationALook up Spanish property areas (city, suburb, urbanisation) by free-text name. Returns up to 10 matches with id, name, and the parent province/city. Use this to resolve place names before calling search_properties, especially for common spellings like 'Nueva Andalucia' (vs 'Nueva Andalucía') or 'Marbella old town'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text place name. 2+ characters. | |
| provinces | No | Optional comma-separated province ids to scope the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details: returns up to 10 matches, specific fields, and scope (Spanish property areas). 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?
Two sentences, no wasted words. First sentence states core function and output, second provides usage context with examples.
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 autocomplete tool with no output schema, the description adequately specifies input, output structure, and usage context. No missing information needed for correct usage.
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. The tool description does not add additional parameter information beyond what is in the schema.
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 looks up Spanish property areas by free-text name and returns matches with id, name, and parent province/city. It distinguishes from sibling tools like search_properties which are for property search.
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?
Explicitly advises using this before search_properties to resolve place names, with examples of common spelling variations. This provides 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.
create_contactAInspectAdd a new contact to YOUR agency's CRM. Use when the agent wants to save a person (buyer, owner, enquirer). If a contact with the same email already exists it is returned rather than duplicated. The contact is created unassigned and flagged as needing attention so it surfaces in the CRM. Requires an agency API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Contact's first name (or full name). | |
| No | Email address. Optional but recommended (used for de-duplication). | ||
| phone | No | Phone number. Optional. | |
| surname | No | Contact's surname. Optional. | |
| company_name | No | Company name (for a business contact). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that contact is created 'unassigned and flagged as needing attention' and requires an agency API key. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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?
Three concise sentences: purpose, usage context, behavioral details. No redundant information.
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?
Covers core behavior, deduplication, assignment, and flagging. Slightly lacking details on return value, but no output schema exists.
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%, so baseline is 3. The description adds minimal info beyond schema (email deduplication already in schema 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 action ('Add a new contact') and the resource ('agency's CRM'). It distinguishes from sibling tools like 'find_contacts' (search) and 'log_note' (note).
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?
Explicitly says 'Use when the agent wants to save a person' and describes deduplication behavior. Could be more explicit about when not to use, but provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_contactsASearch YOUR agency's CRM contacts by name, company, email or phone. Use to look a person up before logging a note or to check if they're already in the CRM. Requires an agency API key; only ever searches the calling agency's own contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Name, company, email or phone fragment to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds context about API key requirement and scoping to own contacts, which is useful beyond 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?
Three concise sentences. First sentence states purpose, second gives use cases, third adds constraint. 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?
No output schema, but description adequately covers when and how to use. Could mention what fields are returned for completeness, but sufficient for simple search 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 coverage is 50% (only query described). Description reinforces query fields but doesn't mention limit parameter or its default/min/max values.
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?
Clearly states 'Search YOUR agency's CRM contacts' with specific fields (name, company, email, phone). Distinguishes from sibling tools like create_contact 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?
Explicitly says when to use: 'before logging a note' or 'check if they're already in the CRM'. Also provides important constraint: 'only searches the calling agency's own contacts' and requirement for agency API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_properties_by_descriptionAMatch Spanish properties from a free-form description of what the user wants. Best for vague, conditional, or lifestyle-heavy briefs ("3-bed near a good international school, flexible on budget if there's a sea view"). Uses Gemini to translate the brief into one to three parallel structured searches across PropertyList's full MLS, then merges and ranks the results. Returns up to 9 listings with match scores and an explanation of how the brief was interpreted (and what couldn't be resolved).
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Plain-English (or Spanish) description of what the user is looking for. 10-500 chars. | |
| language | No | en |
| Name | Required | Description |
|---|---|---|
| summary | No | |
| properties | Yes | |
| unresolved | No | |
| interpretation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description discloses that it uses Gemini to translate briefs into 1-3 structured searches, merges and ranks results, returns up to 9 listings with match scores, and provides an explanation of interpretation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that front-load purpose and usage, then explain process and output. Every sentence contributes information without redundancy or 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 fully covers the tool's functionality: input type, processing method, output structure (listings with scores and explanation), and constraints (up to 9 results). Output schema exists, so the return value is adequately described.
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 50% (brief described, language not). The description adds context for 'brief' (free-form, vague, lifestyle-heavy) and mentions 'or Spanish' hinting at language parameter. It also explains how the brief is processed, which adds meaning beyond the schema.
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 'Match Spanish properties from a free-form description' and distinguishes from siblings by specifying 'Best for vague, conditional, or lifestyle-heavy briefs'. It uses a specific verb-resource pair and provides an illustrative example.
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?
Explicitly advises when to use ('Best for vague, conditional, or lifestyle-heavy briefs') and implies alternatives for structured queries (e.g., search_properties). The example clarifies the kind of input suitable for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyAFetch the full record for one PropertyList listing by its reference code (the human-readable id like 'PLE-12345'). Use this once the user has settled on a listing from search_properties or find_properties_by_description and wants details, photos, or agency contact info.
location.city is whatever tier the listing was filed under and
may be a municipality OR a locality inside one. To place a listing
administratively use location.municipality (with its INE
municipality_code); it is null, never guessed, when we cannot
resolve it.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en | |
| reference | Yes | PropertyList reference, e.g. 'PLE-12345'. |
| Name | Required | Description |
|---|---|---|
| property | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, so safety profile is clear. Description adds valuable context about location fields (city tier, municipality null behavior) beyond 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 paragraphs with front-loaded purpose. Every sentence adds value; no redundancy or fluff. Highly concise.
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 simple fetch operation, 2 parameters, and existence of output schema, the description fully covers input usage, field clarifications, and usage context. No gaps.
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 50% (reference has description, language does not). Description adds format example for reference code, but no extra for language. With moderate coverage, description partially compensates but could add more parameter 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 clearly states 'Fetch the full record for one PropertyList listing by its reference code', with specific verb and resource. It distinguishes from sibling tools like search_properties and find_properties_by_description by specifying when to use it.
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?
Explicitly says 'Use this once the user has settled on a listing from search_properties or find_properties_by_description and wants details, photos, or agency contact info', providing clear when-to-use and referencing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_agenciesAFind PropertyList agencies (estate agents) in a given Spanish area, ranked by how many active listings they carry there. Returns up to 10 agencies with name, location, listing count, and a public URL the user can visit. Use this after a buyer has narrowed in on an area and wants to know which agencies dominate it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| location | Yes | Place name (city, suburb, or urbanisation). e.g. 'Estepona'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety profile is clear. Description adds behavioral details: ranking by active listings, return limit (up to 10), and inclusion of a public URL.
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?
Three sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
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 no output schema, description covers return fields adequately. Usage scenario is clear. Missing details like error handling or location validation, but overall complete for a read-only list 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 coverage is 50% (location described, limit not). Description mentions 'up to 10 agencies' which implies the limit parameter but doesn't clarify which parameter controls it or that it can be changed. Adds some context but not full parameter semantics.
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 names the tool's purpose: find PropertyList agencies in a given Spanish area, ranked by active listings. It specifies the returned data (name, location, listing count, public URL) and distinguishes from siblings like 'area_market_summary'.
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?
Explicitly states when to use: 'after a buyer has narrowed in on an area and wants to know which agencies dominate it.' Does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_noteAInspectLog a note against a contact or a listing in YOUR agency's CRM (e.g. record a call outcome or a viewing). Provide the note text plus a contact_id (from find_contacts) and/or a property reference. The note appears on the contact/property timeline. Requires an agency API key.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | The note text to record. | |
| contact_id | No | Contact to attach the note to (from find_contacts). Optional if a property reference is given. | |
| property_reference | No | Listing reference to attach the note to. Optional if a contact_id is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation; description adds context about API key requirement and timeline effect. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, 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?
Covers key aspects: purpose, parameters, outcome (appears on timeline), and authentication (API key). Adequate for a simple create tool with no output schema.
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 good descriptions. Description reinforces optionality and source of contact_id but adds limited new detail beyond schema.
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?
Clearly states verb (log) and resource (note against contact/listing). Distinguishes from siblings as no other tool logs notes.
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 for when to use with contact_id from find_contacts and optional property reference. Does not explicitly say when not to use, but sibling list has no similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_leadsAList recent enquiries (leads) for YOUR agency's CRM - newest first. Use when the agent asks about their own leads/enquiries (e.g. "what came in today?"). Requires an agency API key; only ever returns the calling agency's own leads.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ISO date/time - only leads created on or after this. Optional. | |
| property_reference | No | Only leads about this listing reference. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral traits: returns newest first, requires agency API key, only returns own agency's leads, which are useful beyond annotations and do not contradict them.
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, front-loaded with the core action and purpose. No unnecessary words; every sentence adds value.
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 3 optional params, no output schema, and good annotations, the description covers purpose, usage, and behavioral constraints. Could mention pagination or return format, but is mostly 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 coverage is 67%, with two parameters described ('since', 'property_reference') but 'limit' only has constraints. The description adds no details about parameters, e.g., how 'limit' affects results or format of 'since', failing to compensate for moderate schema coverage.
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 lists recent leads for the agency's CRM, newest first. It distinguishes from siblings like 'my_listings' and 'submit_enquiry' by specifying leads specifically.
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 says to use when the agent asks about their own leads/enquiries, with an example. It implies context but does not explicitly list when not to use or alternative tools, though the focus on 'own leads' provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_listingsAList YOUR agency's own property listings (newest first), optionally filtered by status or a specific reference. Use for "show my listings" / "is reference X still online?". Requires an agency API key; only ever returns the calling agency's own properties.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | Listing status. Defaults to 'online'. 'draft' covers listings not yet published (new + in review); 'all' returns every status. | online |
| reference | No | A specific listing reference. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable behavioral context: requires an agency API key, results are scoped to the caller's agency, and results are ordered newest first. This goes beyond the annotations by disclosing authentication and data-scoping constraints.
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 with front-loaded purpose, followed by use cases and a key constraint. No redundant phrasing; every clause adds information.
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 tool is simple, has strong annotations, and the description covers purpose, filters, ordering, auth, and scope. It doesn't detail return format or edge-case behavior, but for a list tool with these annotations, this is adequate. Minor gap: no mention of how the 'reference' parameter behaves if not found, but schema context implies empty result.
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 67% of parameters with descriptions (status and reference). The description reinforces that filtering is optional and mentions status/reference explicitly. It does not add detail about the 'limit' parameter beyond what schema provides, so the added semantic value is modest.
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 uses a specific verb ('List') with a clear resource ('YOUR agency's own property listings') and adds ordering and filter details. It explicitly distinguishes this from other property searches by stating it 'only ever returns the calling agency's own properties', setting it apart from generic 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?
It provides direct use-case examples: 'Use for "show my listings" / "is reference X still online?"' This gives clear context for when to employ the tool. It doesn't explicitly state when not to use it or name alternative tools, but the scope restriction makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_propertiesASearch PropertyList's full Spanish property MLS by structured filters. Use for queries that translate cleanly to fields: bedrooms, bathrooms, price ceiling, property type, area name. For free-form briefs use find_properties_by_description instead.
Returns a paginated list with summary text plus structured JSON. Every
property carries oracle_verified and oracle_attestation_url —
true when PropertyList Oracle holds a verified attestation for the listing's municipality and segment.
A location we do not hold returns zero results with
error: location_not_found and location_match.matched: false. It
never substitutes listings from other areas.
location.city is whatever tier the listing was filed under and
may be a municipality OR a locality inside one. To place a listing
administratively use location.municipality (with its INE
municipality_code); it is null, never guessed, when we cannot
resolve it.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| language | No | Preferred language for property titles and description excerpts. | en |
| location | No | Free-text place name (city, suburb, or urbanisation). e.g. 'Marbella', 'Nueva Andalucia', 'Sotogrande'. Pre-resolved with autocomplete_location if you need to confirm match. | |
| page_size | No | ||
| price_max | No | Maximum price in euros (sale) or monthly euros (rent). | |
| price_min | No | Minimum price in euros (sale) or monthly euros (rent). | |
| search_type | No | Listing market. Defaults to 'for-sale'. | |
| bedrooms_max | No | ||
| bedrooms_min | No | ||
| bathrooms_min | No | ||
| property_types | No | Comma-separated slugs: apartments, villas, penthouses, plots, townhouses, commercial. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| error | No | |
| total | Yes | |
| page_size | Yes | |
| properties | Yes | |
| location_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: pagination, return format (summary + JSON), oracle_verified fields, location error handling, and the distinction between location.city and location.municipality. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main purpose first, then usage guidance, return format, and edge cases. It is slightly lengthy but every sentence serves a purpose. Could be trimmed slightly without losing essential info.
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 (11 parameters, output schema exists), the description covers key aspects: pagination, error handling, authentication (oracle), and location nuance. It lacks some parameter-level detail but is sufficient for an agent to invoke correctly.
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 55%, and the description compensates by explaining location semantics and the meaning of oracle fields. It does not describe all 11 parameters individually, but adds value for the most important ones. A more detailed param mapping would improve clarity.
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 searches PropertyList's Spanish property MLS with structured filters, and explicitly distinguishes it from find_properties_by_description for free-form queries. The verb 'search' and resource 'property MLS' are specific and unambiguous.
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 on when to use this tool (structured filters) and when to use find_properties_by_description (free-form). It also explains behavior for unknown locations, but does not explicitly list all situations where the tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_enquiryAInspectSubmit an enquiry (lead) about a specific listing on behalf of a prospective buyer or tenant. Use this once the user has chosen a property and wants the agency to contact them. The listing agency receives the enquiry in their CRM and follows up directly.
Requires an API key. Provide the property reference (from search results)
plus the enquirer's contact details. Only submit with the person's clear
intent and consent - this sends their details to a real estate agency.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Enquirer's full name. | |
| Yes | Enquirer's email address. | ||
| phone | Yes | Enquirer's phone number (with country code where possible). | |
| message | No | Optional message / what they want to know or arrange (e.g. a viewing). | |
| language | No | Preferred language for the agency to reply in. | en |
| reference | Yes | PropertyList listing reference the enquiry is about, e.g. 'PLE-12345'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint=false and destructiveHint=false, the description adds that it sends details to a real estate agency and requires clear consent, disclosing external effect and privacy concerns beyond 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 concise paragraphs, first stating purpose and when to use, second detailing requirements and consent. No fluff, front-loaded with main action.
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 submission tool with good annotations and full schema coverage, description adequately covers what happens (agency receives in CRM, follows up) and when to use. No output schema, but that's acceptable.
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 adds minor context (reference from search results, phone with country code) but mostly reinforces schema. Baseline 3 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 submits an enquiry/lead about a specific listing for a prospective buyer/tenant. It distinguishes from sibling tools (e.g., create_contact, my_leads) by focusing on the enquiry action.
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?
Explicitly says 'Use this once the user has chosen a property and wants the agency to contact them.' Mentions prerequisites (API key, reference from search) and consent requirement. Lacks explicit exclusions of alternative tools but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verified_valuationAGet a valuation for a property or area from recorded market data, not asking prices. Returns the €/m² for the municipality and segment, an indicative valuation when you give a size (build_sqm) or a listing reference, and a content-hashed attestation URL the figure can be cited from.
Check verified before citing. It is true ONLY for Spanish figures
drawn from the notarial register (Consejo General del Notariado) with
at least 10 recorded transactions behind them.
Elsewhere - Portugal and Cyprus especially - the figure comes from a
national house-price index and is an estimate: transaction_backed is
false, source_label names the real source, and it must not be
described as notary-verified. indicative_band_pct widens as the
evidence thins.
Only two segment attestations exist per municipality, so a request for
penthouse or townhouse resolves to the nearest attested segment.
property_type is the segment actually used and
requested_property_type is what you asked for; when they differ the
text says so. Also returns our proprietary network achieved-sale figure
where available. If no attestation covers the area yet, it says so
plainly (use area_market_summary for asking-price stats instead).
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Municipality / city name, e.g. "Marbella". Ignored if a reference is given. | |
| build_sqm | No | Built size in m² to value. Optional. | |
| reference | No | Value a specific PropertyList listing by reference (uses its municipality, type and size). Optional. | |
| property_type | No | Optional segment slug: apartment, villa, penthouse, townhouse, plot. Defaults to the municipality-wide figure. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| network | No | |
| location | Yes | |
| on_chain | No | |
| verified | Yes | |
| build_sqm | No | |
| period_end | No | |
| sample_size | No | |
| content_hash | No | |
| source_label | No | |
| property_type | No | |
| attestation_url | No | |
| indicative_range | No | |
| transaction_backed | No | |
| valuation_estimate | No | |
| indicative_band_pct | No | |
| verified_price_per_sqm | No | |
| requested_property_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent), the description discloses critical behavioral details: the verified flag is true only for Spanish notarial data with 10+ transactions, the fallback to nearest attested segment for penthouse/townhouse, the distinction between property_type and requested_property_type, and the behavior when no attestation exists. This is rich transparency about data provenance and edge cases.
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 long but every sentence earns its place. It front-loads the core purpose, then logically structures verification semantics, segment resolution, and fallback guidance. It avoids repeating schema content and presents technical nuances in a readable, organized manner.
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's complexity (4 optional params, output schema, annotations), the description covers all necessary context: data source differences by country, field meanings, edge cases for segments, and the alternative tool for asking-price stats. It is complete for the agent to understand when and how to invoke the tool correctly.
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?
Although the schema already describes all parameters, the description adds significant meaning: build_sqm and reference trigger an indicative valuation, location is ignored when a reference is given, and property_type resolves to the nearest attested segment when the requested segment lacks attestation. It also explains the relationship between property_type and requested_property_type, which is not in the schema.
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 opens with a specific verb+resource: 'Get a valuation for a property or area from recorded market data, not asking prices.' It clearly states what the tool does and immediately distinguishes it from asking-price stats. It also names a sibling tool (area_market_summary) as the alternative for asking-price stats, reinforcing differentiation.
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 guidance on when to use the tool versus alternatives. It states 'If no attestation covers the area yet, it says so plainly (use area_market_summary for asking-price stats instead)' and warns that figures from Portugal and Cyprus are estimates and must not be described as notary-verified. This provides clear when-to-use and when-not-to-use context.
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!