searchSearch current Hyperliquid vault records and canonical VaultVision research pages. Use this standard discovery tool before fetch when the requested entity is ambiguous.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint=false. The description adds context about data being 'current' and 'canonical,' but it does not disclose additional behavioral details such as pagination, rate limits, or how results are ordered. This is adequate given the annotations, but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states what is searched, and the second gives actionable routing guidance. Every sentence earns its place, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has a small parameter set, output schema, and strong annotations, which reduces the burden on the description. Still, the description leaves a notable gap: it does not disambiguate from search_vaults, and it provides no parameter guidance despite zero schema descriptions. It is adequately useful but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the query and limit parameters. It does neither: there is no mention of query syntax, what constitutes a valid query, how limit behaves, or why limit is capped at 20. The description adds no parameter-level meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Search') and its scope ('current Hyperliquid vault records and canonical VaultVision research pages'), so an agent can tell it is a discovery tool. It also points toward fetch as a downstream step, but it does not differentiate itself from the sibling tool search_vaults, which appears to overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage guidance: use this as a standard discovery tool before fetch when the entity is ambiguous. This explicitly establishes a condition and a preferred ordering. However, it does not mention when not to use it or how it compares to search_vaults, leaving that sibling distinction unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct actions and resources, but search_vaults and rank_vaults both return ordered vault lists, and fetch and get_vault can retrieve similar single-record data. The descriptions provide enough context to disambiguate in most cases.
Tool names generally follow a clear verb_noun snake_case pattern (compare_vaults, get_vault, rank_vaults). Standalone verbs like fetch and search are minor deviations but remain readable and consistent in style.
Nine tools is well-scoped for a research-focused server. Each tool covers a distinct investigation workflow without redundant entries or excessive surface area.
The server covers discovery, retrieval, comparison, ranking, risk explanation, alerts, and HLP-specific metrics. Minor gaps exist, such as no historical/time-series tool, but core research workflows are fully supported.