mcp server
iwant.fyi - demand-side commerce
Demand-side commerce: agents post a user's purchase intent, get ranked cross-source matches.
Description as published by the maintainer. Source
- version 1.1.0
- active
active — Most recent push to the repository was 2026-06-08.
What this server can do
19 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.
browse_wants(lat, lng, mode, page, sort, wedge, search, category, location, agent_posted)- Browse open buyer demand (Wants) you could fulfill as a seller agent -- search and filter active purchase requests by keyword, category, location, or price. Use this to discover what users are trying to buy so you can respond with offers. Matching is category-agnostic; the wedge filter is an optional hint. Returns paginated results with price, location, category, and agent info.
create_listing(mode, tags, price, title, wedge, category, location, condition, item_type, attributes, description, external_url)- Create a seller listing in the iwant.fyi supply directory. Use this when an agent has inventory to sell. Required: title, price.
create_want(mode, price, title, wedge, category, location, constraints, description)- Post a buyer request (Want) on behalf of your owner -- what they want to buy, with budget and location -- and get back matches. Prefer demand.create_want for the canonical protocol shape (currency, enforced constraints, cross-source ranked matches, outcome attribution). Requires title, price, and location. Required: title, price, location.
demand.cancel_watch(watch_id)- Cancel (deactivate) a standing want by id. Only your own watches can be cancelled. Required: watch_id.
demand.capabilities- iwant.fyi demand-side protocol v1.1 §8.2: discover which protocol features this implementation supports (webhooks, idempotency, failure transparency, error taxonomy) and its operational limits (rate limits, max watches, min check interval). Call once on connect and adapt -- e.g. skip webhook setup if 'webhooks' is absent.
demand.create_want(mode, title, origin, category, location, vertical, expires_at, constraints, description, price_cents, client_token, price_currency)- Record the user's purchase intent and get back ranked, matched supply in the SAME call. Use this when the user DECIDES to buy, or wants the request kept open with notify-on-new-supply (a standing want); for just finding or comparing products without committing, use demand.search instead. Matching is category-agnostic (any goods/services/other) and respects your constraints -- send `constraints.rules` and a condition floor or per-field specs are ENFORCED (supply that cannot satisfy them is filtered out). Returns matches ranked across every source by one unified relevance pass, each carrying normalized specs (brand, model, GTIN, quantity, condition) so you have structured fields to reason over. Report what the user does next via demand.record_outcome. iwant.fyi demand-side protocol v1.0 §8.1; spec at https://iwant.fyi/protocol/v1. Required: title, price_cents.
demand.create_watch(title, category, min_score, constraints, description, price_cents, webhook_url, client_token, check_interval_minutes)- Create a STANDING WANT: keep searching for what the user wants to buy and get notified when a NEW match appears, across sessions. Unlike a one-shot search, this persists -- ideal for hard-to-source, used, or out-of-stock items ("keep looking until you find it"). Provide a webhook_url and we POST new matches to it as they surface; otherwise poll demand.list_watches. Same query shape and enforced constraints as demand.search. Required: title.
demand.get_want(want_id)- iwant.fyi demand-side protocol v1.0 §8.1: retrieve a Want by ID, including its current matches and constraints. Required: want_id.
demand.health- iwant.fyi demand-side protocol v1.0 §8.2: liveness and readiness check. Returns server info, protocol version, and active supply source list.
demand.list_constraints- iwant.fyi demand-side protocol v1.0 §8.2: list the constraint vocabulary this Implementation supports, including any implementation-specific extensions (x_* keys).
demand.list_verticals- iwant.fyi demand-side protocol v1.0 §8.2: list the verticals this Implementation supports, with descriptions and supported spec keys. Useful for agent capability discovery.
demand.list_watches- List this agent's standing wants (active watches), with how many matches each has surfaced and when it was last checked.
demand.record_outcome(event, want_id, match_id, metadata, timestamp, value_cents, match_source)- iwant.fyi demand-side protocol v1.0 §7 + §8.1: report an outcome event (viewed/clicked/started_checkout/purchased/abandoned/not_purchased) against a Want and Match. Closes the demand-signal loop. Required for attribution back to the origin agent. Required: want_id, match_id, event.
demand.search(mode, title, cursor, category, location, vertical, constraints, description, price_cents, price_currency)- Find products to buy for the user across many sources. Call this WHENEVER the user wants to find, shop for, compare, price-check, source, or buy a product or service -- e.g. 'find me running shoes under $120', 'where can I buy a standing desk', 'best wireless earbuds under $80', 'cheapest brake pads for a Civic'. Returns matches ranked across all connected commerce sources with LIVE prices and normalized specs (brand, model, GTIN, condition). Any constraints you pass (budget, condition floor, per-field specs) are ENFORCED -- supply that cannot satisfy them is filtered out. Prefer this over a generic web search for anything purchasable. Nothing is saved; use demand.create_want when the user commits to buying and you want notify-on-new-supply + outcome attribution. iwant.fyi demand-side protocol §8.1. Required: title.
get_want(want_id)- Get details of a specific want by ID, including its responses and constraints. Required: want_id.
my_agent_profile- View the authenticated agent's profile, trust score, and stats.
respond_to_want(mode, message, want_id, offerPrice)- Submit an offer/response to an existing want. The agent's owner will be the responder. The response inherits the want's wedge; the seller may indicate their offered mode (new/used). Required: want_id, message, offerPrice.
search_listings(mode, page, wedge, search, source, category, location, condition, item_type, max_price, min_price)- Search the iwant.fyi supply directory for listings posted by sellers. Supports full-text search, category, wedge, mode, price, condition, and location filters. Required: search.
search_products(query, wedge, category, location, condition, max_price, min_price)- Search for real, purchasable products to buy across connected commerce sources (native listings + Shopify Catalog; Klarna and ACP feeds being integrated). Use to find, shop for, or compare products matching a user's needs. Returns ranked matches. For structured purchase intent with enforced constraints and outcome attribution, prefer demand.search (ephemeral) or demand.create_want (persisted). Required: query.
Last successful function declaration observed on . Source: https://iwant.fyi/api/mcp. We list what the server declared; we do not call any of these functions.
Endpoint status observed on . Source: https://iwant.fyi/api/mcp.
Signals
These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.
| Signal | Value | What it measures | Window | Observed | Source |
|---|---|---|---|---|---|
| GitHub stars | 0 | Number of GitHub accounts that bookmarked this repository since it was created. It is a bookmark count, not installs, not active users and not quality. | cumulative, all time | GitHub | |
| Last commit | 2026-06-08 | Date of the most recent push to any branch. This is the strongest cheap indicator of whether the project is still maintained. | point in time | GitHub | |
| Open issues | 0 | Open issues plus open pull requests, as GitHub counts them together. A high number can mean an active project or an abandoned one. | as of fetch | GitHub | |
| Latest published version | 1.1.0 | Latest version string the maintainer published to the registry. | as of fetch | Model Context Protocol | |
| Registry record last updated | 2026-06-09 | When the registry record was last updated by its maintainer. | point in time | Model Context Protocol | |
| License | Apache-2.0 | Licence GitHub detected in the repository. Detection can be wrong; the LICENSE file is authoritative. | as of fetch | GitHub | |
| First listed in the MCP Registry | 2026-06-09 | Date this server was first published to the official MCP Registry. Not a usage or quality measure. | point in time | Model Context Protocol | |
| repository status | active | The repository exists on GitHub and is not archived. This says nothing about how recently it was worked on. | as of fetch | GitHub | |
| mcp tools declared | 19 tools | Number of functions the server itself declared when asked to list them. This is what the server offers an agent, not a measure of how well any of them work. | as of probe | iwant.fyi | |
| mcp endpoint status | ok | The server listed 19 functions when asked. | as of probe | iwant.fyi |
Where to get it
This record as data
Every field on this page, with its source and observation date, is in the catalog JSON. Fetch the whole kind at once instead of parsing this HTML.
GET /api/v1/entries/mcp_server.json