BigGo MCP 服务器利用专业价格比较网站 BigGo 的 API。
Related MCP server: E-commerce MCP Server
支持
stdio和SSE传输
产品发现：跨多个电子商务平台搜索产品（亚马逊、Aliexpress、Ebay、淘宝、Shopee……等）
价格历史跟踪：通过提供产品网址或相关条款来跟踪产品价格历史。
规格比较 [在版本 >= 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 | 没有任何 | 规范搜索必填 |
| 客户端机密 | 没有任何 | 规范搜索必填 |
| 产品搜索区域 | 台湾 | 美国、台湾、日本、香港、新加坡、马来西亚、印度、菲律宾、泰国、越南、印度尼西亚 |
| SSE 服务器端口 | 9876 | 任何可用的端口号 |
| 服务器传输类型 | 标准输入输出 | 标准输入输出，标准输出 |
默认 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.
