Loading ToolBench
店铺大数据 MCP server providing access to enterprise store data, fuzzy search, offline store search, and restaurant branch statistics APIs
This server has 4 tools with inconsistent quality. Tool naming is problematic: all tools use prefixes (store_bigdata_*) rather than action verbs, making intent unclear to LLMs. Descriptions are present but verbose (400-500+ chars), exceeding the recommended 10-1024 range and wasting tokens. Input schemas are properly typed with JSON Schema format, but parameter descriptions are often vague or contain API jargon untranslated for LLMs. Output schemas are documented in docstrings but lack structured response format declarations. Error handling is minimal, the call_api() function returns generic failures ('查询失败', 'API call failed') with no recovery guidance. The server uses STDIO transport only, which is a hard cap on protocol readiness. Most critically, tool names like 'store_bigdata_company_restaurant_branches' do not follow verb-noun convention; they should be action-oriented (e.g., 'get_restaurant_branches', 'search_offline_stores').
该接口的功能是根据输入的企业信息（如企业名称、注册号、统一社会信用代码或企业id）查询并返回该企业旗下餐饮品牌门店的详细信息，包括总数、品牌类别、城市和省份的门店分布等。此接口可能用于企业内部管理、商业合作对接、市场调研及分析等场景，帮助相关人员获取某一企业在餐饮行业的市场布局和品牌影响力。通过分析返回的数据，企业可以优化资源配置、制定市场策略，并评估品牌覆盖的地域广度和门店分布情况。
该接口的功能是根据提供的企业名称、人名、品牌、产品、岗位等关键词模糊查询相关企业列表。返回匹配的企业列表及其详细信息，用于查找和识别特定的企业信息。
该接口的功能是提供线下店铺的搜索功能，通过输入店铺名称、类目、消费区间、店铺状态、地理位置等条件，返回符合条件的店铺信息列表，包括店铺的详细信息和联系方式。此接口可以用于帮助用户便捷地找到符合其需求的线下店铺，例如在本地服务类应用中帮助消费者搜索到达便利的店铺，或可供商家进行市场分析和潜在客户定位。通过结合人均消费、店铺状态、地理区域等多种条件进行筛选，有助于精确匹配用户需求。
该接口的功能是根据品牌ID获取特定餐饮品牌在各城市及省份的门店分布情况，包括各城市和省份的门店数量统计。此接口可以用于企业内部业务分析，帮助企业了解其门店在不同地域的分布，从而优化资源分配和市场策略。
Tool names do not follow verb_noun convention. All tools use noun-prefix naming (store_bigdata_*) instead of action verbs (get_, search_, list_). LLMs cannot infer intent from name alone and must parse lengthy descriptions, increasing hallucination risk.
Tool descriptions are excessively long (400-530 chars), exceeding recommended 10-1024 range. Descriptions contain marketing copy and usage scenarios that waste tokens without clarifying parameters. Example: store_bigdata_company_restaurant_branches description is 530 chars and buried the actual parameter requirements.
Parameter descriptions lack LLM clarity. Many use Chinese technical terms or API jargon (e.g., 'matchKeyword', 'keywordType') without clarifying what the LLM should pass. Example: keywordType parameter description '主体类型枚举' provides enum values but not guidance on when to use each.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Error handling is generic and non-actionable. call_api() function returns '查询失败' (query failed) and '接口调用失败' (API call failed) without indicating retry-ability, missing required fields, or next steps. LLMs cannot self-correct or guide users.
Output schemas documented in docstrings but not formalized in response objects. Tool responses return raw API data without structured typing or field descriptions. No pagination or limit enforcement documented in actual code (pageSize defaults exist but not enforced in server).
Parameter constraints not enforced in code. pageSize documentation claims 'max 50' but code does not validate this. ooMinStorePerCapitaConsumption has unrealistic default (10000000000.0). Numeric ranges not validated, inviting LLM errors.
Secrets stored in environment variables (INTEGRATOR_ID, SECRET_ID, SECRET_KEY) are checked at tool call time, not startup. If missing, tools fail with generic error. No pre-flight validation or clear messaging.
No tool composition guidance. store_bigdata_company_restaurant_branches docstring mentions 'call fuzzy_search first if you don't have full name' but this is buried in prose; not formalized as a dependency hint or separate discovery tool.