Watches Czech home listings for a buyer. Takes no contact; active only after e-mail opt-in.
Scored across 5 tools
Each tool has a clearly distinct purpose: publish creates an intent, get checks status, list_matches reads saved matches, search_offers performs an immediate market search, and withdraw stops watching. Although search_offers and list_matches both return homes, their descriptions clearly separate immediate searching from intent-based matching.
All tool names follow the same intent_verb_noun pattern (intent_get_intent, intent_list_matches, intent_publish_intent, intent_search_offers, intent_withdraw_intent). The convention is predictable and consistent throughout.
Five tools is well-scoped for a focused home-watch service. Each tool covers a necessary step in the intent lifecycle without unnecessary surface area.
The core lifecycle is covered: create, check status, view matches, search current offers, and withdraw. A minor gap is the absence of an update operation for changing intent criteria or the hidden limit without withdrawing and republishing.
Use this to check whether an intent created with intent_publish_intent is already confirmed by the user and active, waiting, expired or withdrawn. Requires the intentCode; returns the statement and dates only — never the user's e-mail, the hidden limit or any other personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| intentCode | Yes | The intentCode returned by intent_publish_intent. |
| Name | Required | Description |
|---|---|---|
| buyBy | No | |
| found | Yes | |
| status | No | 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 | No | |
| niceToHave | No | |
| validUntil | No | Date (YYYY-MM-DD) until which the intent is watched (before confirmation: until the draft is deleted). |
| activeSince | No | |
| hasHiddenLimit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds genuinely useful context beyond them: the required intentCode and a privacy guarantee that only the statement and dates are returned, never the user's e-mail, hidden limit, or other personal data. It omits behavior for unknown/expired codes, which keeps it from a 5.
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, both earning their place: the first front-loads purpose and lifecycle states, the second covers the required input and the return/privacy contract. No filler or repetition of the title.
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?
An output schema exists, so return-value documentation is not strictly needed, yet the description still scopes the response to statement and dates. Combined with the input and privacy disclosure, an agent has everything needed to call it correctly; only error/not-found behavior is left unspecified.
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 100% and the single intentCode parameter is fully documented with its pattern and origin, so the schema carries the load. The description only restates that intentCode is required and must come from intent_publish_intent, adding no syntax beyond the schema; baseline 3 applies.
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?
States a specific verb (check) and resource (an intent's state) and enumerates the possible lifecycle states (confirmed/active/waiting/expired/withdrawn), which lets an agent distinguish it from the sibling mutators intent_publish_intent and intent_withdraw_intent without opening a schema.
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?
Frames usage conditionally on an intent created via intent_publish_intent and on verifying confirmation, so an agent knows this is the read/verification counterpart to publishing. It does not explicitly say when not to use it or name a competing tool for listing intents, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what LivinIsto has found for an intent created with intent_publish_intent. These are the same homes LivinIsto e-mails to the user; this server cannot send messages into the conversation by itself. Requires the intentCode; optional since (ISO time) returns only newer matches. Returns at most 20 newest matches with the asking price and LivinIsto price verdict at the time of the match and a link. Before the user confirms the intent there are no matches. Matches come from listings LivinIsto aggregates from the market, so they cover only homes listed on LivinIsto and may be incomplete; a home may already be sold or rented.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Only matches found after this ISO time. | |
| intentCode | Yes | The intentCode returned by intent_publish_intent. |
| Name | Required | Description |
|---|---|---|
| more | No | More matches exist than returned; call again with since. |
| found | Yes | |
| status | No | 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. |
| matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses a hard cap ('at most 20 newest matches'), what is returned (asking price, price verdict at time of match, link), an important channel constraint ('this server cannot send messages into the conversation by itself'), and data-quality caveats (aggregated market listings, may be incomplete, home may already be sold or rented). This is unusually rich behavioral context.
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?
Front-loaded with the trigger condition, then prerequisites, then output shape and caveats — a sensible order. It is slightly long and the caveat sentence is dense, but nearly every clause carries decision-relevant 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?
An output schema exists, yet the description still supplies the operational facts an agent needs: the 20-match cap, the empty-before-confirmation state, and the risk that a listed home is gone. Nothing needed to call it or to set user expectations 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 description coverage is 100%, with both intentCode and since already documented in the schema, so the baseline is 3. The description reinforces that intentCode comes from intent_publish_intent and that since is optional and returns only newer matches, but adds no syntax or format detail 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?
States a specific verb and resource ('list homes found for a property watch') and anchors it to a concrete user question ('what LivinIsto has found for an intent created with intent_publish_intent'). This makes it trivially distinguishable from the sibling write/setup tools intent_publish_intent and 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit triggering condition ('when the user asks what LivinIsto has found') plus two prerequisites: the intent must be confirmed ('before the user confirms the intent there are no matches') and the intentCode is required. It does not explicitly rule out alternative tools, but the sibling set makes the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Use this when the user wants to find a flat, house, cottage or plot for sale or rent in the Czech Republic now. Pass what they are looking for as one short phrase (Czech works best), e.g. "byt 2+kk Brno do 6 milionů". Returns up to 20 homes from LivinIsto's offer in LivinIsto's own order, each with a link to the home on www.livinisto.cz, plus what was understood, which words were not applied and what had to be relaxed. For rent the price is per month. When suggestIntent is true (nothing or little found, or part of the phrase was dropped), offer the user intent_publish_intent with the same statement so LivinIsto keeps watching. Results come from listings LivinIsto aggregates from the Czech market and may be incomplete; no seller or agent contact is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | At most this many homes (default 10; LivinIsto returns at most 10). | |
| statement | Yes | What the user is looking for, e.g. "dům Plzeň do 8 milionů". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, yet the description still adds real operational context: results are capped, returned in LivinIsto's own order, not relevance-ranked, drawn from aggregated market listings that may be incomplete, and omit seller/agent contact. It also explains the suggestIntent signal and that rent prices are monthly. It does not say whether results are cached or how fresh they are beyond 'today'.
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 trigger and the Czech-phrase instruction are front-loaded, and the return-value, suggestIntent and data-quality caveats follow in sensible order. It is dense but every sentence carries information; the only small drag is the mismatch between 'up to 20 homes' and the schema's ten-result ceiling.
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?
There is no output schema, so the description carries the return shape and does so: result count, ordering, containing link, plus the understood/dropped/relaxed diagnostics. Combined with the fallback routing to intent_publish_intent and the incompleteness caveat, an agent has enough to call this and interpret what comes back.
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 the baseline is 3, but the description goes beyond the schema by telling the agent the statement should be one short phrase in Czech and supplying a concrete worked example. It does not reconcile the 'up to 20 homes' text with the schema's caveat that LivinIsto returns at most 10, which leaves the effective limit slightly ambiguous.
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 first sentence names a specific verb (find), resource (flat, house, cottage, plot for sale or rent) and domain (Czech Republic now), which an agent can act on immediately. It also implicitly separates itself from the intent_* siblings by naming intent_publish_intent as the follow-up path rather than a substitute.
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 ('when the user wants to find... now') and an explicit branch: when suggestIntent is true, offer the user intent_publish_intent with the same statement. That routes the agent between this tool and its sibling under a stated condition, not a guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants LivinIsto to stop watching for an intent created with intent_publish_intent. Takes effect immediately; nothing more is e-mailed for it. Requires the intentCode.
| Name | Required | Description | Default |
|---|---|---|---|
| intentCode | Yes | The intentCode returned by intent_publish_intent. |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the effect is immediate and no further e-mail is sent, which tells the agent exactly what 'destructive' means here, plus the prerequisite of holding the intentCode.
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 short sentences, front-loaded with the trigger condition, followed by the effect and the required input. Every clause carries information and nothing is repeated from the title.
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?
With an output schema present, return values need not be explained, and the description covers trigger, effect, and required input for a one-parameter mutation. The only minor gap is whether the stoppage is reversible or requires re-publishing, which the agent must infer.
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 the single parameter is fully documented in the schema, including its 32-character pattern and origin from intent_publish_intent. The description only restates 'Requires the intentCode' and adds no format or lookup guidance, so baseline 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?
States a specific verb and resource ('stop watching for an intent') and explicitly ties the tool to the sibling that created the intent, intent_publish_intent. An agent can distinguish this from intent_get_intent and intent_list_matches without opening any schema.
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?
Gives a clear trigger condition ('when the user wants LivinIsto to stop watching') and names the originating tool, so the agent knows this follows intent_publish_intent. It does not state any when-not conditions or a true alternative, but for a single-purpose unsubscribe tool the routing is unambiguous.
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.
intent_search_offersintent_publish_intent1 field changedInput schema / properties / langAdded 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"
+}intent_publish_intent3 fields changedOutput schema / properties / notUnderstoodAdded value: +{
+ "description": "Words of the statement that are NOT watched for as a filter. Tell the person.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / understoodAdded value: +{
+ "description": "What LivinIsto will watch for, read from the statement (in Czech). Tell the person before they confirm.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "intentCode",
- "status",
- "consentUrl",
- "consentExpiresAt",
- "statement",
- "niceToHave",
- "buyBy",
- "hasHiddenLimit"
-]New value: +[
+ "intentCode",
+ "status",
+ "consentUrl",
+ "consentExpiresAt",
+ "statement",
+ "niceToHave",
+ "buyBy",
+ "hasHiddenLimit",
+ "understood",
+ "notUnderstood"
+]intent_get_intentintent_list_matchesintent_publish_intentintent_withdraw_intentWatches Slovak home listings for a buyer. Takes no contact; active only after e-mail opt-in.
Watches Czech used-car ads for a buyer. Takes no contact; active only after e-mail opt-in.
Watches Slovak used-car ads for a buyer. Takes no contact; active only after e-mail opt-in.
Czech distress real estate — paid tier (full search, owner data, RUIAN).
Add one secure layer between your agents and this server.