LivinIsto — home watch

Watch new property listings for the user (needs the user's confirmation)

intent_publish_intent

Use this when the user asks LivinIsto to keep watching Slovak property listings (flats, houses, cottages, plots; for sale or rent) for them over time (e.g. "let me know until March about a 2-room flat in Žilina under 150 000 €"). This does NOT start watching by itself and takes no e-mail address or other personal data: it returns a consentUrl on www.livinisto.sk that the user must open themselves, enter their own e-mail there and confirm by clicking the link LivinIsto e-mails them. Never ask the user for their e-mail in the conversation and never open the link for them. An unconfirmed draft is deleted after 24 hours. Matching properties are e-mailed to the user and can also be read with intent_list_matches using the returned intentCode — keep it in the conversation. hiddenLimitEur is optional: the most the user would pay (for a rental, per month), stored encrypted and never shown to sellers or returned by any tool; pass it only if the user said it. Matches come from listings LivinIsto aggregates from the Slovak market (its own listings and public listings from Slovak property portals), so they cover only properties listed on LivinIsto (Slovakia only, EUR) and may be incomplete.

Input Schema

Name	Required	Description
`lang`	No	Optional language of the replies (texts only; codes, URLs and statuses never change). By default the language of the statement.
`buyBy`	No	Date (YYYY-MM-DD) by which the user wants to buy or rent; watching stops after it.
`statement`	Yes	What the property MUST be, as one short Slovak phrase, e.g. "2-izbový byt Žilina do 150 000 €" or "prenájom 1-izbový byt Bratislava do 700 €".
`niceToHave`	No	Wishes that are not required (never filters), e.g. "balkón, výťah".
`hiddenLimitEur`	No	Optional private maximum price in EUR (for a rental, per month); encrypted on receipt and never returned by any tool.

Output Schema

Name	Required	Description
`buyBy`	Yes
`status`	Yes	awaiting_consent = the user has not confirmed on the LivinIsto page yet; awaiting_email_confirmation = the user filled in the page and must click the link in the e-mail; active = LivinIsto is watching; expired = the confirmation link, the buy-by date or the intent's validity ran out; withdrawn = cancelled.
`statement`	Yes
`consentUrl`	Yes	Page on www.livinisto.sk where the USER confirms the intent with their own e-mail. Show it unchanged.
`intentCode`	Yes	Secret code of this intent; use it with intent_get_intent, intent_list_matches and intent_withdraw_intent.
`niceToHave`	Yes
`understood`	Yes	What LivinIsto will watch for, read from the statement (in Slovak). Tell the person before they confirm.
`notUnderstood`	Yes	Words of the statement that are NOT watched for as a filter. Tell the person.
`hasHiddenLimit`	Yes	Whether a hidden limit was stored. Its value is never returned.
`consentExpiresAt`	Yes	ISO time after which the unconfirmed draft is deleted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / lang

Added value: +{
+  "description": "Optional language of the replies (texts only; codes, URLs and statuses never change). By default the language of the statement.",
+  "enum": [
+    "en",
+    "sk"
+  ],
+  "type": "string"
+}

Changed3 schema fields changedOct 22, 2026

addedOutput schema / properties / notUnderstood

Added value: +{
+  "description": "Words of the statement that are NOT watched for as a filter. Tell the person.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / understood

Added value: +{
+  "description": "What LivinIsto will watch for, read from the statement (in Slovak). Tell the person before they confirm.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "intentCode",
-  "status",
-  "consentUrl",
-  "consentExpiresAt",
-  "statement",
-  "niceToHave",
-  "buyBy",
-  "hasHiddenLimit"
-]New value: +[
+  "intentCode",
+  "status",
+  "consentUrl",
+  "consentExpiresAt",
+  "statement",
+  "niceToHave",
+  "buyBy",
+  "hasHiddenLimit",
+  "understood",
+  "notUnderstood"
+]

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond the annotations: no personal data is taken, a consentUrl must be opened and confirmed by the user, unconfirmed drafts are deleted after 24 hours, and the hidden price limit is encrypted and never exposed. It also discloses the data source and its completeness limits (Slovakia only, EUR, aggregated listings), which the annotations (readOnlyHint=false, destructiveHint=false) do not cover.

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

Conciseness4/5

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

Front-loaded with the triggering use case and the consent-flow constraint, then moves to privacy details and coverage caveats. It is dense but every sentence carries operational value; the only minor cost is length, not waste.

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?

Given a mutation tool with annotations, an output schema, and five documented parameters, the description supplies the missing operational context: the consent handoff, expiry, privacy of the hidden limit, and the limited market coverage of matches. An agent has everything needed to call it correctly and explain it to the user.

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 coverage is 100% and already documents lang, buyBy, statement, niceToHave, and the encrypted hiddenLimitEur. The description reinforces the privacy semantics of hiddenLimitEur and the 'never filters' nature of niceToHave, but mostly restates what the schema already says, so the baseline of 3 applies.

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 (publish an intent to watch Slovak property listings) with the exact use-case trigger and an example query. It also names the sibling it pairs with (intent_list_matches) so the agent can distinguish reading matches from creating the watch.

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?

Explicit when-to-use with a concrete example, explicit what-not-to-do (never ask for e-mail, never open the link), and the follow-up path via intent_list_matches. The preconditions (consentUrl flow, 24-hour expiry) are spelled out rather than inferred.

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

All LivinIsto — home watch 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.

Resources

Need Help?