Agentic commerce is fragmenting fast. In the last year alone:

OpenAI's ACP (Agentic Commerce Protocol) lets ChatGPT users buy from a curated list of Shopify merchants.
Google's UCP (Universal Commerce Protocol) lets Gemini agents complete journeys at partner merchants — Shopify, Etsy, Wayfair, Target, Walmart, and others.
Google's AP2 (Agent Payments Protocol) standardizes cryptographic payment authorization for agents.
Anthropic's MCP (Model Context Protocol) gives agents structured tool and data access.

Each of these is a piece of the puzzle. None of them defines how an agent expresses what its user wants in a structured, machine-matchable form.

When a user tells their AI assistant "I need a 1/4-inch drive torque wrench rated 25-100 ft-lb, calibrated within the last two years, under $150, in Brooklyn", the agent has poor options:

Web search and scrape. Brittle, slow, and increasingly legally fraught (see Amazon v. Perplexity).
Hit one retailer's API directly. Limited inventory, no cross-merchant comparison.
Use ACP or UCP. Only partner merchants. Only the checkout end of the funnel.

None of these treat the user's articulated demand as a first-class object. Each chat session re-derives the user's intent from scratch. Demand doesn't persist. Constraints can't be reliably communicated. Outcomes don't flow back to the demand origin. The agent ecosystem has agreed on how to complete a purchase, but not how to find what to purchase.

What the iwant.fyi demand-side protocol does

The iwant.fyi demand-side protocol lives one layer above the supply protocols. It defines:

A canonical Want object — structured purchase intent, durable beyond a single chat session, with vertical-specific schema (year/make/model for auto parts, drive size + torque range for tools).
A vocabulary of Constraints — machine-evaluable filters that go beyond keyword search (price ranges, condition floors, location radius, deadlines, brand allowlists, spec ranges).
A Match response shape — how supply across multiple sources is presented back to the agent, ranked, with reasons, with affiliate-tracked URLs.
Outcome events — how clicks, purchases, and abandonments attribute back to the originating agent and feed into match-quality learning.

It's MCP-native (no transport competition with the protocol Anthropic gave us), Apache 2.0, and intentionally small — v1 has 7 tools and 4 required fields on the Want object.

A working example. A LangGraph agent built on iwant.fyi takes this conversation:

User: My 2018 Honda Civic LX is making a loud squeal when I brake.

Agent: Front brake pads are the most likely cause. Aftermarket OK? Budget?

User: Aftermarket is fine. Around $80.

...and calls demand.create_want with:

{
  "title": "2018 Honda Civic LX front brake pads",
  "price_cents": 8000,
  "vertical": "auto_parts",
  "mode": "any",
  "constraints": {
    "rules": {
      "condition_min": "new",
      "specs": {
        "year_make_model": {"year": 2018, "make": "Honda", "model": "Civic", "trim": "LX"}
      }
    }
  }
}

The implementation fans out across whichever supply sources it has connected (Shopify Catalog, eBay, affiliate networks, direct merchant APIs) and returns ranked matches. Once the user picks one, the agent reports demand.record_outcome back so attribution flows to the originating agent and match quality improves over time.

The protocol doesn't tell the implementation how to match — that's where competition lives. But it standardizes the interface so any agent on any framework can express demand and receive supply in the same shape.

Why now

The supply-side protocols are landing fast. ACP shipped in late 2025. UCP went public in early 2026. AP2 was donated to the FIDO Alliance. MCP itself is approaching ubiquity in the agent dev ecosystem. They're all rapidly standardizing how agents complete purchases.

The demand-side has no equivalent yet. Whoever defines it gets to set the vocabulary for an entire category. We're applying the Stripe playbook to demand instead of payments: be the canonical, opinionated, technically excellent reference. Take care of the boring parts. Let everyone else build on top.

Why open

Demand protocols, like payment protocols, only work if there's one. If we kept this proprietary to iwant.fyi alone, nobody outside our user base would adopt it. By publishing under Apache 2.0 and letting anyone implement, the protocol can become canonical regardless of which implementation people choose.

The spec lives at iwant.fyi/protocol/v1 and on GitHub at staugs/iwantfyi-spec. Both Apache 2.0. Anyone can implement; anyone can fork; anyone can extend.

iwant.fyi as the canonical implementation

We run iwant.fyi as the canonical implementation. It's a real demand-side commerce site. The MCP server at iwant.fyi/api/mcp implements the full spec — all 4 required tools and 3 recommended tools from §8. An HTTP fallback at iwant.fyi/api/v1 mirrors the same surface for non-MCP clients. There's a conformance test kit, four official SDKs, three example agents, and developer docs at iwant.fyi/developers. All Apache 2.0.

SDKs

Four officially maintained adapters, all end-to-end verified against the live implementation:

Package	Language	Framework
`@iwantfyi/sdk`	TypeScript	Generic — works with any MCP client or directly
`iwantfyi-langchain`	Python	LangChain `StructuredTool` factory
`iwantfyi-composio`	Python	Composio action registration
`iwantfyi-crewai`	Python	CrewAI `BaseTool` integration

One factory call returns the seven canonical demand.* tools ready for your agent.

Example agents

Three open-source agents that demonstrate full protocol flows end-to-end:

tools-finder (TypeScript) — Claude Opus 4.7 buyer-side conversational agent using the tool runner pattern, adaptive thinking, and prompt caching.
auto-parts-diagnostic (Python) — LangGraph react agent with year/make/model + symptom diagnostic flow.
seller-agent (Python) — the seller side of the reverse-auction loop. Watches Wants in a wedge, scores against local inventory, auto-quotes.

All in packages/examples/ under Apache 2.0.

Decisions worth flagging

A few opinionated choices in v1 we'd love feedback on:

MCP as transport, not competition. The protocol uses MCP as its transport rather than competing with it. The agent industry doesn't need another transport. (HTTP fallback exists for non-MCP clients per §9, but MCP is canonical.)

Outcome events are agent-reported, not server-detected. We trust the agent to report clicked / purchased. This is more honest, more flexible, and avoids the privacy issues of redirect-tracking everyone. Cost: implementations have to trust their integrating agents.

Spec exists because the implementation needs it, not the other way around. We built iwant.fyi first, hit the gap, then wrote the spec to formalize what was missing. The spec is therefore opinionated by lived implementation experience rather than designed-by-committee.

Vertical specs live under constraints.rules.specs. Year/make/model for auto, drive size + torque range for tools, capacity + season for outdoor gear. The protocol doesn't mandate values — implementations advertise what they support via demand.list_verticals.

Negotiation and escrow are explicitly out of scope for v1. Both are well-known to be hard. The spec defers them to v1.1 or v2 to keep v1 small and shippable.

What we'd love feedback on

Is the constraint vocabulary right? We made opinionated choices on what to include in v1 (year/make/model, torque ranges, deadlines) and defer to v1.1 (negotiation, escrow, federation). Anything missing that should be in v1?
Is the outcome-event model right? Agent-reported vs. server-detected was a non-obvious call. Privacy and flexibility argued for agent-reported; some implementers may prefer server-detected for accountability.
Should this be governed by an open standards body eventually? Today it's just iwant.fyi stewarding the spec. Eventually that needs to be something more legitimate — W3C, IETF, an MCP working group, or something new.

If you have thoughts on any of these — or just want to push back on the whole thesis — open an issue, email us, or jump in on Hacker News when this goes up. RFC-style; v1.1 is open to suggestions on what to deprioritize or re-add.

If you build something on top, we'd love to hear about it.