BigGo MCP 서버는 전문적인 가격 비교 웹사이트인 BigGo의 API를 활용합니다.
Related MCP server: E-commerce MCP Server
stdio및SSE전송을 지원합니다
제품 검색 : 다양한 전자상거래 플랫폼(Amazon, AliExpress, Ebay, Taobao, Shopee 등)에서 제품을 검색합니다.
가격 내역 추적 : 제품 URL이나 관련 용어를 제공하여 제품 가격 내역을 추적합니다.
사양 비교[v0.1.28 이상 버전에서 비활성화됨] : 기본 정보부터 보다 복잡한 기술 사양까지 사양을 기준으로 제품을 비교하고 찾아보세요.
파이썬 >= 3.10
사양 검색을 위한 BigGo 인증( client_id 및 client_secret )
BigGo 계정이 없으면 등록하세요 .
BigGo 인증 페이지 로 이동
"인증서 생성" 버튼을 클릭하세요
client_id 와 client_secret 복사하세요
MCP 서버 구성( BIGGO_MCP_SERVER_CLIENT_ID 및 BIGGO_MCP_SERVER_CLIENT_SECRET )에서 사용하세요.
지엑스피1
특정 버전의 경우
BigGo-MCP-Server@VERSION사용하세요. 예:BigGo-MCP-Server@0.1.1
변하기 쉬운 | 설명 | 기본 | 선택 |
| 클라이언트 ID | 없음 | 사양 검색에 필요합니다 |
| 클라이언트 비밀번호 | 없음 | 사양 검색에 필요합니다 |
| 제품 검색 지역 | 타이더블유 | 미국, 대만, 일본, 홍콩, 싱가포르, 말레이시아, 인도, 필리핀, 태국, 베트남, 아이다호 |
| SSE 서버용 포트 | 9876 | 사용 가능한 포트 번호 |
| 서버 전송 유형 | stdio | stdio, sse |
기본 SSE URL: http://localhost:9876/sse
product_search : BigGo 검색 API를 이용한 제품 검색
price_history_graph : 제품 가격 내역을 시각화하는 링크
price_history_with_history_id : 제품 검색 결과의 내역 ID를 사용합니다.
price_history_with_url : 제품 URL을 사용하여 가격 내역을 추적합니다.
spec_indexes : 제품 사양에 사용 가능한 Elasticsearch 인덱스를 나열합니다.
spec_mapping : 예시 문서와 함께 Elasticsearch 인덱스 매핑을 보여줍니다.
spec_search : Elasticsearch에서 제품 사양 쿼리
get_current_region : 현재 지역을 가져옵니다
제품 발견 관련:
Look for Nike running shoes가격 내역 추적 관련:
Show me the price history of this product: https://some-product-url사양 비교 관련:
Find me phones with 16GB RAM and 1TB storagePlease show me diving watches that can withstand the most water pressure자세한 내용은 build.md를 참조하세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 라이선스 파일을 참조하세요.
Product Price History With URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Product URL |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether the operation is read-only, safe, or destructive, nor does it describe any side effects, authentication needs, or rate limits. The agent gets zero behavioral insight.
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 short (5 words) but under-specified, not concise. It lacks structure and fails to provide essential information, making it inadequate for clear communication.
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?
Despite the tool's simplicity (1 parameter, output schema present), the description is severely incomplete. It does not explain the tool's purpose, behavior, or return value, leaving significant gaps for an agent to infer.
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 the baseline is 3. The description adds no additional meaning beyond the schema's 'Product URL' for the 'url' parameter. It does not specify format, constraints, or examples, but the schema already covers the parameter adequately.
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 'Product Price History With URL' is a noun phrase that merely echoes the tool name without specifying a verb or action. It does not clearly state what the tool does (e.g., retrieve, update, display), leaving the agent uncertain about its function.
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?
No guidance is provided on when to use this tool versus the sibling 'product_search'. There is no mention of contexts, alternatives, or when not to use it, making it hard for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Product Search
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., request limits, authentication needs, side effects). The description is minimal and adds no 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 words, which is not an appropriate size. It is under-specification rather than conciseness, as it fails to provide any useful information beyond the tool name.
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?
Despite having an output schema, the description gives no context about the tool's behavior, return values, or when to use it. It is completely inadequate for a tool with 1 parameter and a sibling tool.
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 coverage is 100% with a single parameter 'query' described as 'Search query' with examples. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
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 just 'Product Search', which is a tautology of the tool name. It does not specify a verb or resource, and does not distinguish it from the sibling tool 'price_history_with_url'.
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 no guidance on when to use this tool or when to avoid it. No alternatives or context are mentioned.
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.
price_history_with_urlproduct_searchScored across 2 tools
The two tools have clearly distinct purposes: one for product search and one for price history. There is no overlap or ambiguity.
Both tools use snake_case and are descriptive, but 'price_history_with_url' includes a preposition while 'product_search' is simpler, showing slight inconsistency in structure.
With only 2 tools, the server feels under-scoped for a product search domain, limiting its utility. Typically at least 3-5 tools are expected.
Missing essential tools like product detail, category listing, or filters. The surface only covers search and price history, leaving significant gaps.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cross-merchant product search with real price history, comparisons, and demand signals.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
