BigGo MCP Server
Servidor MCP de BigGo
Introducción
BigGo MCP Server utiliza API de BigGo, un sitio web de comparación de precios profesional.
Related MCP server: E-commerce MCP Server
Características
Admite transportes
stdioySSE
Descubrimiento de productos : busque productos en múltiples plataformas de comercio electrónico (Amazon, Aliexpress, Ebay, Taobao, Shopee, etc.)
Seguimiento del historial de precios : realice un seguimiento del historial de precios del producto proporcionando la URL del producto o términos relacionados.
Comparación de especificaciones [Deshabilitado en versiones >= v0.1.28] : Compare y encuentre productos según sus especificaciones, desde información básica hasta especificaciones técnicas más complejas.
Instalación
Prerrequisitos
Python >= 3.10
Certificación BigGo (
client_idyclient_secret) para búsqueda de especificaciones.
¿Cómo obtener la certificación BigGo?
Registre una cuenta BigGo si no tiene una.
Haga clic en el botón "Generar certificación"

Copiar el
client_idyclient_secretÚsalos en la configuración del servidor MCP (
BIGGO_MCP_SERVER_CLIENT_IDyBIGGO_MCP_SERVER_CLIENT_SECRET)
Configuración de instalación
{
"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"
}
}
}
}Para una versión específica, utilice
BigGo-MCP-Server@VERSION, por ejemplo:BigGo-MCP-Server@0.1.1
Variables de entorno
Variable | Descripción | Por defecto | Opciones |
| ID de cliente | Ninguno | Necesario para la búsqueda de especificaciones |
| Secreto del cliente | Ninguno | Necesario para la búsqueda de especificaciones |
| Región para búsqueda de productos | Dos | EE. UU., Taiwán, Japón, Hong Kong, Singapur, Malasia, India, Filipinas, Taiwán, Vietnam, Irlanda |
| Puerto para servidor SSE | 9876 | Cualquier número de puerto disponible |
| Tipo de transporte del servidor | estudio | estudio, sse |
URL SSE predeterminada: http://localhost:9876/sse
Herramientas disponibles
product_search: Búsqueda de productos con la API de búsqueda de BigGoprice_history_graph: Enlace que visualiza el historial de precios del productoprice_history_with_history_id: utiliza los identificadores del historial de los resultados de búsqueda de productosprice_history_with_url: rastrea el historial de precios mediante las URL de los productosspec_indexes: enumera los índices de Elasticsearch disponibles para las especificaciones del productospec_mapping: muestra el mapeo del índice de Elasticsearch con documentos de ejemplospec_search: Consulta las especificaciones del producto desde Elasticsearchget_current_region: Obtener la región actual
Preguntas frecuentes
¿Cómo activar el uso de la herramienta?
Para el descubrimiento de productos relacionados:
Look for Nike running shoesPara el seguimiento del historial de precios relacionado:
Show me the price history of this product: https://some-product-urlPara comparación de especificaciones relacionadas:
Find me phones with 16GB RAM and 1TB storagePlease show me diving watches that can withstand the most water pressureConstruir
Consulte build.md para obtener más detalles.
Licencia
Este proyecto está licenciado bajo la Licencia MIT. Consulte el archivo de LICENCIA para más detalles.
Available Tools
2 toolsprice_history_with_urlD
Product Price History With URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Product URL |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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_searchD
Product Search
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
price_history_with_url - First observed
product_search
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants to interact with a complete e-commerce application, providing authentication, product browsing, and shopping cart management through standardized MCP tools.-
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides real-time access to MongoDB product data, enabling sophisticated e-commerce queries with price range filters, category searching, and product recommendations through a conversational interface.-
- AlicenseBqualityFmaintenanceA Model Context Protocol server that aggregates and compares deals from multiple sources including Slickdeals, RapidAPI marketplace, and web scraping, enabling users to search, filter, and compare deals through a chat interface.67MIT
- FlicenseCqualityDmaintenanceA Model Context Protocol server for querying Turkish market prices, comparing products, and getting AI-powered shopping recommendations.106-