Loading ToolBench
MCP server providing e-commerce platform data APIs for querying enterprise online store information, product profiles, and fuzzy search capabilities across domestic and foreign e-commerce platforms
This server has significant structural issues. All four tools are explicitly defined with descriptions and basic parameters, but the implementation lacks critical production-grade patterns. Tool naming does not consistently follow verb_noun conventions (all tools are named 'estore_bigdata_*' which reads as a prefix rather than action-oriented names). Descriptions are verbose (200-300+ chars) but lack the clarity and structure expected for LLM tool selection, they read more like marketing copy than actionable tool guidance. Parameter schemas are present but incomplete: many parameters lack proper enum constraints (e.g., keywordType should be an enum but is just 'string'), and output schemas are documented in docstrings but not exposed as structured return types. Error handling is minimal, call_api() returns generic strings like '查询失败' (query failed) with no recovery guidance. The server exposes no tool annotations, no per-request metadata handling, and relies on STDIO transport, which cannot be used by hosted clients.
该接口的功能是根据企业的关键识别信息（如企业名称、注册号等）查询其在电商平台上的店铺及商品概况，包括品牌信息、评分、创建时间等详细信息。此接口可用于市场调研、竞争分析或投资评估等场景，帮助企业或投资者了解特定企业的电商运营状况及市场表现，例如在选择合作品牌或评估市场机会时，获取目标企业的电商表现数据等。
该接口的功能是通过输入特定的企业标识信息（如企业名称、注册号等）来查询与该企业相关联的网店信息，并返回网店的详细信息和业务数据概览。这个接口可以用于电商平台的运营管理、数据分析和竞争对手研究等场景。例如，市场调研人员可以使用该接口获取竞争对手的网店运营状况和产品信息，从而帮助企业进行市场定位和战略调整；或者，通过该接口，监管部门可以监控企业的电商经营活动，确保合规运营。
该接口的功能是根据提供的企业名称、人名、品牌、产品、岗位等关键词模糊查询相关企业列表。返回匹配的企业列表及其详细信息，用于查找和识别特定的企业信息。
该接口的功能是提供企业在国内外的网店概况信息，通过输入企业的相关标识信息查询，输出企业网店的数量、商品总量、销售平台、主营品牌和产品、以及店铺来源等详细信息。此接口可用于市场调研公司、投资机构、竞争分析团队或电商平台运营者，用于分析企业在电子商务领域的市场影响力、市场覆盖率和商品销售布局，帮助制定市场策略或进行投资决策。
Tool names do not follow verb_noun convention. All four tools start with 'estore_bigdata_' (a product/service prefix) rather than action verbs. Names like 'estore_bigdata_global_online_store_profile' lack clarity about the primary action. LLMs cannot easily infer whether the tool 'gets' data, 'searches' for it, 'lists' stores, or 'describes' profiles. Rename to: get_store_profile, search_products, fuzzy_search_enterprises, get_store_details.
Descriptions are verbose (250-350 chars) and lack actionable structure. They read as feature lists rather than LLM-optimized guidance. For example, 'estore_bigdata_global_online_store_profile' describes 12 output fields in the docstring (domesticEshopCount, domesticEshopBrandList, etc.) but the tool description never explicitly states: 'Returns store counts, product totals, platform list, brands, and products across domestic and foreign markets.' Descriptions should be 50-200 chars, use action-first phrasing, and state when to use the tool vs. alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter 'keywordType' is declared as type 'string' but should be an enum. The description states it accepts 'name, nameId, regNumber, socialCreditCode' but the schema does not enforce this. Free-form strings invite hallucinated values like 'company_name' or 'id'. Convert keywordType to enum: ['name', 'nameId', 'regNumber', 'socialCreditCode']. This affects all four tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All four tools are read-only, this should be declared via readOnlyHint:true in the schema so agents know they are safe to retry. Currently, the risk field in the assessment shows 'READ_ONLY' but this is not exposed in the tool definition itself.
Error handling is minimal and non-actionable. call_api() returns generic strings like 'Query failed' or error messages without recovery guidance. No error categorization (retryable vs. user-fixable vs. fatal). For example, if an invalid keywordType is passed, the API likely rejects it silently, and the LLM receives no hint to try a different value. Implement: (1) error categorization, (2) actionable messages like 'Invalid keywordType: got "company_name", must be one of: name, nameId, regNumber, socialCreditCode', (3) recovery suggestions.
Output schemas are documented in docstrings but not exposed as structured return type hints. Python code shows parameter types (e.g., matchKeyword: str) but the return type is always '-> dict' with no further specification. LLMs cannot see the structure of the response (e.g., that fuzzy_search returns {total: int, resultList: [{annualTurnover: str, ...}]}). Add return type hints and/or expose schema in the tool definition.
pageSize parameter in fuzzy_search has no min/max constraints in the schema. Description mentions 'one page can get at most 50 items' and 'values over 50 are replaced with 50' but the schema does not enforce this, LLMs cannot see these bounds. Add min:1, max:50 to the schema, and adjust the description to be concise: 'Page size (1 - 50, default 50).'
No pagination chain awareness. fuzzy_search returns 'total' and 'resultList' but does not include 'next_cursor' or 'has_more' to signal to agents when more results are available. For large datasets, the LLM may assume it has all results when it only has page 1 of 50. Add 'has_more: bool' or 'next_cursor: string' to the response schema so agents can plan multi-page fetches.