AutoIsto — 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 Slovak car listings for them over time (e.g. "let me know until March about an estate car under 15 000 €, 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.sk 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. hiddenLimitEur 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 aggregates from the Slovak market (its own sellers' listings and public listings from Slovak car portals), so they cover only cars listed on AutoIsto (Slovakia, EUR) 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 Slovak or Czech phrase, e.g. "kombi do 15000 € nie diesel".
`niceToHave`	No	Wishes that are not required (never filters), e.g. "ťažné, automat".
`hiddenLimitEur`	No	Optional private maximum price in EUR; 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.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 AutoIsto 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. 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 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.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false): it discloses that no e-mail or personal data is collected, that a consentUrl is returned and must be opened by the user, that unconfirmed drafts are deleted after 24 hours, that matches arrive by e-mail and via intentCode, and that hiddenLimitEur is encrypted and never returned by any tool. It also sets expectations about data coverage limits.

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 condition and kept to one dense paragraph where nearly every sentence carries a rule the agent needs. It is long and has minor repetition of schema facts (hiddenLimitEur handling), which costs a point but not readability.

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?

With an output schema present, the description still supplies the essential hand-off detail (consentUrl, intentCode for intent_list_matches) and the privacy/consent contract, so the agent knows both what to do and what to tell the user. Nothing material is missing for a non-destructive draft-creation tool.

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 already 100%, so the baseline is 3; the description adds operational meaning by telling the agent to pass hiddenLimitEur only when the user stated it and to keep intentCode in the conversation for intent_list_matches. Some of that (encryption, never returned) merely restates the schema, keeping it from a 5.

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 ('keep watching Slovak car listings for them over time') and makes the consent-flow nature explicit, which distinguishes it from intent_get_intent, intent_withdraw_intent and even intent_list_matches (named directly). An agent can tell exactly what this tool creates and what it does not.

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?

Opens with an explicit trigger ('when the user asks AutoIsto to keep watching...'), an inline example of the qualifying request, and an explicit exclusion ('this does NOT start watching by itself'). It also names the follow-up path (read matches via intent_list_matches) and the constraint 'pass hiddenLimitEur only if the user said it'.

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

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