Loading ToolBench
A Model Context Protocol server providing tools for ZoomEye queries for LLMs
This server has three tools with mixed quality. Tool naming is decent (verb_noun style), but descriptions range from incomplete to overly verbose. Parameter schemas are present but lack critical details. Output schemas are entirely undocumented. Error handling is basic (raises ValueError) with no recovery guidance. The server is read-only (safe from destructive operations) but lacks LLM-optimization patterns throughout.
Search query for ZoomEye. ### Parameters |Parameter|Type|Required|Description| | ----- | ----- | ----- | ----- | |qbase64|string|true|Base64 encoded query string. For more, refer to Related references.| |fields|string|false|The fields to return, separated by commas. Default: ip, port, domain, update_time. For more, refer to Response field description| |sub_type|string|false|Data type, supports v4, v6, and web. Default is v4.| |page|integer|false|View asset page number| |pagesize|integer|false|Number of records per page, default is 10, maximum is 10,000.| |facets|string|false|Statistical items, separated by commas if there are multiple. Supports country, subdivisions, city, product, service, device, OS, and port.| |ignore_cache|boolean|false|Whether to ignore the cache. false, supported by Business plan and above.|
Search for detailed vulnerability information by vulnerability ID and return formatted results. Use this tool to retrieve comprehensive security vulnerability details from the vulnerability database using a vulnerability identifier (CVE, CNVD, CNNVD). Results include:
Search for vulnerability information by keyword
Output schemas entirely undocumented for all three tools. LLMs cannot plan downstream calls or extract expected fields.
Tool descriptions are incomplete or vague. zoomeye_vuldb_by_id says 'Results include:' and cuts off. zoomeye_vuldb_by_keyword is 6 words with no context.
Conflicting constraint documentation: zoomeye_search schema says pagesize maximum 1000, but description above says 10,000. This causes LLM confusion and potential API errors.
No pagination or result limit enforcement. zoomeye_search could return thousands of records, blowing context window. No indication of max default results or guidance on pagesize limits for LLM reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Error handling is minimal. Tools raise generic ValueError with API error messages. No guidance for LLM on recovery (e.g., 'Try with a simpler query', 'API key may be invalid'). No error classification (retryable vs fatal).
API key is passed via environment variable (good security practice), but server code does not validate presence until tool invocation. If key is missing, tools fail with ValueError. No upfront validation or clear error message.
Parameter descriptions lack detail on format and constraints. E.g., 'qbase64' says 'Base64 encoded query string' but does not explain what kind of query syntax is valid. Users (and LLMs) must consult external docs (SEARCH_SYNTAX_GUIDE import exists but is not surfaced in tool descriptions).