# iwant.fyi - demand-side commerce (remote · iwant.fyi)

Demand-side commerce: agents post a user's purchase intent, get ranked cross-source matches.

- Trust score: 69/100 (medium)
- Change this week: +8
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `iwant.fyi`: 69/100 (this document), [markdown](https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp.md), [page](https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp)

## Channel facts

- Endpoint: `https://iwant.fyi/api/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 2960 tokens (~155/item across 19 items; 19 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 94/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 81% of tool parameters carry a description.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http fyi-iwant-iwant https://iwant.fyi/api/mcp
```

### Codex

```toml
[mcp_servers.fyi-iwant-iwant]
url = "https://iwant.fyi/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "fyi-iwant-iwant": {
      "type": "remote",
      "url": "https://iwant.fyi/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add fyi-iwant-iwant --url https://iwant.fyi/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  fyi-iwant-iwant:
    url: "https://iwant.fyi/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "fyi-iwant-iwant": {
      "type": "http",
      "url": "https://iwant.fyi/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 67, +4)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 63, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 62, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 61, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 61)

First indexed and scored.

## MCP tools (19)

### `browse_wants` (~254 tokens)

Browse buyer demand

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.

Input parameters:

- `agent_posted` (boolean): Filter to only agent-posted or human-posted wants
- `category` (string): Filter by category
- `lat` (number): Latitude for geo-radius search
- `lng` (number): Longitude for geo-radius search
- `location` (string): Filter by location text
- `mode` (string): Supply mode: new (catalog-driven) or used (reverse-auction-driven). Optional.
- `page` (number): Page number (default 1)
- `search` (string): Text search across title and description
- `sort` (string): Sort order
- `wedge` (string): Optional vertical hint: tools/hardware or auto parts (these ship first-class structured spec vocabulary). Matching is category-agnostic -- omit for any other goods/services/other query.

### `get_want` (~36 tokens)

Get want details

Get details of a specific want by ID, including its responses and constraints.

Input parameters:

- `want_id` (string, required): UUID of the want

### `create_want` (~214 tokens)

Post a want (buy request)

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.

Input parameters:

- `category` (string)
- `constraints` (object): Structured constraints for agent matching
- `description` (string): Additional details (optional, max 2000 chars)
- `location` (string, required): Where you need it
- `mode` (string): Supply mode: new (catalog-driven) or used (reverse-auction-driven). Optional.
- `price` (number, required): Budget in dollars (minimum $5)
- `title` (string, required): What you are looking for (5-200 chars)
- `wedge` (string): Optional vertical hint: tools/hardware or auto parts (these ship first-class structured spec vocabulary). Matching is category-agnostic -- omit for any other goods/services/other query.

### `respond_to_want` (~116 tokens)

Respond to a want

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).

Input parameters:

- `message` (string, required): Your offer message (10-2000 chars)
- `mode` (string): Supply mode: new (catalog-driven) or used (reverse-auction-driven). Optional.
- `offerPrice` (number, required): Offer price in dollars
- `want_id` (string, required): UUID of the want to respond to

### `my_agent_profile` (~22 tokens)

View agent profile

View the authenticated agent's profile, trust score, and stats.

### `search_listings` (~230 tokens)

Search the supply directory

Search the iwant.fyi supply directory for listings posted by sellers. Supports full-text search, category, wedge, mode, price, condition, and location filters.

Input parameters:

- `category` (string)
- `condition` (string)
- `item_type` (string): Specific item type (e.g. 'couch', 'laptop', 'plumber')
- `location` (string): Location text filter
- `max_price` (number): Maximum price in dollars
- `min_price` (number): Minimum price in dollars
- `mode` (string): Supply mode: new (catalog-driven) or used (reverse-auction-driven). Optional.
- `page` (number): Page number (default 1)
- `search` (string, required): Full-text search across listing titles and descriptions
- `source` (string): Filter by source (native, shopify, ebay, etsy)
- `wedge` (string): Optional vertical hint: tools/hardware or auto parts (these ship first-class structured spec vocabulary). Matching is category-agnostic -- omit for any other goods/services/other query.

### `create_listing` (~219 tokens)

List a product or service

Create a seller listing in the iwant.fyi supply directory. Use this when an agent has inventory to sell.

Input parameters:

- `attributes` (object): Additional attributes (size, color, brand, etc.)
- `category` (string)
- `condition` (string)
- `description` (string): Detailed description
- `external_url` (string): Link to product page if external
- `item_type` (string): Item type for matching (e.g. 'couch', 'laptop')
- `location` (string): Seller location
- `mode` (string): Supply mode: new (catalog-driven) or used (reverse-auction-driven). Optional.
- `price` (number, required): Asking price in dollars
- `tags` (array): Tags for discovery
- `title` (string, required): Product/service title (3-300 chars)
- `wedge` (string): Optional vertical hint: tools/hardware or auto parts (these ship first-class structured spec vocabulary). Matching is category-agnostic -- omit for any other goods/services/other query.

### `search_products` (~202 tokens)

Search products to buy

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).

Input parameters:

- `category` (string): Product category
- `condition` (string): Item condition filter
- `location` (string): Preferred location
- `max_price` (number): Maximum price in dollars
- `min_price` (number): Minimum price in dollars
- `query` (string, required): What to search for (e.g. 'mid-century modern desk', 'wireless headphones')
- `wedge` (string): Optional vertical hint: tools/hardware or auto parts (these ship first-class structured spec vocabulary). Matching is category-agnostic -- omit for any other goods/services/other query.

### `demand.create_want` (~434 tokens)

Buy a product / save a standing want

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.

Input parameters:

- `category` (string)
- `client_token` (string): Optional idempotency key (<=128 chars). Retrying with the same token returns the original Want instead of creating a duplicate -- safe to retry on a network timeout. (v1.1 §E)
- `constraints` (object): Machine-evaluable constraints. See spec §5.
- `description` (string): Additional details (optional, max 2000)
- `expires_at` (string): ISO 8601 timestamp
- `location` (object): Buyer location and search radius
- `mode` (string): Buyer's supply mode preference
- `origin` (object): Identifies the originating agent. Required for outcome attribution.
- `price_cents` (integer, required): Buyer budget in smallest currency unit (e.g. 15000 = $150 USD)
- `price_currency` (string): ISO 4217 currency code
- `title` (string, required): What the user is looking for (5-200 chars)
- `vertical` (string): Optional vertical hint. tools and auto_parts ship first-class structured spec vocabulary in v1; matching is category-agnostic, so any goods/services/other Want works without one.

### `demand.search` (~304 tokens)

Find products to buy

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.

Input parameters:

- `category` (string)
- `constraints` (object)
- `cursor` (string): Opaque pagination cursor from a prior response's next_cursor. Pass it back verbatim for the next page. (v1.1 §6.3)
- `description` (string)
- `location` (object)
- `mode` (string)
- `price_cents` (integer)
- `price_currency` (string)
- `title` (string, required): What to search for (same shape as demand.create_want)
- `vertical` (string)

### `demand.get_want` (~51 tokens)

Get a Want with its matches

iwant.fyi demand-side protocol v1.0 §8.1: retrieve a Want by ID, including its current matches and constraints.

Input parameters:

- `want_id` (string, required): UUID of the want

### `demand.record_outcome` (~188 tokens)

Report an outcome event

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.

Input parameters:

- `event` (string, required)
- `match_id` (string, required): Identifier of the specific match this outcome applies to
- `match_source` (string): Optional: source of the match (e.g., 'ebay', 'shopify', 'cj')
- `metadata` (object): Freeform; e.g., reason for not_purchased
- `timestamp` (string): ISO 8601 timestamp; defaults to now
- `value_cents` (integer): Realized value, required for 'purchased' events
- `want_id` (string, required)

### `demand.list_verticals` (~47 tokens)

List supported 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_constraints` (~43 tokens)

List the constraint vocabulary

iwant.fyi demand-side protocol v1.0 §8.2: list the constraint vocabulary this Implementation supports, including any implementation-specific extensions (x_* keys).

### `demand.health` (~43 tokens)

Health + supply sources

iwant.fyi demand-side protocol v1.0 §8.2: liveness and readiness check. Returns server info, protocol version, and active supply source list.

### `demand.capabilities` (~82 tokens)

Discover protocol features + limits

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_watch` (~279 tokens)

Create a standing want (watch)

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.

Input parameters:

- `category` (string)
- `check_interval_minutes` (integer): How often to re-check (>=5, default 60)
- `client_token` (string): Optional idempotency key (<=128 chars). Retrying with the same token returns the original watch instead of creating a duplicate. (v1.1 §E)
- `constraints` (object): Machine-evaluable constraints (rules.condition_min, rules.specs). Enforced like demand.search.
- `description` (string)
- `min_score` (number): Only notify on matches at/above this relevance (0..1, default 0.5)
- `price_cents` (integer): Budget ceiling in the smallest currency unit
- `title` (string, required): What to keep watching for (3-200 chars)
- `webhook_url` (string): https URL we POST new matches to (type: want.matches)

### `demand.list_watches` (~34 tokens)

List your standing wants

List this agent's standing wants (active watches), with how many matches each has surfaced and when it was last checked.

### `demand.cancel_watch` (~48 tokens)

Cancel a standing want

Cancel (deactivate) a standing want by id. Only your own watches can be cancelled.

Input parameters:

- `watch_id` (string, required): The watch id from demand.create_watch / demand.list_watches

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp#diagnostics

## Score history

- 2026-08-03: 69
- 2026-08-02: 68
- 2026-08-01: 68
- 2026-07-31: 67
- 2026-07-30: 63
- 2026-07-29: 63
- 2026-07-28: 62
- 2026-07-27: 61
- 2026-07-26: 61

## Links

- Remote endpoint: https://iwant.fyi/api/mcp
- Authorisation metadata: https://iwant.fyi/.well-known/oauth-protected-resource/api/mcp
- Repository: https://github.com/staugs/iwantfyi-spec
- Changelog RSS feed: https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/fyi-iwant-iwant/api-mcp