Buy-Box: a free MCP server that gives every AI agent the same buying criteria

Showcase Built for Cursor
1

I use Claude, ChatGPT, Grok, Gemini and Cursor, and I kept re-explaining what I’m shopping for to each one. So I built Buy-Box: you save a “buy box” (budget, must-haves, dealbreakers) once, and any agent you connect reads it before it searches or recommends.

I use it for a house search and a car search, but it works for anything: laptops, flights, furniture, gifts.

Tools: set_buy_box, get_buy_box, list_categories, score_candidates, export_buy_box, delete_buy_box

Add to Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "buy-box": { "url": "https://buybox.agentconsult.ai/mcp" }
  }
}

Cursor will prompt you to sign in (OAuth, no API key or client ID to set up). Then try:

Save a buy box for a used car: under $25k, AWD, under 60k miles, no Nissans.

Later, in any connected agent:

Score these listings against my car buy box.

Details

  • Remote MCP server, Streamable HTTP, nothing to install
  • Your boxes are private to your account; export or delete them with a tool call
  • Never collects payment details or shopping site passwords
  • Listed on the official MCP Registry, cursor.directory and Glama
  • Tested in Cursor, Claude, VS Code and Gemini

Free during early access. I’m looking for early users to tell me what breaks or what’s missing, so reply here with feedback.

https://buybox.agentconsult.ai

4

How do updates work when two agents use the same box? If I lower the budget in Cursor while another agent still has the old criteria, can its next update overwrite that change? A revision check or a clear “last update wins” rule would be useful to know before sharing a box across agents.

6

Good question. Right now it’s last-write-wins, but per field, not for the whole box.

  • Updates merge by default. A write only touches the fields it sends, so if Cursor lowers budget and another agent later adds a dealbreaker, the new budget stays.
  • The risk is a stale agent re-sending budget from an old read. That will overwrite the change. So will a replace=true call, which rewrites the whole box.
  • Agents are told to call get_buy_box before writing, and every box has a last_updated timestamp. Nothing on the server enforces that yet, though.

I’m adding an optional revision check: pass the last_updated you read, and the write is rejected if the box changed since then. Until that ships, the safe pattern is to read right before you write and avoid replace=true on shared boxes.

7

Thanks for spelling out the field-level behavior. For the revision check, I’d test two agents reading the same version, then submitting conflicting budget changes at the same time: only one should succeed. The version check and write need to be one atomic operation for that test to pass. I’d also check rapid updates that might share a timestamp at your storage precision. A revision counter could avoid that ambiguity. On rejection, returning the current version would let the agent re-read and reconsider its intended change instead of blindly replaying the stale patch.