BigGo MCP サーバーは、専門的な価格比較 Web サイトである BigGo の API を利用します。
Related MCP server: E-commerce MCP Server
stdioおよびSSEトランスポートをサポート
製品の発見: 複数の電子商取引プラットフォーム (Amazon、Aliexpress、Ebay、Taobao、Shopee など) で製品を検索します。
価格履歴の追跡: 製品の URL または関連用語を入力して、製品の価格履歴を追跡します。
仕様比較 [バージョン >= v0.1.28 では無効] : 基本情報からより複雑な技術仕様まで、仕様に基づいて製品を比較して見つけます。
Python >= 3.10
仕様検索用の BigGo 証明書 ( client_idおよびclient_secret )。
BigGo アカウントをお持ちでない場合は登録してください。
「証明書を生成」ボタンをクリックします
client_idとclient_secretをコピーします
MCP サーバー構成で使用します ( BIGGO_MCP_SERVER_CLIENT_IDおよびBIGGO_MCP_SERVER_CLIENT_SECRET )
{
"mcpServers": {
"biggo-mcp-server": {
"command": "uvx",
"args": [ "BigGo-MCP-Server@latest"],
"env": {
"BIGGO_MCP_SERVER_CLIENT_ID": "CLIENT_ID",
"BIGGO_MCP_SERVER_CLIENT_SECRET": "CLIENT_SECRET",
"BIGGO_MCP_SERVER_REGION": "REGION"
}
}
}
}特定のバージョンについては、
BigGo-MCP-Server@VERSIONを使用します。例:BigGo-MCP-Server@0.1.1
変数 | 説明 | デフォルト | 選択肢 |
| クライアントID | なし | 仕様検索に必須 |
| クライアントシークレット | なし | 仕様検索に必須 |
| 商品検索の地域 | TW | 米国、台湾、日本、香港、シンガポール、マレーシア、インド、フィリピン、タイ、ベトナム、インドネシア |
| SSEサーバーのポート | 9876 | 利用可能なポート番号 |
| サーバートランスポートタイプ | 標準入出力 | 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ライセンスの下で提供されています。詳細はLICENSEファイルをご覧ください。
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.
