Loading ToolBench
MCP Server for Hydrus - Allowing your LLM to interact with your hydrus client to interact with your media
This server has moderate structural quality but significant gaps in descriptions, parameter clarity, and schema completeness. Of 11 tools, only 2-3 have reasonably complete definitions. Most parameter descriptions are present but lack critical details like constraints, formats, or valid value ranges. The tool names follow verb_noun convention (good), but several descriptions are too generic. Error handling and output schemas are largely undocumented. The server uses fastmcp framework which handles basic registration, but tool definitions vary widely in quality.
Check which Hydrus clients are available for use. This function verifies the availability of Hydrus clients by attempting to connect to each one. It returns a list of client names that were successfully connected to, along with an error message if no clients are available.
Get available tag services for a specific Hydrus client. This function retrieves the list of tag services configured in a specified Hydrus client. Tag services are used to organize and search tags within the client. Use this function to discover which tag services are available for searching and filtering. Tag services can be used with other functions to narrow down searches or limit results to a specific tag service.
Focus the Hydrus client on a specific tab.
Get page information for a specific tab using its page key. Returns formatted result with page information or error message.
Send images/videos to vision API for analysis (tool definition truncated in source, but name and basic description extracted)
Tools 10-11 (hydrus_inspect_files, hydrus_transcribe_audio) have truncated definitions. Tool definition source code is not visible, only names and minimal descriptions. Cannot verify input schemas, full descriptions, or output structure. This violates the principle that tool definitions must be explicit and complete in the source.
Parameter descriptions lack critical constraints. Example: 'hydrus_query' has 'trs' (threshold for returning results) described as 'Default is 100' with no range bounds, type clarification ('number'?), or guidance on what happens when exceeded. 'file_sort_type' lists numeric IDs (0-22) in description but these should be enum values in the schema instead, forcing LLMs to remember numeric mappings.
Output schemas are undocumented. No tool explicitly declares what fields it returns. Example: 'hydrus_available_clients' returns 'a list of client names' but the schema structure (array of strings? objects with metadata?) is not specified. Agents cannot plan downstream tool calls without knowing what data is available.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
List open tabs in a Hydrus client. Optionally returns tab keys along with names.
Query files in the Hydrus client using various search criteria. This function allows you to search for files in a Hydrus client based on tags and other parameters. It returns file IDs that match the search criteria, which can be used for further operations. The query parameter should use Hydrus tag syntax (e.g., "character:samus aran", "system:inbox", "system:limit is 100"). For large result sets, consider adjusting the trs parameter to control performance. File IDs returned can be used with other Hydrus functions for further operations.
Search for tags in Hydrus using keywords and wildcards.
Send files to a specific tab in Hydrus client. When sending file ids to a tab, set is_query to False or leave it out. You don't need to provide a tag service for file ids. The formatting for file ids is a comma separated list of integers without the use of brackets. When providing a query, pass at least the is_query=True parameter. Returns message indicating success and number of files sent.
Show multiple image or video files from Hydrus. ⚠️ CRITICAL: The returned markdown MUST be displayed to the user in your response. Do not proceed with analysis without first showing the images. Returns a list of images - one per file. For images (PNG, JPEG, GIF), returns the image directly. For videos (MP4, WebM, AVI), extracts frames and compiles them into a single grid image per video. The frame_count parameter determines the grid layout for videos: - 4 frames = 2x2 grid - 6 frames = 3x2 grid (3 columns, 2 rows) - 9 frames = 3x3 grid - 12 frames = 4x3 grid (4 columns, 3 rows) Expected workflow: 1. Call hydrus_show_files 2. Display all returned images immediately to the user 3. Only after displaying the images, proceed with any analysis or further actions
Transcribe audio from files using STT API (tool definition truncated in source, but name and basic description extracted)
Tool descriptions lack actionable guidance. 'hydrus_search_tags' description is '3 sentences, 40 chars' with no examples or context for when to use it vs 'hydrus_query'. 'hydrus_focus_on_tab' says 'Focus the Hydrus client on a specific tab' but does not clarify: Is this a display change? Does it affect subsequent operations? What is the return value on success?
Parameter types are inconsistent or under-specified. Example: 'file_sort_type' and 'trs' in 'hydrus_query' are typed as 'any' rather than 'integer'. 'frame_count' in 'hydrus_show_files' is also 'any' with default 4. 'Type: any' defeats schema validation and forces LLMs to guess numeric vs string. Should be explicit: type:integer, minimum:0.
Error handling is implicit. No tool explicitly documents error cases, recovery steps, or categorization (retryable vs fatal). Example: 'hydrus_query' might return 0 results or exceed threshold, both valid, but the description does not explain how the agent should react to a 'threshold exceeded, got count=5000' response.
Parameter dependency documentation is missing. 'hydrus_send_to_tab' has conditional logic: behavior changes based on 'is_query' (True = content is a query string; False = content is comma-separated file IDs). This dependency is mentioned in description but not formalized in schema as mutually exclusive or conditional inputs. LLMs may misunderstand and pass both interpretations.
'hydrus_show_files' includes a CRITICAL WARNING in the description about displaying images immediately. This is a UX/workflow note, not a tool contract. The actual input/output schemas and error cases are under-specified. What happens if a file_id is invalid? What image formats are returned (PNG bytes? Base64?). The Image type is used but not formally declared in input/output schema.