Loading ToolBench
A Model Context Protocol (MCP) server that provides product search, price history tracking, and specification search capabilities.
The BigGo MCP Server has 7 tools with mixed definition quality. Only 2 tools are actively registered (product_search, price_history_with_url) per server_setup.py, while 5 are defined but commented out. Tool naming is verb-driven and reasonably clear (product_search, price_history_*), but descriptions vary in quality. Most tools lack parameter examples and some descriptions reference required prerequisites without clear guidance. Input schemas are present with types and descriptions, but output schemas are entirely undocumented. Critical issue: the 5 'spec_' tools are not registered in the server, making them unavailable at runtime despite being defined. Error handling is minimal, no recovery guidance, no actionable error messages. Overall definition quality falls in the 'fair' range with significant gaps in schema documentation and error handling.
Link That Visualizes Product Price History
Product Price History With History ID
Product Price History With URL
Product Search
Elasticsearch Indexes for Product Specification. It is REQUIRED to use this tool first before running any specification search.
Elasticsearch Mapping For Product Specification. Use this tool after you have the index, and need to know the mapping in order to query the index. Available indexes can be obtained by using the 'spec_indexes' tool.
5 of 7 tools are defined but NOT registered in server_setup.py (spec_indexes, spec_mapping, spec_search, price_history_graph, price_history_with_history_id are all commented out). These tools are unreachable at runtime despite having definitions.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, making it impossible to chain tools or extract specific data. This violates the documented output schema requirement.
spec_indexes tool has minimal description ('Elasticsearch Indexes for Product Specification') and lacks explanation of when/why to use it or what it returns. Description is too brief to guide LLM selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Product Specification Search. Index mapping must be aquired before using this tool. Use 'spec_mapping' tool to get the mapping of the index.
spec_search tool has complex multi-step requirements (use spec_indexes first, then spec_mapping) documented in description but scattered across parameter docs rather than clearly sequenced. Dependency hints are present but disorganized.
No error handling or recovery guidance in any tool. No documentation of what errors are retryable, what are user-fixable, or what are fatal. No actionable error messages shown in code.
price_history_with_history_id and price_history_graph both accept 'history_id' and serve similar purposes (both operate on product history). Naming distinction is unclear, one generates a visualization link, the other returns history data. Tool composition is poor.
spec_search expects 'elasticsearch_query' as either 'string or object', a union type that is ambiguous and forces the LLM to guess format. Should accept only one type (likely object) with clear schema or require pre-serialized JSON string.
Tool descriptions include examples with specific 'history_id' values that LLMs may reuse literally (e.g. 'tw_pmall_rakuten-nwdsl_6MONJRBOO'). This violates guidance to avoid example values in descriptions, they should be replaced with format constraints.
No pagination parameters (page, limit, offset, cursor) on product_search tool. If search results can be large, lack of pagination will blow context window and violate paginated-result pattern.
spec_mapping and spec_search have prerequisites documented in descriptions but no formal way to express them as multi-step requirements. If spec_mapping fails or is skipped, spec_search will fail with unclear error.