Loading ToolBench
IP address lookup server using IPWhois information and IP segment database
IPSearch has two READ_ONLY tools with basic descriptions but significant quality gaps. Tool names follow a verb pattern (ip_lookup, keyword_lookup) but are generic and underdifferentiated. Descriptions are present but minimal (Chinese text, 25 - 31 chars after translation, well below the 194-char baseline). Both tools lack output schema documentation, responses are unstructured text strings. Parameter descriptions exist but lack constraints (format validation, range limits). No error handling guidance beyond returning error strings. The schema definitions in mcp.WithString() are visible and typed, but output structure is completely undocumented. STDIO-only transport caps protocol readiness at 50, further limiting production applicability.
根据IPv4地址查询所属IP段以及IPWhois信息
根据IPWhois登记信息关键字搜索IP段以及IPWhois信息
Output schema not documented. Both tools return unstructured text (mcp.NewToolResultText), but there is no declaration of what fields, structure, or format the response contains. LLMs cannot parse or chain results without knowing the output shape.
Descriptions are extremely minimal (25 - 31 characters), well below the 194-character baseline for production tools. 'Query IPv4 address for IP segment and IPWhois info' (translated) lacks context about when to use this tool vs. keyword_lookup, what format the IP must be in, what 'IPWhois' means, or what the response structure is.
Parameters lack format and constraint documentation. The 'ip' parameter accepts any string; there is no description stating 'IPv4 address in dotted-decimal notation (e.g. 192.0.2.1)' or mentioning that validation happens server-side and will reject invalid formats. The 'keywords' parameter docs say 'comma-separated keyword list' but do not specify minimum/maximum length, special character handling, or whether keywords are case-sensitive.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Error messages are generic and don't guide recovery. Examples: '无效的IPv4地址' (Invalid IPv4 address) with no hint to check format. 'At least provide one valid keyword' gives no examples of valid keywords. Following the pattern:recovery-guide, errors should state what went wrong AND what to try next.
Tool names are generic verbs without clear differentiation. 'ip_lookup' and 'keyword_lookup' both perform searches, but the names don't indicate the semantic difference (IP segment vs. registrant info). Better names: 'search_ip_segment' or 'lookup_ip_address' vs. 'search_ip_registrant' or 'lookup_whois_keywords'.
Pagination not implemented for keyword_lookup. The tool enforces maxKeywordResults=2000 and silently truncates, but there is no limit parameter, offset/cursor support, or indication to the LLM that results are capped. This forces agents to make multiple calls with different keywords to retrieve large result sets, and they have no way to know results were truncated.
Response includes raw database fields without context. The lookupByIP response returns 'IP段' (IP range), 'netname', 'descr', etc. without explaining what these fields mean. For example, 'status' field is not documented, does it indicate network status, allocation status, or something else? LLMs need context to interpret response fields.