AutoIsto CZ — car watch

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

intent_publish_intent

Use this when the user asks AutoIsto to keep watching Czech car listings for them over time (e.g. "let me know until March about an estate car under 300 000 CZK, not diesel"). This does NOT start watching by itself and takes no e-mail address or other personal data: it returns a consentUrl on www.autoisto.cz that the user must open themselves, enter their own e-mail there and confirm by clicking the link AutoIsto 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 cars 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, stored encrypted and never shown to sellers or returned by any tool; pass it only if the user said it. Matches come from listings AutoIsto CZ aggregates from the Czech market (its own sellers' listings and public listings from Czech car portals), so they cover only cars listed on AutoIsto CZ (Czech Republic, CZK) and may be incomplete.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "statement": "<statement>"
    },
    "name": "intent_publish_intent"
  }
}

Input Schema

Name	Required	Description
`buyBy`	No	Date (YYYY-MM-DD) by which the user wants to buy; watching stops after it.
`statement`	Yes	What the car MUST be, as one short Czech (or Slovak) phrase with prices in CZK, e.g. "kombi do 300000 Kč ne diesel".
`niceToHave`	No	Wishes that are not required (never filters), e.g. "tažné, automat".
`hiddenLimitCzk`	No	Optional private maximum price in CZK; 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 AutoIsto page yet; awaiting_email_confirmation = the user filled in the page and must click the link in the e-mail; active = AutoIsto 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.autoisto.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 AutoIsto 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. 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.

Changed3 schema fields changedOct 22, 2026

addedOutput schema / properties / notUnderstood

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

addedOutput schema / properties / understood

Added value: +{
+  "description": "What AutoIsto 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.6/5.0

Behavior4/5

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

Annotations already cover the mutation-safety profile (readOnlyHint=false, destructiveHint=false, not idempotent), and the description adds substantial context beyond them: the consent-URL handoff, the 24-hour draft expiry, encrypted hiddenLimitCzk that is never returned, and the data-source coverage caveat. It stops short of describing the response shape beyond consentUrl/intentCode, keeping it at a 4 rather than 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.

Conciseness4/5

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

Front-loads the use case and the critical non-action (does not start watching by itself), then handles the consent flow, privacy, and data-coverage caveats. It is long but dense with actionable constraints; a couple of clauses (e.g. the source-aggregation detail) could be trimmed without loss.

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?

An output schema exists, so return values needn't be spelled out, and the description nonetheless explains how to use intentCode and what consentUrl requires. For a mutation tool with a privacy-sensitive consent handoff, nothing an agent needs in order to call it correctly is missing.

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, but the description adds genuine guidance for hiddenLimitCzk (pass only if the user said it, stored encrypted, never surfaced) and constrains statement to a short Czech/Slovak phrase. The buyBy and niceToHave semantics are largely left to the schema.

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 action (publishing a watch intent that produces a consent URL) with the resource (Czech car listings) and even names the trigger phrasing. It is clearly distinguishable from siblings like intent_list_matches and intent_withdraw_intent, which it references explicitly.

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 when-to-use trigger with a concrete user example, and clarifies what the tool does NOT do (doesn't start watching itself, doesn't take an e-mail). It also routes the agent onward: read matches via intent_list_matches with the returned intentCode.

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

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