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 in Open agent center

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.

AWB exposes forty-five workflow-shaped MCP tools. Signing in and allowing the client is the approval; it grants every permission in the vocabulary for 30 days, 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 to reduce approval fatigue.

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 awb_get_buying_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 awb_get_capture_images when there are several file ids, or awb_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, awb_attach_photo returns a short-lived PUT capability on assistwithbuying.com. It never redirects to or exposes Backblaze. The normal fast appraisal save is awb_log_appraisal; the normal Mission save is awb_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 awb_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, for 30 days. There is 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, your AI access page 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.

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 for 30 days. Buying issues and receipts that authority separately from OAuth identity.
That baseline is the "ordinary-research" policy, version 3, decided 2026-09-01. 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.
Nothing is withheld pending a request: every permission in this vocabulary is granted by signing in. /settings/ai 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, its location data is stripped on the way in while its capture time is kept, 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 /settings/ai.
An assistant proposes and answers; the person decides. A suggestion is raised with awb_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.
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.
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 awb_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. awb_manage_connection files one exact request and returns a link for the person; only their click can approve it.
No assistant operation narrows, widens, revokes, or renews 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 /settings/ai, and a connection they narrowed is never widened back.
Each connection lasts 30 days from the sign-in that made it, and the person renews it themselves.
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.

1In your assistant's settings, find Connectors (sometimes Apps, Integrations, or Custom connectors) and add a custom one.
2Paste the MCP server URL above. Leave any client ID and client secret fields blank — Buying does not use them.
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.
4Ask it to call awb_get_buying_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.

1Add the endpoint as a remote HTTP MCP server, using whatever the agent calls that (often an `mcp add` command).
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.

1Add an HTTP MCP server entry like the snippet below to the editor's MCP config.
2Use the sign-in prompt the editor shows next to that server entry, approve in the browser, and click Allow.
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.

1Configure the client to launch a community OAuth bridge pointed at the endpoint, as below.
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 awb_get_buying_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 awb_save_complete_result to save a Mission, products/options, dated observations, comparison, sources, decision, and Queue result in one approval.
For queued photos, call awb_get_capture_images when there are several file ids, or awb_get_capture_image for one file. Do not try web_fetch, bash, or browser fetch on the image URL first.
AI photo PUTs go only to https://assistwithbuying.com. Never allowlist or expose Backblaze. Preflight a set first, then use at most 3 independent per-file begin/PUT/finish lanes and retry only the failed lanes.
Observations, source checks, decisions, and events preserve history. Record blocked or gated sources honestly.