Draft v0.1 — published for review. Not final until approved; may change incompatibly before 1.0.
Protocol v0.1 draft
istointents.com

Binding: MCP (Model Context Protocol)

On this page
  1. Tools for buyer agents (OAuth required — they act for a person)
  2. Tools for sellers and seller agents
  3. Tools for anyone (read-only, no OAuth)
  4. Rules specific to agents
  5. Consent-link profile (v0.1 addendum, 2026-10-11)
  6. Existing servers

AI assistants reach an Isto Intents intent holder through MCP. This binding defines the tools a holder's MCP server exposes. Transport and authorisation follow the MCP specification (Streamable HTTP, OAuth 2.1 for anything that acts on a buyer's behalf).

Tools for buyer agents (OAuth required — they act for a person)#

tool input output notes
intent_publish_intent statement, optional criteria, area, budget, hiddenLimit (plain number, sealed by the holder on receipt), buyBy, validUntil Intent (without the sealed limit) + consentUrl when consent is missing The holder MUST obtain consent on its own page; an agent cannot grant it
intent_get_intent id Intent
intent_update_intent id, changed fields Intent renewing validUntil requires the buyer's fresh action
intent_withdraw_intent id { status: "withdrawn" } MUST take effect immediately
intent_list_matches intent, since? [{ offer: Offer, deliveredAt }] the offers the holder has delivered for the intent; anything the holder adds goes under extensions

Tools for sellers and seller agents#

tool input output notes
intent_demand_summary category, one cell of the holder's band grid DemandSummary or withheld spec §6; MAY be public without OAuth
intent_submit_offer Offer with source.kind = "reply" and inReplyTo { accepted } only for intents with visibility: pseudonymous; the seller never receives buyer contact

Tools for anyone (read-only, no OAuth)#

tool input output
intent_search_offers statement Offer[] — the holder's ordinary catalogue search

Rules specific to agents#

  1. A tool result MUST NOT include buyer contact, pseudonyms of other buyers, or any hidden limit.
  2. Tool descriptions MUST state that results come from a market aggregator and may be incomplete.
  3. Holders MAY limit the rate of requests.

A holder MAY offer the buyer tools without OAuth under this profile. It exists because most assistants today connect to a holder's MCP server without signing the person in, and because the safest place for an e-mail address is the holder's own page, not the conversation.

  1. intent_publish_intent takes no contact data at all — no e-mail, phone or name field in its input schema. It stores a draft that is not an intent: nothing is delivered for it, it is not counted in any DemandSummary and it expires within 24 hours.
  2. The result carries an intentCode (a secret of at least 128 random bits) and a consentUrl on the holder's own domain. On that page the person enters their own contact, reads the consent text (the same text as the holder's other channels) and submits; the holder then verifies the channel (double opt-in). Only after that is the intent active. An agent cannot complete these steps and MUST NOT try (open the link for the person, fill in the form).
  3. Taking over a draft is first-come: once a person has given consent, the same link cannot be taken over again.
  4. The intentCode replaces the OAuth identity for intent_get_intent, intent_list_matches and intent_withdraw_intent. Whoever holds it may read the intent's statement and the offers delivered for it and may withdraw it — the same power as an unsubscribe link in an e-mail footer. It MUST NOT give access to contact data, the hidden limit (only a hasHiddenLimit boolean) or confirmation tokens, even after the intent is confirmed.
  5. A hidden limit MAY be passed to intent_publish_intent; the holder seals it on receipt and the consent page shows only that a limit is set, never its value.
  6. Because an MCP server cannot push into a conversation, results are pulled: the agent keeps the intentCode and calls intent_list_matches (optionally with since). Delivery to the verified channel continues independently.
  7. Usage metering, if any, MUST NOT record the statement, the code or the contact.

Statuses: awaiting_consent → awaiting_email_confirmation → active; or expired / withdrawn.

Existing servers#

Servers that implement this binding are listed, with the countries, categories and languages they serve and the result of an automated check, in the Isto Intents Registry at https://istointents.org/registry.json — see Discovery and Registry. The first ones are AutoIsto s. r. o.'s consent-link servers for Slovakia and Czechia (vehicles and property). A holder's catalogue-search MCP server, if it has one, is separate from its intent server.