Skip to content
Buying
Sign in

Setup

Connect your AI assistant

One-time OAuth setup. Then your chosen AI can continue a Mission you shaped, or return a bounded Queue result when you ask.

Assist With Buying is a durable place to keep research for you and your chosen AI. Start with a Mission question, criteria, notes, sources, and a decision yourself; when you want help, your AI can read that exact context and return structured Findings without replacing what you said matters.

The setup instructions below are public and readable without JavaScript. Account data stays private and is only available to an assistant after you approve OAuth access.

Plain-text agent setup URL: https://assistwithbuying.com/ai.txt.

A private account is required for OAuth approval

Anyone can read these setup instructions. When an AI client opens the OAuth approval screen, sign in to the free AWB account whose private account you want that client to use.

Create or sign inConnect your AIFor your AI
If you are an AI agent reading this page

Do not try to read the user's private research by fetching website pages. The web app intentionally hides account data from ordinary unauthenticated requests.

To work with AWB, the user must connect you as an MCP client using the endpoint https://assistwithbuying.com/mcp. Authentication is OAuth in the user's browser. Do not ask the user for an AWB API key; static API keys are not shipped yet.

Operating this website in a browser for the person? Stop and connect through /connect instead: edits typed into the site are signed as them and lose the prices, statuses and screenshots the tools keep.

AWB exposes eighty-seven workflow-shaped MCP tools. Signing in and allowing the client is the approval; it grants every permission in the vocabulary until the person removes it, with no end date, including attaching a photograph and contributing to the shared public directory. Nothing is withheld pending a request. Many AI apps ask the user to approve calls; prefer the complete-result save, and buying_capture for a whole sale, to reduce approval fatigue — and tell the person they can set the write tools to Always allow once, which is the only real fix when a prompt goes unanswered.

A scripted lifecycle harness re-proves this server's side of the contract on every deployment: anonymous challenge, scope-filtered listing, bounded read, idempotent write, cross-owner refusal, malformed and replayed requests, revoke denial, reconnect, and synthetic cleanup. What it does not prove is any particular AI client's own environment. Earlier dated production acceptances (2026-08-12 through 2026-08-14) predate the grant boundary and are not a current compatibility claim for any named client. No client is named as supported until it completes the full lifecycle under grants in its own environment.

If you only see the old heading "Your AI assistant" and "Loading...", your fetch layer is reading a stale cached copy. Fetch https://assistwithbuying.com/ai.txt instead.

Call buying_get_brief first. Search before creating, then read the Mission context before correcting it. Keep reusable products separate from Mission-specific offers.

A person may already have written the question, accepted criteria, saved notes or sources, and recorded a bounded decision in the Mission desk. Treat those as durable context: preserve accepted criteria, propose rather than silently adopt new ones, and append source checks or a newer decision without erasing the person's history.

For capture photos, call buying_get_capture_images when there are several file ids, or buying_get_capture_image for one file, and inspect the returned inline image. Do not try web_fetch, bash, curl, or browser fetch on files[].url first; an AI app's ordinary network sandbox may block an ordinary HTTP request even though MCP can return the image directly. That is the client's network layer, not a Buying grant failure.

For uploads, buying_attach_photo returns a short-lived PUT capability on assistwithbuying.com. It never redirects to or exposes Backblaze. The normal fast appraisal save is buying_log_appraisal; the normal Mission save is buying_save_complete_result.

Claude-specific evidence, checked 2026-09-02: if that client's code execution blocks the first-party PUT, the narrow setting is Settings → Capabilities → assistwithbuying.com. All domains works but is broader and unnecessary. Start a new Cowork conversation after changing it. This is separate from MCP/OAuth, and Backblaze must never be allowlisted. This is troubleshooting evidence, not a current named-client support claim.

Prefer buying_save_complete_result after normal research. It saves the Mission, options/products, dated observations, comparison, source outcomes, optional decision, and optional Queue outcome atomically. Stable keys make retries safe.

Normal MCP context withholds seller contacts. The connector cannot message, negotiate, buy, move money, or delete or publish your private research. The four Places tools are a narrow exception: after explicit confirmation they can create a public location, add one short privacy-scrubbed contribution, and withdraw that same person's contribution.

What connecting does

When you sign in and click Allow, that is the approval. Your AI can then read your Missions, save research, work your Queue, open your captured photos, attach one, and add venues and privacy-scrubbed notes to the shared directory — all of it, until you remove it. There is no end date and no second screen to find afterwards, and nothing is held back waiting for you to ask for it.

What no approval here can ever allow is a different question, and those limits do not move: no AI connected to Buying reveals a seller's contact details, contacts or negotiates with anyone, makes an offer, spends money, completes a purchase, deletes or exports your workspace, publishes your private research, or reaches any other person's workspace.

Setup takes a few minutes, not seconds. Two steps in it are yours and cannot be handed to an assistant: signing in, and clicking Allow. If it stops and waits for you there, it is meant to.

Afterwards, Connect your AI is where you see what it did and change it later — narrow it to less, or revoke it outright. It is not a gate you have to pass. The change reaches your AI on its very next request. And you never have to connect anything: you can hand work to any assistant by copying a Queue brief and pasting the answer back yourself.

Your assistant's own reading is For your AI: every tool this endpoint answers, what each one does, the calls worth making first, and the rules it runs under. It is public, so you can point yours at it before you have decided anything.

The rules every connection runs under

  • Signing in through OAuth and allowing the client is the approval. From that moment the connection holds mission.read, mission.write, queue.read, queue.write, media.read, media.write, places.read, places.contribute, research.files.read, research.files.write until the person removes it. Buying issues and receipts that authority separately from OAuth identity.
  • That baseline is the "ordinary-research" policy, version 5, decided 2026-09-28. Every grant records which policy issued it. A connection issued under an older version and never narrowed by the person is widened to the current default on its next call, and the ledger entry names both versions.
  • A selected-Mission connection must cover every existing subject of a continued pass and every supplied subject on the same grant. Supplying an allowed Mission does not authorize a different pass. An unreadable, empty or incomplete existing subject set is refused; the boundary reads up to 50 subjects and refuses larger sets for a narrowed connection.
  • Active approvals from before connections lost their expiry date remain usable, however many historical grants the account holds. Discovery, connection status and authorization use the same complete client lookup, including eligible unbound approvals; revoked grants and grants bound to another client never supply authority.
  • Nothing is withheld pending a request: every permission in this vocabulary is granted by signing in. https://assistwithbuying.com/connect is where the person narrows a connection or revokes it if they want less, never where they go to unlock ordinary use.
  • Attaching a photograph writes stored bytes rather than sentences, and "media.write" is nevertheless granted by signing in: this is a product for photographing things at sales, and the assistant that writes an Appraisal is the one holding the picture of what it appraised. The care that decision needs is in the tool rather than in the tier. A photograph an assistant attaches is filed as attached by that assistant, named and dated, never as one the person took; one at a time, under a hard size ceiling, with the bytes re-read and checked server-side; it lands as a private file, kept exactly as sent with its location and capture time (private to the workspace; a share only ever serves a location-free copy), and nothing an assistant may call can make it public or take it back. The person removes it in the product, and narrows the permission in one click at https://assistwithbuying.com/connect.
  • An assistant proposes and answers; the person decides. A suggestion is raised with buying_propose_suggestion and waits: there is no tool that accepts one, and an Appraisal never becomes a Mission by machine — growing one is the person's own action. Both omissions are deliberate.
  • Work the person ASKED to have done later is written down with buying_queue_for_later: an ordinary Waiting ask, marked "Left by your AI, at your request", that starts nothing. An idea the assistant had on its own is never filed that way; it is a suggestion, and waits for the person.
  • buying_queue_for_later handles each ask atomically; a refusal writes nothing for that ask. Replay an operationId with the complete original ask, including thing fields; changed content conflicts, and legacy thing asks without their original payload cannot safely replay.
  • buying_capture returns a saved Item and its receipt even when only the outcome is refused: saved[].outcomeRefused describes that refusal instead of claiming saved[].outcome. come_back also records a Trip return intention. Bundle allocations use accepted active Listed tags, estimates only when no tags exist, then even shares per object. Predictions, comparables and list prices do not establish tags or tag discounts.
  • A verdict on an Appraisal is optional and always shown as the answering assistant's, named and dated. Buying does not certify what a thing is worth, and no answer is ever presented as Buying's own.
  • Purchase replays preserve omitted metadata and companion attribution. For bundles, tagCents uses the Item's per-unit or whole-lot basis, unitCents is per unit, and totalCents is a whole-line weight fallback. Quantity is recorded separately. Replay the complete original purchase-key set; person-adjusted shares and the recorded total are preserved, and incompatible replays are refused. Each bundle contributes to private seller statistics once; corrections apply the contribution difference.
  • Type writes refuse a child whose parent has the same normalized name, and refuse moving a subtree when its bounded descendant walk is incomplete; no partial ancestry rewrite is saved.
  • Fewer calls, same result. Read once at the start — buying_get_brief and buying_get_preferences — rather than re-reading between saves. Batch every sweep: buying_save_items_batch for listings, buying_save_purchases_batch for a receipt, buying_update_list for several entries and their run. Ask for a page and follow its cursor instead of raising a limit until a whole table comes back. Link a record in the same call that saves it. Prefer the one tool that summarises a block over assembling it from five.
  • A preference is saved only when the person explicitly asked for it, and buying_save_preference records their own words as the reason. Anything an assistant merely inferred goes to buying_propose_preference and waits; nothing reads a pending proposal as a standing fact, and there is no tool that adopts one. A preference is readable back to an assistant only after the person opens that row themselves, so creating one does not make it visible to the assistant that wrote it. The one exception the person chose: what they look for — their wants, collections and shopping habits — is written for their own AI to read, so those three kinds start open and they close any of them in one click.
  • buying_import_sale identifies an event by its normalized listing URL within your workspace, independently of its title. Different listing identities remain different events; re-importing the same identity reuses the event. Existing Place prose is retained; replacing it requires buying_save_place_description explicitly.
  • buying_get_trip day.total.byCurrency and day.stops[].byCurrency report currency, spendCents, companionCents, retailCents, retailLines and paidAgainstRetailCents separately per currency. Legacy money totals and day.currency are null for mixed currencies. Compare retail only with purchases in the same currency; companion lines remain attributed evidence outside personal spending.
  • Taking an Item off a Trip stop keeps the Item and records an exclusion, so its Place does not put it back on that stop. Explicitly linking it again clears that exclusion. Organizer matching reuses exact normalized company cores, never arbitrary name containment or suffix letters inside a name. Multiple core matches are refused with candidate IDs for an explicit choice.
  • A Note keeps the person's own wording. An assistant's reading of a note is stored in a separate, attributed field beside it, and no tool lets an assistant rewrite what the person said.
  • A suggestion the person declined carries a standing rule with their reason and the one condition under which it may be raised again. The rule is enforced on the write, and the refusal names it. Read buying_list_suggestion_decisions before proposing rather than learning the rule by being refused.
  • The token proves who is calling; the stored grant decides what they may do. The grant is re-read on every single call, and the token's own scopes are never read for authorization.
  • Asking for access never changes live authority. buying_manage_connection files one exact request and returns a link for the person; only their click can approve it.
  • No assistant operation narrows, widens, or revokes a permission. The one authority change that is not the person's own click is Buying raising a never-narrowed connection to the current default baseline, which only ever adds what every connection now holds and is recorded in the ledger. Narrowing and revoking remain the person's alone, at https://assistwithbuying.com/connect, and a connection they narrowed is never widened back.
  • A connection lasts until the person removes it at https://assistwithbuying.com/connect. It has no end date and nothing to renew; a connection nobody has used for a long time is shown to the person as unused, and is never ended automatically. A connection that holds nothing — waiting for the person, removed, or over the limit — still lists buying_manage_connection, which says which of those it is and links to https://assistwithbuying.com/connect.
  • No approval this product can issue ever allows any of the following. Reveal a seller's contact details, or contact, message, or negotiate with anyone. Make an offer, spend money, or complete a purchase. Permanently delete, archive, or export your workspace. Publish your private research, or share it outside Buying. Reach another person's workspace, or any other Assist product.
  • A connected client may still apply its own per-tool prompt or block policy; Buying does not override client-side approval controls.

Setting up a conforming client

Buying publishes the requirements for a conforming AI client: remote MCP over Streamable HTTP, OAuth completed in your browser, and a tool list it refreshes rather than caches. We describe the common shapes of client rather than naming products, because naming one is a support promise, and a support promise needs that client's full lifecycle proved in its own environment. None has been re-proved since access grants shipped.

MCP server URL (Streamable HTTP)

https://assistwithbuying.com/mcp

A chat assistant with connectors

Standards-basedDesktop or web assistants that let you add a custom MCP connector

The simplest shape. If your assistant has a Connectors, Apps, or Custom integrations screen that accepts a remote MCP URL, that is the whole setup.

  1. 1In your assistant's settings, find Connectors (sometimes Apps, Integrations, or Custom connectors) and add a custom one.
  2. 2Paste the MCP server URL above. Leave any client ID and client secret fields blank — Buying does not use them.
  3. 3Choose Connect, sign in with your Assist With Buying account, and click Allow. That creates the ordinary 30-day Buying grant; there is no second permission screen.
  4. 4Ask it to call buying_get_brief. Buying rechecks the stored grant on every tool call.

Good to know

  • Some assistants expose the add-connector flow only on desktop or web, even when the phone app can use a connector once it exists.
  • Set the connector up from your assistant's settings, not by asking it in chat to connect itself.
  • Many assistants ask you to approve each tool call. You can usually pre-approve a connector you trust; your Buying grant still limits what it can reach.
Setting up a different kind of client

The same MCP server URL works in other apps. Paste it wherever the steps below say “the MCP server URL above.”

MCP server URL (Streamable HTTP)

https://assistwithbuying.com/mcp

A terminal or CLI agent

Standards-basedCommand-line coding and research agents

Most terminal agents add a remote MCP server with one command, then run a separate login step that opens your browser.

  1. 1Add the endpoint as a remote HTTP MCP server, using whatever the agent calls that (often an `mcp add` command).
  2. 2Run the agent's login or authenticate step for that server, complete browser sign-in, and click Allow. That is the Buying approval.

The shape most CLI agents use

<agent> mcp add assistwithbuying --url https://assistwithbuying.com/mcp
<agent> mcp login assistwithbuying

Good to know

  • Do not pass an Authorization header. Leaving it off is what triggers the OAuth flow.
  • Authentication is usually a separate step from adding the server.

A code editor with agent mode

Standards-basedEditors that read an MCP config file

Editors normally take a JSON config entry and then show a sign-in prompt next to the server once it is added.

  1. 1Add an HTTP MCP server entry like the snippet below to the editor's MCP config.
  2. 2Use the sign-in prompt the editor shows next to that server entry, approve in the browser, and click Allow.
  3. 3Switch the assistant into its agent mode; tool use is usually unavailable in plain chat modes.

MCP config entry

{
  "mcpServers": {
    "assistwithbuying": {
      "type": "http",
      "url": "https://assistwithbuying.com/mcp"
    }
  }
}

Good to know

  • Just the URL. Do not add a static Authorization header.
  • On a managed or company seat, an administrator may have to allow MCP servers first.

A client without built-in OAuth

Bridge requiredClients that speak MCP but cannot do the OAuth flow themselves

Some clients support MCP but not remote OAuth. A local bridge can complete the sign-in on their behalf.

  1. 1Configure the client to launch a community OAuth bridge pointed at the endpoint, as below.
  2. 2Run the client. The bridge opens a browser window for sign-in the first time.

Local OAuth bridge

{
  "mcpServers": {
    "assistwithbuying": {
      "command": "npx",
      "args": ["-y", "mcp-remote@0.1.29", "https://assistwithbuying.com/mcp"]
    }
  }
}

Good to know

  • A bridge is a third-party tool running on your machine and handling your tokens. Prefer a client with native OAuth where you have the choice.
  • Pin a version rather than letting it float.
  • Admin-hosted clients are usually configured centrally, not per person.

For agents and developers

If you are an AI assistant and your environment already exposes Assist With Buying MCP tools, use those tools instead of scraping the website. If you do not see AWB tools, tell the user to add the MCP server URL above in their AI app's connector settings.

  • Short agent guide: /llms.txt
  • Full agent guide: /llms-full.txt
  • No AWB API key fallback is available; use OAuth over MCP.
  • AWB never runs the AI, contacts sellers, spends money, or makes purchases.
  • Call buying_get_brief first, search before creating, and read a Mission before editing it.
  • When the person has already shaped a Mission, preserve their accepted criteria and person-authored notes. Add evidence, propose new criteria for review, and append a newer decision instead of overwriting history.
  • A Mission Queue handoff is the bounded next step, not blanket authority. Read its exact Mission scope and return the result only there.
  • Prefer buying_save_complete_result to save a Mission, products/options, dated observations, comparison, sources, decision, and Queue result in one approval.
  • For queued photos, call buying_get_capture_images when there are several file ids, or buying_get_capture_image for one file. Do not try web_fetch, bash, or browser fetch on the image URL first.
  • Assist With Buying does not look at photos for the person; their AI does. For a big set, scan numbered contact sheets with buying_get_photo_sheets, open the photos that matter at 1600px, then ask for a region where a label matters.
  • AI photo PUTs go only to https://assistwithbuying.com. Never allowlist or expose Backblaze. Preflight a set first, open up to 12 slots with one begin_batch, PUT at most 3 at once, and attach them all with one finish_batch. A photo already in a Queue ask is filed with link_existing, with no upload at all.
  • Observations, source checks, decisions, and events preserve history. Record blocked or gated sources honestly.