LivinIsto CZ — home watch

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

intent_publish_intent

Use this when the user asks LivinIsto to keep watching Czech property listings (flats, houses, cottages, building plots; sale or rent) for them over time (e.g. "let me know until March about a 2+kk flat in Brno under 5 million CZK"). This does NOT start watching by itself and takes no e-mail address or other personal data: it returns a consentUrl on www.livinisto.cz 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 homes are e-mailed to the user and can also be read with intent_list_matches using the returned intentCode — keep it in the conversation. hiddenLimitCzk is optional: the most the user would pay in CZK (monthly for rent), 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 Czech market (its own listings and public listings from Czech property portals), so they cover only homes listed on LivinIsto (Czech Republic, prices in CZK) and may be incomplete; no commercial property and nothing abroad.

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 home MUST be, as one short Czech phrase, e.g. "byt 2+kk Brno do 5 milionů" or "pronájem 1+kk Praha do 18000".
`niceToHave`	No	Wishes that are not required (never filters), e.g. "balkon, výtah".
`hiddenLimitCzk`	No	Optional private maximum price in CZK (monthly for rent); 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.cz 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 Czech). 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",
+    "cs"
+  ],
+  "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 Czech). 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.5/5.0

Behavior5/5

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

Annotations cover the basic safety profile, while the description adds critical behavior: a consentUrl is returned, the user must confirm by e-mail, the assistant must not collect the e-mail or open the link, drafts expire after 24 hours, and hiddenLimitCzk is encrypted and never exposed. This is unusually complete behavioral context for a non-read-only tool.

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?

The description is front-loaded with the primary use case and consent flow, and most sentences carry necessary privacy or scope information. It is somewhat dense and long, but the length is largely justified by the consent and data-handling requirements.

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 the presence of an output schema, the description need not explain return values in detail, yet it still mentions consentUrl and intentCode. It also covers matching behavior, coverage limitations, deletion timing, and privacy constraints, leaving little ambiguity for correct invocation.

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 schema already documents most parameters. The description adds meaningful semantics for hiddenLimitCzk, including privacy handling, monthly-for-rent interpretation, and the rule to pass it only if the user volunteered it.

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 states a specific action: setting up a watch request for Czech property listings that requires user consent. It clearly distinguishes this from reading matches via intent_list_matches, though it does not explicitly differentiate from sibling tools such as intent_get_intent or intent_withdraw_intent.

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?

It gives explicit when-to-use guidance tied to the user asking LivinIsto to keep watching listings over time. It also states what the tool does not do, when to pass hiddenLimitCzk, and which sibling tool to use for reading matches.

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

All LivinIsto CZ — 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?