First-party Spanish, Portuguese and Italian property listings with notarial-verified prices.
Return 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.
Look 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.
Add 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.
Start a new property listing in YOUR agency's CRM from a description. Use when the agent is describing a property they have taken on and wants it in the system.
Creates a DRAFT. It is never published and never appears on the portal from here: the agent adds photographs and the energy rating in the CRM and publishes it themselves. The response includes a direct link to the draft.
Location is resolved against the real area tree, so a town, suburb or urbanisation name is enough. Requires an agency API key.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | Asking price in euros, or monthly rent for a rental. | |
| bedrooms | No | ||
| headline | No | Short headline for the listing. Optional. | |
| language | No | Language the description is written in. Defaults to the agency language. | |
| location | No | Town, suburb or urbanisation, e.g. "Nueva Andalucia" or "Menara Beach". | |
| plot_sqm | No | Plot size in square metres. | |
| bathrooms | No | ||
| build_sqm | No | Built area in square metres. | |
| description | Yes | The property description, in the language the agent wrote it. | |
| search_type | No | Whether it is for sale or for long-term rent. Defaults to for-sale. | |
| property_type | No | apartment, villa, penthouse, townhouse, plot or commercial. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states the tool creates a draft, never publishes it, and that the response includes a direct link to the draft. This aligns with the annotations (readOnlyHint: false, idempotentHint: false, destructiveHint: false) and provides clear side effects.
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 yet complete, delivered in short paragraphs with clear focus. It avoids redundancy and presents key information (purpose, workflow, output) without unnecessary 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?
It covers the tool's primary function, intended usage, key behavioral aspects, and output. Given the 11 parameters and no output schema, the description provides sufficient context for an agent to invoke it correctly without 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?
The schema description coverage is 82%, with most parameters having clear descriptions (e.g., price, build_sqm, search_type). The description adds context for location resolution and clarifies the purpose of fields like property_type. The missing descriptions for 'bedrooms' and 'bathrooms' are self-explanatory.
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 creates a new property listing draft from a description, with explicit mention that it is not published. It distinguishes itself from sibling tools like search_properties or get_property by specifying it's for creating drafts.
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 explicitly states 'Use when the agent is describing a property they have taken on and wants it in the system.' It also explains the workflow (agent adds photos and energy rating later) and notes that location is resolved against the area tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 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.
Match 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it uses Gemini for translation, executes one to three parallel structured searches, merges and ranks results, and returns up to 9 listings with match scores, interpretation, and unresolved items. This gives the agent a solid mental model of how the tool behaves internally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most important information (what it does and when to use it). It then flows into the internal mechanism and the return value. It is slightly longer than necessary, but every clause adds distinct information (parallel searches, merging, ranking, count, match scores, explanation) without 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 2-parameter tool with no nested objects and an output schema, the description is rich enough. It covers scope ('Spanish properties','PropertyList's full MLS'), process, and what the agent will receive back. Annotations cover safety and idempotency, and the output schema likely explains the return shape. The only slight gap is not describing edge cases like language mismatches or external API dependencies, but that is minor.
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 50%, with the 'brief' parameter already well-described (plain-English/Spanish, 10-500 chars). The description enriches that by clarifying what makes a good brief (vague, conditional, lifestyle-heavy) and provides an example. However, it adds no semantics for the 'language' parameter, which is left entirely to the enum values. Since the schema carries some of the load and the description supplements the brief, a 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 starts with a clear, specific verb and resource: "Match Spanish properties from a free-form description." It immediately distinguishes itself from the sibling search_properties (likely structured queries) by focusing on free-form, vague, lifestyle-heavy briefs. The mechanism, using Gemini to convert the brief into parallel structured searches, further clarifies the tool's unique function.
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 statement 'Best for vague, conditional, or lifestyle-heavy briefs' provides explicit guidance on when to choose this tool. It also gives a concrete example of an appropriate brief. However, it does not explicitly state when not to use it or name the structured alternative (e.g., search_properties), so while the context is clear, the exclusion is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch 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 or photos. To contact the listing agency, use submit_enquiry - direct phone or email details are not part of the payload.
Works without an API key up to a daily per-IP allowance of distinct listings; past that, a free API key (https://www.propertylist.es/mcp) raises the allowance.
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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint), so the bar is lower but the description still adds substantial behavioral context: the API-key/rate-limit model ('works without an API key up to a daily per-IP allowance... a free API key raises the allowance') and important data semantics ('location.city is whatever tier the listing was filed under'). These are genuinely useful and go well beyond structured fields.
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 front-loaded paragraphs, each earning its place: core purpose and usage, operational/auth constraints, and a data-quality caveat. There is no fluff, and the most important invocation-relevant information appears first.
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 2-parameter read-only tool with an output schema and strong annotations, the description covers everything needed: what it returns, when to call it, how auth works, where to route alternative intents, and how to interpret a subtle field (`location.city` vs `location.municipality`). Nothing material is missing.
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` is documented in the schema and the description reinforces it with the 'human-readable id' framing. However, the description adds nothing about the `language` parameter, leaving its semantics to the self-explanatory enum and default. The description adds marginal value over the schema for `reference` and no value for `language`, so it sits at the acceptable baseline.
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 a specific verb and resource: 'Fetch the full record for one PropertyList listing by its reference code.' It also distinguishes itself from siblings by naming search_properties and find_properties_by_description as the preceding search tools and submit_enquiry as the contact-related alternative. An agent knows exactly what this tool is for.
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?
Explicit usage guidance: 'Use this once the user has settled on a listing from search_properties or find_properties_by_description and wants details or photos.' It also provides an explicit alternative for a different intent: 'To contact the listing agency, use submit_enquiry.' The when and when-not conditions are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find 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 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.
List recent enquiries (leads) for YOUR agency's CRM - newest first. Use when the agent asks what has just come in (e.g. "what came in today?").
This is the enquiry inbox: an enquiry that arrived from the portal, a website or a microsite. Once an agent starts working a person they live on a pipeline board instead - for those, use my_pipeline. An agency that works everything off the boards can have a busy CRM and an empty inbox here, which is not the same as having no leads.
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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds key behavioral context: it requires an agency API key, only ever returns the calling agency's own leads, and distinguishes this inbox from the pipeline board. It also clarifies that the leads are from portal, website, or microsite enquiries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and ordering, then adds tightly relevant usage guidance and mental-model context. Every sentence earns its place without fluff or 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?
Given that all parameters are optional and the annotations already declare read-only, idempotent, non-destructive behavior, the description fully covers what an agent needs: purpose, differentiation, scope, auth expectation, and examples. No important context appears missing.
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 schema already documents since and property_reference clearly, and limit is self-evident from its type, default, minimum, and maximum. The description does not add much parameter-level meaning beyond the schema, but the schema itself is strong enough that no critical gap remains.
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 ('recent enquiries (leads) for YOUR agency's CRM') and specifies the ordering ('newest first'). It also differentiates from the sibling tool my_pipeline by explaining that leads being actively worked move to the pipeline board.
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 explicitly says when to use the tool, such as when the agent asks 'what came in today?', and when not to use it by directing pipeline-board leads to my_pipeline. It even addresses a common misinterpretation: an empty inbox for board-first agencies is not the same as having no leads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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.
List the cards on YOUR agency's CRM pipeline boards (Kanban), with each board's own stage names and card counts.
Boards: lead, buyer, seller, tenant, nurture (each card is a contact) and property (each card is a listing). Stage names are whatever the agency renamed them to, so read them from the reply rather than assuming.
Call with no pipeline for a summary of every board - use this to answer "what's in my pipeline?" or "how many buyers do I have?". Call with a pipeline for that board's cards, newest activity first.
This is the board view. For enquiries that have just arrived and have not been worked yet, use my_leads instead.
Returns the WHOLE agency's boards, not one agent's cards - an API key belongs to the agency, not to a person. Requires an agency API key; only ever returns the calling agency's own data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cards per stage. Counts are always the full stage total, whatever this is set to. | |
| stage | No | Only cards in this stage. Match on the stage name as it reads on the board (case-insensitive); closed stages such as Won or Lost can be asked for by name. Optional. | |
| pipeline | No | Which board. Omit for a summary of all of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description discloses that the API key belongs to the agency rather than a person, that results are always scoped to the calling agency's own data, that stage names are dynamic and must be read from the reply, and that board cards are ordered by newest activity. These are meaningful behavioral details the annotations alone do not provide.
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?
Every sentence delivers a distinct piece of value: the action, the board/card types, the dynamic stage-name warning, the two call patterns, the sibling distinction, and the agency-level permission scope. It is thorough without being padded.
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 no output schema, the description covers the essential return semantics: board stage names, card counts, board-specific card lists, and summaries. It also explains sort order and treats previously worked-but-unworked leads, giving the agent enough context to select and 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?
The input schema already documents all 3 parameters at 100% coverage, so the baseline is met. The description adds extra parameter-related semantics: omitting `pipeline` produces an all-boards summary, supplying a pipeline returns that board's cards in newest-activity order, and counts are full stage totals regardless of the limit.
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 opening sentence is a specific verb+resource statement: it lists cards on a named resource, 'your agency's CRM pipeline boards,' and clarifies card types by board. It explicitly contrasts with my_leads by calling itself 'the board view,' so an agent can disambiguate it from siblings.
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 call patterns: 'Call with no pipeline for a summary of every board' and 'Call with a pipeline for that board's cards, newest activity first.' It also names a concrete alternative—'For enquiries that have just arrived and have not been worked yet, use my_leads'—so the when-to-use decision is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 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?
Annotations already declare read-only and idempotent behavior, and the description adds meaningful behavioral detail: paginated responses, oracle_verified fields, location-not-found behavior, and the guarantee that searches never substitute listings from other areas. It also clarifies how location.municipality is resolved, including when it is null.
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?
Every sentence carries useful, non-redundant information. The description is front-loaded with purpose and usage, then gives output shape, edge-case behavior, and field semantics in a logically ordered flow. There is no filler or tautology.
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 an 11-parameter search tool with an output schema, the description supplies the meaning an agent needs: when to use it, what gets searched, how location matching fails, and how to interpret municipality versus locality-tier fields. The existence of an output schema covers the return payload, so nothing critical is left unexplained.
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 descriptions already cover language, location, price bounds, search_type, and property_types. The description adds partial coverage for the undocumented bedroom/bathroom parameters and describes them as filter dimensions, but it does not clarify min/max semantics or page/page_size behavior. It is adequate but not fully compensating for the 55% schema coverage gap.
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 names a specific verb and resource: "Search PropertyList's full Spanish property MLS by structured filters." It explicitly lists the filter dimensions and distinguishes itself from the free-form sibling by naming find_properties_by_description, so an agent can separate the tools without guessing.
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 gives a clear when-to-use rule: structured queries that map to fields such as bedrooms, bathrooms, price, property type, and area. It also gives the exclusion: "For free-form briefs use find_properties_by_description instead," which is an explicit alternative with a stated condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit 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.
This is the supported way to contact a listing agency - direct phone or
email details are not exposed by other tools. Works without an API key up
to a small daily per-IP allowance; a free key
(https://www.propertylist.es/mcp) removes it. 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?
Beyond the annotations, the description discloses that the enquiry is delivered to the agency's CRM, that this sends personal details to a third party, that usage works without an API key up to a daily per-IP allowance, and that a free key removes the limit. These are meaningful behavioral and privacy traits that are not present in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then covers operational and consent constraints in a compact, well-organized way. It is longer than average, but every sentence carries useful information for safe invocation, including the API-key allowance and the privacy warning.
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 side-effecting tool with no output schema, the description is unusually complete: it states when to use it, what will happen after submission, how to get the reference, what data is sent, the API-key/rate-limit context, and the consent requirement. An agent has what it needs to invoke it correctly and safely.
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 schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds only modest value by saying the reference comes from search results and that enquirer contact details are required; it does not add format, validation, or behavior details for individual parameters 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?
Description names a specific verb and resource: submitting an enquiry (lead) about a specific listing on behalf of a prospective buyer or tenant. It also distinguishes this from generic contact/listing operations by explaining that it is the supported way to reach a listing agency and that direct phone/email details are not exposed by other tools.
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 gives an explicit trigger ('once the user has chosen a property and wants the agency to contact them'), an explicit prerequisite (clear intent and consent), and an explicit alternative boundary (other tools do not expose direct contact details). This leaves little ambiguity about when submit_enquiry should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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 |
|---|---|---|---|
| build | No | Alias of build_sqm. | |
| 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. | |
| build_size | No | Alias of build_sqm. | |
| 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 annotations (readOnly, idempotent), the description discloses the verification logic (verified field only true for Spanish notarial data), the content-hashed attestation URL, and the fallback respectively. It also notes the difference between property_type and requested_property_type, adding context not present in 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: a clear purpose first, followed by key behavioral notes, and finally edge cases. All information is dense and relevant, with no redundancy or filler.
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 (6 parameters, output schema, regional variations, segment limitations), the description covers the essential operational context: verification handling, geographical differences, segment fallback, and an explicit alternative tool. It leaves no critical ambiguity for the agent.
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% and descriptions are clear, but the tool description adds value by explaining the interaction between property_type and requested_property_type, and how build_sqm influences the valuation type. This goes beyond the schema and justifies a score above the baseline.
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 fetches a valuation from recorded market data (not asking prices), returning €/m² and an attestation URL. It distinguishes from siblings like area_market_summary by explicitly tailoring for market data insights.
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 explicit guidance on when to use this tool (for notary-verified Spanish data) versus area_market_summary for asking-price stats. It also cautions against citing Portugal/Cyprus figures as notary-verified and explains the segment fallback for penthouse/townhouse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
find_properties_by_description1 field changedInput schema / properties / language / enumPrevious value: -[
- "en",
- "es"
-]New value: +[
+ "en",
+ "es",
+ "de",
+ "fr",
+ "it",
+ "nl",
+ "pt",
+ "bg",
+ "el",
+ "da",
+ "sv",
+ "no",
+ "fi",
+ "pl",
+ "ru"
+]get_property2 fields changedInput schema / properties / language / enumPrevious value: -[
- "en",
- "es",
- "de",
- "fr",
- "it",
- "nl",
- "pt",
- "bg",
- "el",
- "da",
- "sv",
- "no",
- "fi"
-]New value: +[
+ "en",
+ "es",
+ "de",
+ "fr",
+ "it",
+ "nl",
+ "pt",
+ "bg",
+ "el",
+ "da",
+ "sv",
+ "no",
+ "fi",
+ "pl",
+ "ru"
+]Output schema / properties / property / properties / features_languageAdded value: +{
+ "type": "string"
+}search_properties1 field changedInput schema / properties / language / enumPrevious value: -[
- "en",
- "es",
- "de",
- "fr",
- "it",
- "nl",
- "pt",
- "bg",
- "el",
- "da",
- "sv",
- "no",
- "fi"
-]New value: +[
+ "en",
+ "es",
+ "de",
+ "fr",
+ "it",
+ "nl",
+ "pt",
+ "bg",
+ "el",
+ "da",
+ "sv",
+ "no",
+ "fi",
+ "pl",
+ "ru"
+]submit_enquiry1 field changedInput schema / properties / language / enumPrevious value: -[
- "en",
- "es",
- "de",
- "fr",
- "it",
- "nl",
- "pt",
- "bg",
- "el",
- "da",
- "sv",
- "no",
- "fi"
-]New value: +[
+ "en",
+ "es",
+ "de",
+ "fr",
+ "it",
+ "nl",
+ "pt",
+ "bg",
+ "el",
+ "da",
+ "sv",
+ "no",
+ "fi",
+ "pl",
+ "ru"
+]my_pipelinecreate_listingverified_valuation2 fields changedInput schema / properties / buildAdded value: +{
+ "description": "Alias of build_sqm.",
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / build_sizeAdded value: +{
+ "description": "Alias of build_sqm.",
+ "minimum": 1,
+ "type": "integer"
+}my_listings2 fields changedInput schema / properties / status / descriptionPrevious value: -"Listing status. Defaults to 'online'."New value: +"Listing status. Defaults to 'online'. 'draft' covers listings not yet published (new + in review); 'all' returns every status."Input schema / properties / status / enumPrevious value: -[
- "online",
- "offline",
- "sold",
- "all"
-]New value: +[
+ "online",
+ "offline",
+ "sold",
+ "draft",
+ "all"
+]verified_valuation4 fields changedOutput schema / properties / indicative_band_pctAdded value: +{
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / requested_property_typeAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / source_labelAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / transaction_backedAdded value: +{
+ "type": "boolean"
+}area_market_summary5 fields changedOutput schema / properties / errorAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / location_matchAdded value: +{
+ "properties": {
+ "exact": {
+ "type": "boolean"
+ },
+ "matched": {
+ "type": "boolean"
+ },
+ "matched_areas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matched_location": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "requested": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / price_basisAdded value: +{
+ "type": "string"
+}Output schema / properties / price_unitAdded value: +{
+ "enum": [
+ "total",
+ "per_month",
+ "per_week"
+ ],
+ "type": "string"
+}search_properties2 fields changedOutput schema / properties / errorAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / location_matchAdded value: +{
+ "properties": {
+ "exact": {
+ "type": "boolean"
+ },
+ "matched": {
+ "type": "boolean"
+ },
+ "matched_areas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matched_location": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "requested": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}area_market_summaryautocomplete_locationcreate_contactfind_contactsfind_properties_by_descriptionget_propertylist_agencieslog_notemy_leadsmy_listingssearch_propertiessubmit_enquiryverified_valuationClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
GDPR-clean property listings, rents, price stats, yields and below-market deals. UK, EU.
Portugal real estate search — 224,000+ listings, commute times and market prices
AI-native real estate discovery with structured property search and market intelligence.
Spanish public property auctions (judicial, AEAT, Social Security): daily data and risk flags.
Add one secure layer between your agents and this server.
Most tools have clear, distinct purposes. Some confusion possible between search_properties and find_properties_by_description, but descriptions clearly differentiate structured vs. free-form. Also area_market_summary vs verified_valuation both provide market data, but different types (asking vs notary). Overall well-differentiated.
All tool names follow a consistent verb_noun snake_case pattern: create_contact, create_listing, find_contacts, get_property, list_agencies, log_note, search_properties, etc. Names are predictive and actions are clear.
14 tools is on the higher end of the ideal range (3-15) but appropriate for a property platform that covers both public MLS search and agency CRM functions. It could be split into two servers (public search vs. agency CRM) but still remains manageable.
Covers core flow well: location lookup, market context, search, property details, valuations, and agency CRM (contacts, listings, leads, notes). Minor gaps: no tool for updating a listing (create_listing only creates drafts), and no delete/update for contacts. But primary workflows are supported.