flatin.pt — Portuguese homes: taxes, construction, new-builds

Subscribe an email to new developments or construction

subscribe_digest

Idempotent

Use this when the person asks to be emailed about new-build projects matching a filter (daily) or new construction licensed in one municipality (weekly). Do not use it to have flatin.pt contact them (request_consultation) or to see what is on sale now (search_newbuilds). Ask the person first; nothing is active until they click the confirmation email. city is required for construction and parish works only there; typology, the prices and on_sale work only with new_developments. The answer is the same whether or not the address was already subscribed: never say it was.

Input Schema

Name	Required	Description	Default
`city`	No	Municipality (Lisboa or Lisbon). Required for construction; empty means all of Portugal for new_developments
`what`	No	new_developments: new-build developments matching the filter, daily email when something new appears. construction: newly licensed construction in a municipality ("what is being built"), weekly	new_developments
`email`	Yes	The person's email address
`client`	No	Optional. Your app's host or name: recorded as the request's source
`parish`	No	Optional, construction only: a parish (freguesia) of that municipality
`on_sale`	No	Optional, new_developments: only developments on sale
`language`	No	The person's language: the consent text and the emails come in it. uk is accepted as ua.	en
`typology`	No	Optional. Bedroom counts wanted (T2 = two bedrooms)
`price_max`	No	Optional, new_developments: maximum price in euros
`price_min`	No	Optional, new_developments: minimum price in euros

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 19, 2026

changedInput schema / properties / city / description

Previous value: -"Municipality, Portuguese name (Porto, Lisboa). Required for construction; empty means all of Portugal for new_developments"New value: +"Municipality (Lisboa or Lisbon). Required for construction; empty means all of Portugal for new_developments"

addedInput schema / properties / city / examples

Added value: +[
+  "Porto",
+  "Vila Nova de Gaia"
+]

changedInput schema / properties / client / description

Previous value: -"Optional. Your app's host or name, e.g. claude.ai or chatgpt.com: recorded as the request's source"New value: +"Optional. Your app's host or name: recorded as the request's source"

addedInput schema / properties / client / examples

Added value: +[
+  "claude.ai",
+  "chatgpt.com"
+]

addedInput schema / properties / email / examples
```
Added value: +[
+  "maria@example.com"
+]
```
addedInput schema / properties / email / format
```
Added value: +"email"
```
addedInput schema / properties / language / default
```
Added value: +"en"
```

changedInput schema / properties / language / description

Previous value: -"The person's language: pt, en, ru, ua, de, fr, nl (uk is accepted too). The consent text and the emails come in it. Default: en"New value: +"The person's language: the consent text and the emails come in it. uk is accepted as ua."

addedInput schema / properties / language / enum

Added value: +[
+  "pt",
+  "en",
+  "ru",
+  "ua",
+  "de",
+  "fr",
+  "nl",
+  "uk"
+]

addedInput schema / properties / parish / examples
```
Added value: +[
+  "Paranhos"
+]
```
addedInput schema / properties / what / default
```
Added value: +"new_developments"
```

changedInput schema / properties / what / description

Previous value: -"new_developments (default): new-build developments matching the filter, daily email when something new appears. construction: newly licensed construction in a municipality (\"what is being built\"), weekly"New value: +"new_developments: new-build developments matching the filter, daily email when something new appears. construction: newly licensed construction in a municipality (\"what is being built\"), weekly"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "description": "Always the same, whatever the address's state: a confirmation email was requested; nothing is active until the person clicks it.",
+      "properties": {
+        "confirm_within_days": {
+          "type": "integer"
+        },
+        "consent_text": {
+          "type": "string"
+        },
+        "consent_text_version": {
+          "type": "string"
+        },
+        "frequency": {
+          "type": "string"
+        },
+        "language": {
+          "type": "string"
+        },
+        "scope": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "status",
+        "what",
+        "scope",
+        "frequency",
+        "confirm_within_days",
+        "consent_text",
+        "consent_text_version",
+        "language"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "error": {
+          "type": "string"
+        },
+        "field": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "message": {
+          "type": "string"
+        },
+        "problems": {
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "retry_after_seconds": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "message"
+      ],
+      "type": "object"
+    }
+  ],
+  "description": "Success, or a refusal with an error code. Units: *_cents euro cents, *_eur euros, *_eur_m2 euros per m², *_pct and percent in percent.",
+  "type": "object"
+}

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real behavioral context beyond the annotations: double opt-in ("nothing is active until they click the confirmation email") and the deliberate ambiguity of the response ("never say it was already subscribed"), which pairs with idempotentHint=true. The annotations already cover safety (destructive=false, readOnly=false, openWorld=true), so this addition is the valuable part; it could go further on whether an existing subscription can be cancelled or modified later.

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

Conciseness4/5

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

Front-loads the usage condition, then exclusions, then consent behavior, then parameter constraints — a sensible ordering with no filler sentences. It is dense to the point of being packed with semicolons, but every clause carries distinct information an agent needs.

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

Completeness5/5

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

For a 10-parameter mutation tool with an output schema (so return values need no explanation), the description covers the missing pieces: mode-conditional parameters, consent flow, and post-call phrasing. An agent can call this correctly and report the result appropriately from the description alone.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by consolidating the cross-parameter conditional logic that the schema only states piecemeal — `city` required for construction, `parish` construction-only, `typology`/prices/`on_sale` new-developments-only. It restates some of what individual property descriptions already say, so it is not fully additive.

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

Purpose5/5

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

States a specific verb and resource: subscribing an email address to a digest, with the two modes (daily new-build developments vs weekly licensed construction) spelled out. It explicitly names what it is not (`request_consultation`, `search_newbuilds`), so an agent can separate it from those siblings without opening their schemas.

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

Usage Guidelines5/5

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

Gives an explicit trigger ("when the person asks to be emailed about..."), explicit exclusions with the correct alternative tool named for each, and a procedural prerequisite ("Ask the person first"). Nothing about tool selection is left to inference.

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

All flatin.pt — Portuguese homes: taxes, construction, new-builds tools Inspect

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.