Loading ToolBench
HAP - Model Context Protocol (MCP) Server by MingdaoCloud for integrating with Mingdao API
Three tools with complete Zod schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools are READ_ONLY (good for safety), but descriptions lack actionable guidance for LLM selection. The list_worksheet_records tool has extensive enum reference documentation embedded in the description (FilterTypeEnum, DateRangeEnum), which is helpful but should be formalized as parameter constraints. No error recovery guidance or output schema documentation visible.
Get the field structure and field types of the worksheet. The response includes field type information where each field has a 'type' value corresponding to the following field types: Field Type Reference: 2=Text, 3=Text-Phone, 4=Text-Phone, 5=Text-Email, 6=Number, 7=Text, 8=Number, 9=Option-Single Choice, 10=Option-Multiple Choices, 11=Option-Single Choice, 15=Date, 16=Date, 24=Option-Region, 25=Text, 26=Option-Member, 27=Option-Department, 28=Number, 29=Option-Linked Record, 30=Unknown Type, 31=Number, 32=Text, 33=Text, 35=Option-Linked Record, 36=Number-Yes1/No0, 37=Number, 38=Date, 40=Location, 41=Text, 46=Time, 48=Option-Organizational Role, 50=Text, 51=Query Record
List records from the worksheet
List worksheets within an application
list_worksheets lacks meaningful description. Current text 'List worksheets within an application' (34 chars) is below the 50-char minimum for LLM selection guidance. Does not explain when to call this vs other discovery tools, what fields are returned, or prerequisites.
Output schemas not documented. Tools return JSON with 'success', 'result', and 'error' fields, but the structure of 'result' (fieldsJson, fieldsTable, records) is not formally specified. LLMs cannot plan downstream calls without knowing return field names and types.
Filter parameter documentation embeds enum values as text (FilterTypeEnum 1=Like, 2=Eq, etc.) instead of formalizing them as Zod enums. This forces LLMs to parse text descriptions rather than selecting from machine-readable constraints. The filters array itself lacks clear guidance on when to use values vs value vs dateRange.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
No error recovery guidance. Error responses return JSON with success=false and error message, but do not guide the LLM on next steps (retry, call discovery tool, ask user). A 'Failed to get worksheet information' error gives no actionable path forward.
list_worksheet_records accepts optional filters but does not document mutual exclusivity or dependencies. The description notes that filterType determines which value fields apply (values vs value vs dateRange), but this is not enforced in the schema or clearly stated as a constraint.