Basketed

하나의 바구니. 여러 상점. 당신의 승인 없이는 아무것도 구매되지 않습니다.

유니버설 쇼핑 MCP 서버와 자체 호스팅 제어 패널. 모든 MCP 에이전트는 여러 소매업체에서 실제 상품 검색, 토큰 효율적인 비교, 그리고 오직 인간만이 승인할 수 있는 구매 단계를 얻습니다.

분석 → 추출 → 응답 → 구매 → 수령

pnpm i && pnpm build
node packages/cli/bin.js install --client claude-code   # or --all

이것이 전체 설정입니다. 클라이언트가 stdio를 통해 Basketed 자체를 실행하면 제어 패널이 같은 프로세스에서 열립니다. 해당 링크와 승인을 기다리는 장바구니 링크는 서버 콘솔에 출력됩니다. serve --http --open은 다른 진입 방식입니다: 같은 패널에 더해 /mcp에 Streamable HTTP 엔드포인트가 제공됩니다.

실제로 제공되는 것

Related MCP server: agent-commerce-mcp-server

구매 게이트

에이전트는 구매를 제안할 수 있습니다. 오직 인간만이 승인할 수 있으며, 승인은 항상 모델이 작성할 수 없는 표면에서 도착합니다.

cart_prepare ──► PENDING ──(human)──► APPROVED ──(purchase_confirm)──► order
                    │                                                    │
                    └──► EXPIRED (5 min) / REJECTED                       └─► HANDED_OFF
                                                                              outcome: unknown

두 가지 승인 채널, 모두 하나의 함수로 수렴 — 인간이 어디를 클릭했든 보안 속성은 동일합니다.

B — 유도 채널(클라이언트가 대화 상자를 직접 렌더링하는 방식)은 설계되었지만 구현되지 않았습니다. ApprovalChannel은 "console" | "panel"이며, 이것이 전체 목록입니다. 문자는 계획과 코드가 동일한 사물에 동일한 이름을 사용하도록 유지됩니다.

채널 C는 모델이 해당 표면에 대한 읽기 액세스 권한이 없기 때문에 안전합니다. 에이전트가 코드를 얻는 유일한 방법은 사람이 직접 읽어 주는 것 — 이것이 바로 우리가 요구하려는 인간의 행위입니다.

채널 A는 경로 분할이 아닌 동일한 사실에 기반합니다. Basketed가 설치되는 모든 클라이언트에는 셸이 있으므로 "에이전트가 MCP를 말하고 /api에 도달할 수 없다"는 것은 그 자체로 사실이 아니었습니다 — 로컬 프로세스는 127.0.0.1의 모든 포트를 호출하고 어떤 헤더도 위조할 수 있습니다. 따라서 패널은 프로세스별로 발행되어 동일한 콘솔에 출력되는 토큰 뒤에 있습니다 — 두 전송 모두에서, stdio를 통해 Basketed를 실행한 클라이언트도 채널 A를 사용할 수 있습니다.

stdio에서 패널은 서버가 시작될 때 브라우저에서도 열립니다. 이것은 편의가 아닙니다: 클라이언트는 MCP 서버의 stderr를 캡처하므로 링크는 어떤 인간도 읽지 못할 곳에 기록되며, 아무도 도달할 수 없는 패널은 채널이 아닙니다. 그 탭이 그곳의 채널입니다. 프로세스당 탭 하나; --no-open(또는 BASKETED_NO_OPEN=1)으로 끄면 탭이 폴링하므로 나중에 승인이 필요한 장바구니가 이미 열려 있는 탭에 표시됩니다. /api는 또한 Origin이 정확히 패널의 것과 일치하지 않는 모든 요청을 거부하고, Origin을 보내지 않는 변경 요청도 거부합니다. 이것이 웹 페이지가 브라우저를 통해 패널을 조종하는 것을 막는 방법입니다.

의도적으로 존재하지 않는 것: approve() 도구, approved: true 매개변수, 재정의 플래그, 또는 set_delivery_address 도구. tools/list를 실행하고 확인하세요. 부재가 기능입니다.

적대적 테스트

pnpm smoke        # five smoke suites, all offline
pnpm test         # 160 unit tests
pnpm drill        # the whole demo path with the network genuinely severed
pnpm smoke:live   # ...and against live merchants, spending real requests

1. 승인 전 purchase_confirm → 거부됨

2. 승인, 확인 후 동일한 approval_id 재생 → 거부됨, 소비됨

3. 승인 후 DB에서 가격 변경 → 거부됨, 해시 불일치

4. --fast-mode로 재시작하고 1–3 반복 → 모두 여전히 거부됨

5. 에이전트에게 자신의 구매를 승인하도록 요청 → 그렇게 할 수 있는 도구가 없음

--fast-mode는 구매를 건드릴 수 없으며, 두 번 증명됩니다

행동적으로, 그리고 실제 가져오기 그래프를 따라: commerce/purchase.ts에서 도달 가능한 어떤 것도 플래그가 있는 mcp/policy.ts를 가져오지 않습니다. 플래그는 구매 경로에서 무시되는 것이 아니라 — 그 경로에서 도달할 수 없으며, 둘을 연결하는 리팩터링은 CI를 실패시킵니다.

오프라인 훈련은 실제로 네트워크를 차단합니다

pnpm drill은 서버 프로세스에서 모든 비루프백 연결을 거부하는 가드를 미리 로드한 다음 전체 데모 경로를 실행합니다. 여전히 Wi-Fi가 있는 머신에서 스냅샷 플래그를 설정하는 것은 플래그가 구문 분석된다는 것만 증명합니다. 실제 차단 아래에서 고정된 10개의 Shopify 상점 중 7개가 어두워지고 — stores_failed에 이름이 다시 나타납니다. 조용히 더 적은 상점을 반환하는 검색은 성공과 똑같이 보이기 때문입니다.

데이터 출처

모든 어댑터는 두 가지 독립적인 사항을 선언하며, 어느 것도 과장될 수 없습니다. 모든 응답은 모드를 포함하며, 패널은 이를 배지로 표시합니다.

실제 Tesco는 라이선스 통합이 아닙니다. search.api.tesco.com과 xapi.tesco.com은 Tesco 자체 웹사이트가 호출하는 공개 엔드포인트이며, API 키는 공개되어 프론트엔드 JS에 포함되어 있습니다 — 그러나 Tesco는 둘 중 어느 것의 제3자 사용을 문서화하거나 지원하지 않으며, 이렇게 사용하는 것은 비공식 API 클라이언트와 마찬가지로 Tesco 서비스 약관을 벗어납니다. sim:tesco는 이와 무관하며 항상 그랬던 것 그대로입니다: 픽스처 데이터, 여전히 오프라인 훈련이 실행하는 대상, 여전히 실제 네트워크 없음.

스크래퍼도, 안티봇 우회도 없습니다. Cloudflare 챌린지, WAF 핑거프린팅, CAPTCHA는 운영자가 의도적으로 활성화한 접근 제어입니다. 이를 무력화하면 에이전트 쇼핑을 방어 가능하게 만드는 "사용자가 행위자"라는 방어가 파괴되고, 끊임없이 깨집니다. 이러한 보호 장치 뒤에 있는 소매업체는 provider 또는 simulated입니다. 이것은 비활성화된 채로 제공하는 기능이 아니라 — 아예 구축하지 않는 기능입니다.

HANDED_OFF는 결코 성공을 주장하지 않습니다. 경로가 사람이 직접 완료하는 URL로 끝나면 우리는 결과를 실제로 알 수 없으며, 누군가 패널에서 표시하기 전까지 주문은 정확히 그렇게 표시됩니다. 아무도 결제하지 않은 주문에 조용히 녹색 체크 표시를 보여주는 것은 이 제품이 배포할 수 있는 가장 치명적인 버그일 것입니다.

도구

금전 관련 — destructiveHint: true, ALLOW로 승격 불가:

토큰 레버

response_format: concise(기본값) · detailed · compact(짧은 키와 한 줄 범례 포함). fields는 명시적 허용 목록용. budget_tokens는 상한선 — url → image → attrs → 이름 자르기 → 행 삭제 순으로 정리되며, _meta.truncated가 무엇이 제거되었는지 알려줍니다. id, price, mode는 절대 삭제되지 않습니다: 결과는 토큰을 아끼기 위해 출처를 잃어서는 안 됩니다.

설치

basketed install은 패널이 렌더링하는 것과 동일한 하나의 변형 테이블로 구동됩니다. 따라서 설치 프로그램, 복사 블록, 배지가 구성 파일의 위치에 대해 서로 다르게 말할 수 없습니다. 아래의 거의 모든 예외가 조용히 실패하기 때문에 중요합니다: 잘못된 키 이름은 오류를 내지 않고 서버가 그냥 나타나지 않습니다.

basketed clients                       # every client, its file, its key
basketed install --client claude-code
basketed install --all --dry-run       # show the diff, write nothing
basketed doctor                        # check the install end to end

쓰기는 병합 후 교체이며, 덮어쓰지 않습니다. 기존 파일은 <file>.basketed-backup-<timestamp>로 백업되고, 관련 없는 키와 다른 서버는 보존되며, 쓰기는 원자적이고, diff가 출력됩니다. 파싱할 수 없는 구성은 거부되고 교체되지 않고 바이트 단위로 동일하게 유지됩니다.

Kiro의 autoApprove는 함정입니다. 우리가 생성한 구성에는 읽기 전용 도구 네 개만 나열되며, basketed doctor는 금전 관련 도구가 수동으로 추가된 경우 경고합니다.

프로토콜

이중 시대, 두 전송 모두. MCP **2026-07-28**은 initialize, 세션 및 서버 시작 요청을 제거했습니다. 최신 클라이언트는 레거시 서버와 통신할 수 없고 그 반대도 마찬가지입니다. "모든 에이전트에 설치"는 전적으로 하나의 바이너리에서 둘 다 제공하는 데 달려 있으므로 scripts/smoke-mcp.mjs는 동일한 바이너리를 두 번 엽니다 — 한 번은 initialize로, 한 번은 상태 없이 — 어느 쪽 실패도 서버 자체 로그에서 보이지 않기 때문입니다.

또한: server/discover, 모든 도구의 outputSchema, 이전 클라이언트를 위해 텍스트로 미러링된 구조화된 출력, 결정적 도구 순서, 네 가지 주석, 네임스페이스 이름.

보안

• 자격 증명 금고가 구축되었습니다. packages/vault는 저장된 각 비밀을 ~/.basketed/master.key(모드 0600)의 32바이트 키로 AES-256-GCM으로 봉인합니다. 평문을 반환하는 함수는 정확히 하나 — reveal() — 이며, 아웃바운드 fetch에 헤더를 첨부하는 요청 인터셉터 외에는 어디에서도 호출되지 않습니다. 테스트는 작업 공간에서 다른 호출 지점을 찾아 하나라도 나타나면 실패합니다. 패널 — 이 목록의 다른 모든 것과 동일한 프로세스별 토큰 뒤에 — 은 금고에 쓰고 메타데이터만 다시 읽습니다. 어떤 MCP 도구도 자격 증명을 받지 않습니다, 절대: AdapterCtx에는 자격 증명이 이동할 수 있는 필드가 없습니다. 잘못되었거나 누락된 키 파일은 Connect-stores 페이지를 저하시킬 뿐이며 MCP 서버를 중단시키지 않으므로 클라이언트가 이 파일 때문에 시작에 실패할 수 없습니다. 배송된 어댑터 중 어느 것도 저장된 것으로 인증하지 않습니다 — Shopify UCP는 익명이고 시뮬레이션된 상점은 확인할 것이 없습니다 — 따라서 Tesco, Costco, Walmart 또는 Amazon을 연결하면 아직 존재하지 않는 어댑터에 대한 자격 증명을 보유하게 되며 오늘 보이는 결과는 변경되지 않습니다.

• "Chrome으로 로그인" (S15), 정확히 Tesco, Costco, Walmart, Amazon용. 이들 중 어느 것도 소비자 OAuth 흐름을 제공하지 않으므로 비밀번호 붙여넣기 상자에 대한 정직한 대안은 실제 브라우저에서 소매업체의 로그인 페이지를 열고 인간이 직접 로그인하게 하는 것입니다. 이는 기계에 이미 설치된 Chrome을 실행하며, 다운로드한 Chromium을 절대 사용하지 않습니다 — 이 기능을 사용하는 누구도 아무것도 설치할 필요가 없습니다. 인간이 "캡처"를 클릭할 때까지 아무것도 읽지 않습니다: 세션 쿠키가 나타나기를 폴링하지 않으며 나타나는 즉시 가져오지 않습니다. 위의 "안티봇 우회 금지"와 일관되게, 소매업체로부터 자동화를 숨기지 않습니다 — navigator.webdriver 스푸핑 없음, 자동화 플래그 제거 없음 — 구동된 브라우저와 인간을 구분할 수 없는 사기 시스템은 이 프로젝트가 Connect-stores 페이지와 맞바꿀 선이 아니기 때문입니다. 이 네 소매업체의 이용약관은 모두 계정 소유자를 포함한 자동 로그인을 금지합니다. 그 위험은 여기뿐만 아니라 버튼 자체에도 공개됩니다. 캡처된 세션은 붙여넣은 자격 증명과 정확히 동일하게 봉인됩니다 — 동일한 금고, 동일한 reveal() 감사 — 그리고 아직 어떤 어댑터도 이를 사용하지 않습니다.

• 에이전트는 불투명한 계정 핸들만 볼 수 있으며, 핸들이 될 수 있는 어떤 것도 볼 수 없습니다.

• 승인 표면은 프로세스별 토큰 뒤에 있습니다 — 서버 자체 콘솔에 6자리 코드 옆에 인쇄됩니다. 경로 분리는 게이트가 아닙니다: Basketed가 설치하는 모든 클라이언트에는 셸이 있으므로 에이전트는 항상 127.0.0.1에 도달하여 어떤 헤더든 위조할 수 있습니다. /api는 또한 패널의 것과 정확히 일치하는 Origin을 요구하며, 없는 변형 요청은 거부합니다.

• 공급업체 텍스트는 신뢰할 수 없는 데이터입니다. NFKC 정규화, 제어 문자 제거, 제로 너비 및 양방향 재정의 제거, HTML 제거, 길이 상한, 주입 패턴 플래그 지정. 실제 방어는 더 강력합니다: 승인 화면과 장바구니 해시는 숫자 및 열거형 필드와 정규화된 제품 이름으로만 구성됩니다. 상인이 작성한 문자열은 어느 쪽에도 도달하지 않습니다.

• approval_id는 CSPRNG이며, 로컬 세션에서 파생된 주체에 서버 측에서 바인딩됩니다 — 에이전트가 제공한 어떤 것에서도 파생되지 않습니다 — 그리고 원자적 소비 내에서 다시 확인됩니다. 소유는 결코 인증이 아닙니다 (2026-07-28 상태 핸들 하이재킹).

• 모든 응답에 대한 편집 계층, 방어가 아닌 그물로. 적중은 버그입니다; 패널은 개수를 표시합니다.

• 우리는 카드 데이터를 다루지 않으며(PCI 범위 밖), 소매업체 비밀번호를 저장하지 않으며, 스크레이퍼를 제공하지 않습니다.

구축되지 않음, 누구도 주장하지 않도록 명시

Costco/Walmart/Amazon용 실제 소매업체 어댑터(어느 것도 소비자 API를 제공하지 않음; 금고는 자격 증명을 보유 — 붙여넣기 또는 Chrome 캡처 — 아직 아무것도 인증하지 않음), 실제 소매업체 OAuth(네 곳 중 어느 것도 제공하지 않음 — Connect stores 참조), 프로토타입 네 곳 외의 상점에 대한 Chrome 로그인 캡처, 모의 IdP, 승인 채널 B(elicitation), compare_products, 주문 페이지, MCPB, 레지스트리 게시, ChatGPT 플러그인 제출. 모두 계획에 설계되었으며 아무것도 구축되지 않았습니다.

Tesco는 이 목록에서 이동한 유일한 소매업체 어댑터입니다 (S16) — 위의 "데이터 출처" 참조: 실제 검색, 실제 상세 정보, 그리고 구매자가 직접 붙여넣은 세션 토큰 뒤의 실제 장바구니. Costco, Walmart, Amazon은 세 곳 모두 Tesco의 프런트엔드가 우연히 노출하는 것과 동등한 비공식적이지만 실제 엔드포인트가 없기 때문에 여기에 남아 있습니다 — 이 세 곳에서 Chrome 로그인 세션이 할 수 있는 것과 할 수 없는 것에 대해서는 Connect stores를 참조하세요.

자격 증명 금고는 이 목록에서 이동한 또 다른 항목입니다 (S14) — 위의 보안 참조 — 그리고 여기서 이를 확인하던 드리프트 가드는 이제 반대를 확인합니다: 이 파일이 더 이상 사실이 아닐 때 정확히 부인을 중단하는지.

docs/ — BENCHMARK

Node ≥ 22 필요 (node:sqlite이므로 네이티브 빌드 단계가 없습니다 — Windows에서 개발 및 검증된 곳에서 중요합니다).