Loading ToolBench
MCP server for querying building and enterprise data through the HandaaS platform, providing fuzzy search, office address details, office address statistics, and building information query capabilities.
This MCP server provides 4 tools for querying building/enterprise data. Tool names follow verb_noun convention (e.g., fuzzy_search, office_address_details), which is good. However, the server has significant definition quality gaps: (1) Parameter descriptions are present but often unclear about dependencies and valid values. For example, 'address' in building_bigdata_office_address_details uses a complex format ('"广东省,广州市"') that is poorly documented. (2) Enum constraints are mentioned in descriptions (e.g., keywordType values: name, nameId, regNumber, socialCreditCode) but not formalized as JSON Schema enums, forcing LLMs to parse free-form text. (3) Output schemas are documented in docstrings but not in structured JSON Schema format, only field names and types are listed, without explicit schema objects. (4) Error handling is minimal: the call_api() function returns generic error messages like '查询失败' (query failed) or API status codes without actionable recovery guidance. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. The server correctly identifies all tools as READ_ONLY in risk metadata but does not use MCP tool annotations. Per-tool scores reflect these patterns across all 4 tools.
支持通过楼宇名称、楼宇类型等查询指定地区的全部楼盘信息，包括楼宇名称、楼宇别名、楼宇地址、楼宇类型、楼宇入驻企业数量等
该接口的功能是根据提供的企业名称、人名、品牌、产品、岗位等关键词模糊查询相关企业列表。返回匹配的企业列表及其详细信息，用于查找和识别特定的企业信息。
该接口功能及用途是根据特定的企业标识信息，查询和返回企业的办公地址相关数据，包括办公地址总数、每个城市的办公地址详细信息等。该接口的主要使用场景包括企业内部管理系统用于了解办公地址布局、商业分析工具中用于市场地理分布分析，以及政府或合作机构进行企业信息核实或者决策辅助时快速获取企业在各地的实际运营地址信息。
该接口功能及用途是根据特定的企业标识信息，查询和返回企业的办公地址相关数据，包括办公地址城市、每个城市的办公地址数量等。该接口的主要使用场景包括企业内部管理系统用于了解办公地址布局、商业分析工具中用于市场地理分布分析，以及政府或合作机构进行企业信息核实或者决策辅助时快速获取企业在各地的实际运营地址信息。
No JSON Schema enum constraints for constrained parameters. keywordType, estatePropertyType, and address parameters accept specific enumerated values (e.g., keywordType: name|nameId|regNumber|socialCreditCode) but are defined as free-form strings. LLMs will hallucinate invalid values instead of selecting from valid options.
Output schemas documented in docstrings but not structured. Tool docstrings list return fields and types (e.g., 'total: int', 'resultList: list of dict'), but this is free-form documentation, not JSON Schema. LLMs cannot parse docstring schemas to understand downstream chaining or field availability.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Generic error messages without recovery guidance. call_api() returns '查询失败' (query failed) or generic HTTP status codes. No indication of whether the error is retryable, user-fixable, or fatal. Agents cannot self-correct.
Address parameter format is complex and poorly documented. building_bigdata_building_query accepts address as a multi-level array like '[["福建省",["贵州省","安顺市","平坝县"]]]' but description relies on a string example that LLMs may misparse. building_bigdata_office_address_details uses comma-separated format. Inconsistent and error-prone.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). All 4 tools are read-only queries with no side effects, but this is not declared via MCP tool annotations. Server metadata marks them as READ_ONLY in risk, but not in protocol-level annotations that clients expect.
Parameter dependencies undocumented. building_bigdata_office_address_details states: 'if you don't have enterprise fullname, call fuzzy_search first' in one place but this critical dependency is buried in the matchKeyword description and may be missed. No formal dependency documentation between tools.
No pagination limits documented. building_bigdata_fuzzy_search returns 'resultList' with no documented upper limit on total results. description states 'pageSize: 一页最多获取50条数据' (max 50 per page) but total result count is unbounded. An agent requesting pageIndex=1, pageSize=50 could receive thousands of results in resultList.