MCP 서버로, Claude(또는 모든 MCP 클라이언트)가 공식 Browse API를 통해 eBay 목록을 검색할 수 있게 해줍니다.
*"100달러 미만 기계식 키보드, 즉시 구매만, 무료 배송으로 찾아줘"*라고 물어보면 어시스턴트가 실제로 검색해 볼 수 있습니다.
eBay results for "mechanical keyboard" — showing 3 of about 41,208 matches
1. Keychron K8 Pro Wireless Mechanical Keyboard - Brown Switches — $79.99
total $79.99 · free shipping · New · was $99.00 (19% off)
seller keeb_supply · 99.6% positive (8421 ratings) · top rated, ships from US
Item v1|335894120043|0 · https://www.ebay.com/itm/335894120043
2. Ducky One 3 TKL Mechanical Keyboard RGB Hot-Swappable — $84.50
total $92.45 · $7.95 shipping · New
seller pc_parts_direct · 98.9% positive (3310 ratings) · accepts offers
Item v1|326770118254|0 · https://www.ebay.com/itm/326770118254모든 도구는 읽기 전용입니다. 이 서버는 목록을 검색하고 읽을 수만 있습니다. 입찰, 장바구니 추가, 주문, 결제는 할 수 없습니다. 구매를 원하면 목록 링크를 제공하고, 직접 결제를 진행해야 합니다.
공식 eBay Browse API를 기반으로 구축되었습니다. 스크래핑, 브라우저 자동화, 쿠키 재사용이 없습니다. 레이아웃 변경으로 깨지지 않으며, eBay 이용약관을 위반하지도 않습니다.
Related MCP server: ebay-browse-mcp
도구 | 용도 |
| 가격, 상태, 구매 방식, 배송, 위치 필터를 지원하는 키워드 검색. |
| 단일 목록의 전체 기록: 품목 세부 정보, 판매자, 반품, 경매 종료 시간. |
| 원래 가격에서 최소 N% 이상 할인된 목록만, 가장 저렴한 순서로. |
| 현재 구성을 표시하고 실제 테스트 호출을 수행합니다. 문제가 있을 때 가장 먼저 실행하세요. |
search_ebay에 대해 알아두면 좋은 두 가지가 있습니다. eBay에는 있지만 고정 가격 카탈로그에는 없는 기능입니다:
buying_option은 auction, buy_it_now, accepts_offers로 필터링합니다.
sort: "ending_soonest" — buying_option: "auction"과 함께 사용하면 곧 마감될 경매를 찾을 수 있습니다.
developer.ebay.com/my/keys에 로그인합니다.
애플리케이션을 만들고 Production 키 세트를 엽니다.
**App ID(Client ID)**와 **Cert ID(Client Secret)**를 복사합니다.
이것으로 끝입니다. 이 서버는 OAuth 클라이언트 자격 증명 흐름을 사용하므로 사용자 토큰, 리디렉션 URI 또는 "RuName"이 필요하지 않습니다.
새 개발자 계정은 키 페이지가 열리기 전에 eBay의 인증을 통과해야 할 수 있습니다. 일반적으로 영업일 기준 약 하루가 걸립니다.
git clone https://github.com/Kirat5690/shopping-mcp.gitcd shopping-mcp && npm install && npm run buildclaude mcp add shopping --env EBAY_CLIENT_ID=your-app-id --env EBAY_CLIENT_SECRET=your-cert-id -- node /absolute/path/to/shopping-mcp/dist/index.jsclaude_desktop_config.json을 편집합니다:
macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"shopping": {
"command": "node",
"args": ["C:\\path\\to\\shopping-mcp\\dist\\index.js"],
"env": {
"EBAY_CLIENT_ID": "your-app-id",
"EBAY_CLIENT_SECRET": "your-cert-id",
"EBAY_MARKETPLACE_ID": "EBAY_US"
}
}
}
}클라이언트를 다시 시작한 다음, 자격 증명이 작동하는지 확인하기 위해 check_ebay_connection을 실행하도록 요청하세요.
변수 | 필수 | 기본값 | 참고 |
| 예 | — | 프로덕션 키 세트의 App ID. |
| 예 | — | 동일한 키 세트의 Cert ID. |
| 아니요 |
|
|
| 아니요 |
| 샌드박스 키를 사용하려면 |
| 아니요 | — | 제휴 태그가 포함된 목록 링크를 반환. |
| 아니요 | — | 배송비 정확도를 높임. |
| 아니요 | — | ISO 국가 코드, 예: |
| 아니요 |
| 요청별 타임아웃. |
최종 가격이 정렬 기준입니다. 가격 정렬은 상품 가격에 배송비를 더한 금액을 사용하므로, 배송비가 비싼 저렴한 상품이 기술적인 이유로 앞서지 않습니다. eBay 자체 가격 정렬은 항상 이렇게 하지 않습니다.
일부 목록에는 총액이 없습니다. eBay가 배송비를 결제 시 계산되는 것으로 표시하는 경우, 배송 주소를 알기 전까지는 최종 가격이 없으며, 목록은 추측하지 않고 그렇게 표시합니다.
통화 변환 없음. 가격은 eBay가 반환하는 그대로 마켓플레이스 자체 통화로 표시됩니다.
목록은 카탈로그 항목이 아닌 개별 판매입니다. 거의 동일한 제목의 두 결과도 상태, 번들 구성, 지역이 다를 수 있습니다. 동일한 상품으로 간주하기 전에 확인할 가치가 있습니다.
find_deals는 광고된 할인만 볼 수 있습니다. eBay의 취소선 "was" 가격을 기준으로 필터링하므로, 할인을 표시하지 않은 진짜 저렴한 목록은 나타나지 않습니다.
npm test테스트 스위트는 eBay 자격 증명 없이 실행됩니다. 금액 및 최종 가격 로직, 출력 형식, 그리고 stdio를 통해 서버를 부팅하고 도구 등록, 스키마 검증, 자격 증명 미설정 경로를 테스트하는 종단 간 MCP 프로토콜 테스트를 포함합니다.
npm run watch # recompile on change
npm run typecheck # types only, no emit구조:
src/
index.ts server entry point and stdio wiring
tools.ts MCP tool definitions
ebay.ts Browse API client and OAuth token cache
config.ts environment parsing and marketplace table
money.ts price parsing, landed totals, ranking
format.ts human-readable output
http.ts fetch with timeout and retry이전 버전에서는 Product Advertising API를 통해 Amazon도 지원했습니다. 이 기능은 v0.2.0에서 제거되었습니다. PA-API는 승인된 Amazon Associates 계정이 필요하며, 자격을 갖춘 판매가 없으면 Amazon이 액세스를 취소합니다. 대부분의 사람이 서버를 실행하기에는 너무 높은 장벽입니다.
Amazon 클라이언트와 AWS SigV4 서명은 승인된 계정이 있고 복원을 원하는 경우 태그 v0.1.0-amazon의 git 기록에 보존되어 있습니다.
MIT — LICENSE 참조.
eBay와 제휴, 보증, 후원 관계가 아닙니다. eBay API 사용은 eBay API License Agreement의 적용을 받습니다.
Report how eBay is configured and make one live test call to confirm the credentials work. Run this first whenever a search fails or returns nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds important behavioral context: 'make one live test call to confirm the credentials work.' This clarifies that despite being read-only, the tool performs an actual network call to the eBay API for testing, which is beyond the basic read-only label. It also implies credential validation, adding value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the purpose front-loaded and the usage guidance immediately after. No wasted words, and it covers purpose, behavior, and usage in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully covers what an agent needs to know: what it does (reports config, tests credentials), when to use it (after a failed search), and the side-effect (live call). It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. The description does not need to explain parameters since none exist. It adequately explains the tool's behavior without needing parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report how eBay is configured and make one live test call to confirm the credentials work.' This is a specific action (report/test) on a specific resource (eBay configuration), and it distinguishes itself from sibling tools like search_ebay and get_listing_details by focusing on connection/credential verification rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Run this first whenever a search fails or returns nothing.' This is a clear trigger condition that indicates precedence over sibling tools. However, it does not explicitly mention when not to use it or list alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search eBay for listings currently discounted off their original price. Returns only items whose advertised saving meets the threshold, cheapest landed price first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many listings to scan before filtering (default 25). Raise this if nothing comes back. | |
| query | Yes | Product or category to hunt for deals in, e.g. 'mechanical keyboard'. | |
| condition | No | Item condition (default new). | |
| max_price | No | Ignore listings above this price. | |
| min_savings_percent | No | Minimum advertised discount off the original price (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds behavioral details: it filters by advertised savings threshold and sorts by landed price, which goes beyond the annotations. It does not describe pagination or response format, but with the annotations covering the basic side effects, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the primary action, the second adds the filtering and ordering behavior. There is zero fluff, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and helpful annotations, the description is sufficiently complete. It explains the core filtering and ordering behavior, which is the key differentiator. While it doesn't describe return fields or pagination, the simplicity of the tool and schema richness compensate. It could add more detail on the response structure, but it is not critically missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, each with its own description. The tool description does not add additional parameter-level clarification beyond what the schema provides, so the baseline of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'eBay listings' with a specific scope: discounted items meeting a savings threshold. It distinguishes itself from siblings like search_ebay by focusing on advertised discounts and cheapest landed price first, making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when seeking discounted items) via its focus on savings thresholds and ordering, but it does not explicitly mention alternatives or exclusions. The existence of sibling tools like search_ebay suggests a differentiation, but no direct comparison is made, so it's clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record for one eBay listing: price, condition, availability, seller rating, item specifics, return policy, and auction end time. Accepts either the v1|...|0 item id or the legacy numeric id from an eBay URL.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | eBay item id — either 'v1|326012345678|0' or the numeric id from the listing URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe read operation with external side effects. The description adds the specific data returned (price, condition, etc.) but doesn't discuss error behavior, latency, or rate limits. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose with a clear list of fields, the second explains the parameter format. No fluff, front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with full schema coverage and safety annotations, the description is complete. It covers what data is returned, which is sufficient. No output schema exists, but the listed fields serve as a partial return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description already explains the item_id formats fully (100% coverage). The tool description reinforces that it accepts either format but adds no new meaning beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full details for one eBay listing, enumerating specific data fields (price, condition, availability, seller rating, etc.). It distinguishes from siblings (search_ebay, find_deals) by focusing on a single item rather than searching or finding deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need full details for a specific listing, as opposed to search or deals tools. It does not explicitly say when NOT to use it or name alternatives, but the context is clear given the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search eBay for listings matching a keyword query, with optional price, condition, buying-format, and shipping filters. Returns title, price, shipping, landed total, seller rating, and a link for each listing. Read-only: this never bids, adds to a cart, or places an order.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering (default relevance). 'ending_soonest' is most useful combined with buying_option='auction' to find auctions about to close. | |
| limit | No | How many listings to return (default 10). | |
| query | Yes | What to search for, e.g. 'Sony WH-1000XM5 headphones'. | |
| condition | No | Item condition (default any). | |
| max_price | No | Maximum price, in the marketplace's own currency. | |
| min_price | No | Minimum price, in the marketplace's own currency. | |
| buying_option | No | Buying format (default any). Use 'auction' for bidding, 'buy_it_now' for fixed price. | |
| seller_location | No | Two-letter country code to restrict where items ship from, e.g. 'US' or 'CA'. | |
| free_shipping_only | No | Only return listings that ship free. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it explicitly states 'Read-only: this never bids, adds to a cart, or places an order,' which is more specific than the generic readOnlyHint annotation. It also discloses the output fields (title, price, shipping, etc.), which is a behavioral trait not covered by annotations or schema. No contradiction; this enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action and filters, the second clarifies read-only behavior. It is front-loaded with the key information and contains zero fluff. Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, but the schema fully documents them, and the description explains what the tool returns and its read-only nature. It lacks mention of pagination or how to interpret structured results, but given the schema coverage and the read-only clarification, the description is complete enough for an agent to invoke correctly. The openWorldHint is not elaborated, but that's acceptable since it's a hint rather than a requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has detailed descriptions. The tool description itself only gives a high-level overview ('optional price, condition, buying-format, and shipping filters'), adding marginal value beyond the schema. However, it does connect the filters to the search intent, which aligns with the baseline of 3. No specific parameter semantics beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and action-oriented: 'Search eBay for listings matching a keyword query' with optional filters and a clear list of returned fields (title, price, shipping, landed total, seller rating, link). It distinguishes from siblings by focusing on search behavior, and the read-only note further clarifies scope. The verb-resource pair is unambiguous and distinct from check_ebay_connection, get_listing_details, and find_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context (search for listings, optional filters) but does not explicitly tell when to use this tool over siblings like get_listing_details or find_deals. It also includes a helpful tip in the schema about using 'ending_soonest' with auctions, but that guidance is embedded in the schema description, not the main description. No clear when-not or alternative tool mention, so it is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0check_ebay_connectionfind_dealsget_listing_detailssearch_ebayScored across 4 tools
Most tools are clearly distinct: check_ebay_connection, search_ebay, get_listing_details each target different actions. search_ebay and find_deals have some overlap, but find_deals is specifically for discounted listings with a savings threshold, so the boundary is clear enough.
Tool names follow a readable snake_case verb_noun pattern: check_ebay_connection, search_ebay, get_listing_details, find_deals. The only minor inconsistency is using both 'search' and 'find' for similar retrieval actions, but the pattern remains predictable.
Four tools is on the small side but appropriate for a focused eBay look-up server. The surface is tight and avoids unnecessary endpoints, though it is slightly minimal for a general 'shopping' MCP.
The tool set covers the core read-only shopping workflow: connectivity verification, keyword search, deal discovery, and listing details. It intentionally omits purchase actions, and while category browsing or seller info could be added, the current surface is not severely incomplete.
Read-only product discovery, merchant trust, shipping and returns for SVV-Schatzoekers.
Live search across 250,000+ verified UK and Canada retail deals. Read-only, no auth required.
Search and browse global classifieds across 80 markets. No auth required for read-only access.
eBay MCP — Browse + Taxonomy APIs via client_credentials OAuth
