Skip to main content
Glama
Sign In

flatin.es — new builds and local data in Spain

by es.flatin
OverviewDiscussionsAdmin

New builds on sale in a place (Spain)

newbuilds_in_place
Read-onlyIdempotent

New-build developments on sale in a municipality, buyer zone or province of the flatin.es catalogue: at most 25 per call, sorted by name, no pagination — the full list is on the linked flatin.es page. Facts are the developer's own, latest check only, with attribution.

Input Schema

NameRequiredDescriptionDefault
placeYesMunicipality (name, slug, 'province/municipality' or 5-digit INE code), buyer zone (costa-blanca, costa-del-sol) or province; prefix 'provincia:' / 'zona:' to disambiguate.
localeNoLanguage of names and page links; default en.
bedroomsNoBedrooms wanted; 4 or more means 4+.
max_priceNoHighest budget in euros, VAT included: the price from must not exceed it. Must not be below min_price. Developments without a published price are left out.
min_priceNoLowest budget in euros, VAT included. A development matches when its published price range overlaps [min_price, max_price]; with only a price from, that price must be at least min_price. Developments without a published price are left out.
delivery_byNoCompletion by the end of this year (this year to this year + 4); ready-to-move-in developments always match.
max_beach_kmNoStraight-line km from the development's own location to the nearest beach, rounded up to 1, 2, 5 or 10; only when the site offers the beach filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / max_price / description
      Previous value: -"Budget in euros, VAT included: the price from must not exceed it. search_url uses the site's budget bucket rounded up (named in the answer). Developments without a published price are left out."New value: +"Highest budget in euros, VAT included: the price from must not exceed it. Must not be below min_price. Developments without a published price are left out."
    • changedInput schema / properties / max_price / minimum
      Previous value: -1New value: +1000
    • addedInput schema / properties / min_price
      Added value: +{
+  "description": "Lowest budget in euros, VAT included. A development matches when its published price range overlaps [min_price, max_price]; with only a price from, that price must be at least min_price. Developments without a published price are left out.",
+  "maximum": 100000000,
+  "minimum": 1000,
+  "type": "number"
+}
  2. Changed4 schema fields changed
    • addedInput schema / properties / bedrooms
      Added value: +{
+  "description": "Bedrooms wanted; 4 or more means 4+.",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / delivery_by
      Added value: +{
+  "description": "Completion by the end of this year (this year to this year + 4); ready-to-move-in developments always match.",
+  "maximum": 2100,
+  "minimum": 2000,
+  "type": "integer"
+}
    • addedInput schema / properties / max_beach_km
      Added value: +{
+  "description": "Straight-line km from the development's own location to the nearest beach, rounded up to 1, 2, 5 or 10; only when the site offers the beach filter.",
+  "maximum": 10,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / max_price
      Added value: +{
+  "description": "Budget in euros, VAT included: the price from must not exceed it. search_url uses the site's budget bucket rounded up (named in the answer). Developments without a published price are left out.",
+  "maximum": 100000000,
+  "minimum": 1,
+  "type": "number"
+}
  3. First observed

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses operationally important traits: at most 25 results per call, sorted by name, no pagination, full list available on the linked page, and that facts come from the developer with only the latest check and attribution. These are exactly the kinds of behavioral and data-quality details an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: resource and scope first, then result cap, sort order, pagination behavior, and data provenance. Every clause carries useful information with no wasted prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter read-only listing tool with full schema coverage and no output schema, the description covers scope, result limits, and data freshness well. It could say a bit more about the shape of returned development facts, but it is largely complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters are already well documented in the schema. The description adds no meaningful parameter semantics beyond echoing the place types that the schema already explains in detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific resource and scope: new-build developments on sale in a municipality, buyer zone, or province in the flatin.es catalogue. It is immediately understandable, though it does not explicitly differentiate itself from the unrelated sibling tools such as purchase_costs or ibi_rate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scope (new builds in a Spanish place) and the cap/no-pagination constraint is stated. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative among the sibling tax and comparison tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All flatin.es — new builds and local data in Spain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources