Watches Slovak 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 role in the intent lifecycle: publish, check status, list matches, search current offers, and withdraw. The descriptions explicitly clarify boundaries, such as status vs. matches vs. current offers.
All tool names use consistent snake_case with the same intent_ prefix and a verb_noun structure. The pattern is predictable throughout.
Five tools is well-scoped for the domain, covering creation, status checking, match retrieval, withdrawal, and direct offer search without redundant endpoints.
Core lifecycle is covered, but there is no tool to list all active intents or update an existing intent, which could cause friction if a user loses the intentCode or wants to change criteria. These are minor gaps that can be worked around by 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 properties 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 price and LivinIsto price verdict (per m², against comparable properties nearby) 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 properties listed on LivinIsto and may be incomplete; a property 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?
Annotations already mark this as read-only, idempotent, and closed-world, and the description adds substantial context beyond that: max 20 newest matches, price and verdict at match time, a link, coverage limits from aggregated listings, and the risk that properties may already be sold or rented. This is rich behavioral disclosure.
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 dense but front-loads the trigger and key constraint, and most sentences carry useful information. It is somewhat long, but the length is largely justified by the behavioral context.
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 available, the description does not need to explain return structure in detail, yet it still covers timing, match count, pricing context, coverage limitations, and prerequisites. An agent has enough to decide when and how to call it.
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%, so both parameters are already documented. The description restates that intentCode is required and since returns only newer matches, but adds little syntax or meaning 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?
The description states a specific verb and resource: list properties found for an intent created with intent_publish_intent. It clearly distinguishes this from the sibling intent-management tools by tying the resource to a published intent watch.
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: use when the user asks what LivinIsto has found for an intent. It also clarifies that these are emailed matches, the server cannot post into the conversation, and before confirmation there are no matches, which covers key usage boundaries.
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 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.
| 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 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Use this when the user wants to find a flat, house, cottage or plot for sale or rent in Slovakia now. Pass what they are looking for as one short phrase (Slovak works best), e.g. "2-izbový byt Bratislava do 200000 €". Returns up to 20 properties from LivinIsto's offer in LivinIsto's own order, each with a link to the property on www.livinisto.sk, 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 Slovak market and may be incomplete; no seller or agent contact is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | At most this many properties (default 10; LivinIsto returns at most 10). | |
| statement | Yes | What the user is looking for, e.g. "dom Žilina do 250000 €". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a safe read-only, idempotent search, but the description adds substantial behavioral detail: up to 20 results in LivinIsto's own order, links to listings, what was understood, dropped or relaxed, rent price per month, data incompleteness, and no seller/agent contact. This goes well beyond what the annotations provide.
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 front-loads the trigger and the key action, then packs return behavior and fallback guidance into a compact paragraph. Every sentence carries actionable 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?
With no output schema, the description still explains the result shape, cap, ordering, links, interpretation feedback, and market limitations. An agent has enough to call it correctly and explain limitations to the user.
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 both parameters. The description adds useful semantics for statement, recommending a short phrase and noting Slovak works best, with an example; it does not add much for limit beyond the schema's default and maximum.
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: find flats, houses, cottages or plots for sale or rent in Slovakia now, sourced from LivinIsto offers. The purpose is clear, though it does not explicitly distinguish itself from sibling tools such as intent_list_matches.
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?
Provides a clear trigger: use when the user wants to find a property now, and includes the fallback instruction to offer intent_publish_intent when results are missing or filters were relaxed. It does not explicitly state when to use a sibling like intent_list_matches instead, so it falls short of full alternatives coverage.
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",
+ "sk"
+ ],
+ "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 Slovak). 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 Czech home listings 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.
Watches Czech used-car ads for a buyer. Takes no contact; active only after e-mail opt-in.
Flats, houses and plots for sale or rent in Slovakia: search, price verdicts and prices per m².
Add one secure layer between your agents and this server.