Hyperliquid MCP Updated
Server Quality Checklist
Latest release: v0.2.1
- Disambiguation4/5
Most tools target distinct data types, but several near-duplicates exist (e.g., hl_open_orders vs hl_frontend_open_orders; hl_user_fills vs hl_user_fills_by_time; hl_meta vs hl_meta_and_asset_ctxs). Descriptions help differentiate them, but an agent could still easily misselect between pairs that differ only in subtle scope or parameters.
Naming Consistency5/5All tools consistently use the 'hl_' prefix with snake_case and descriptive noun phrases (e.g., hl_user_funding_history, hl_candles, hl_spot_meta). The naming pattern is highly predictable and uniform across all 41 tools.
Tool Count3/541 tools is a large surface, but it reflects the broad Hyperliquid API info endpoints. However, many tools are near variants of one another (meta, meta_and_asset_ctxs, user_fills variants), inflating the count and making navigation more difficult than necessary.
Completeness2/5The toolset covers an extensive range of read-only query endpoints, but entirely lacks any write/trading tools (order placement, cancellation, transfers, staking actions). For a trading-focused server, this is a significant gap that would prevent agents from executing core workflows.
Average 2.5/5 across 41 of 41 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior, but it provides none. It does not state return values, side effects, permissions, or any operational traits beyond the ambiguous word 'state,' which fails to inform the agent of what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might seem concise, but it is under-specification rather than efficient brevity. There is only a fragment with no useful content, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description completely fails to explain the tool's role, when to call it, or what the referral state represents. The agent cannot determine the input's meaning or the expected returned data, making the tool effectively unusable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description offers no explanation of the required 'user' parameter. The agent receives no insight into what the user identifies (e.g., ID, address, username) or how it is used to fetch referral state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Referral program state (referral)' is nearly a tautology, restating the tool name without a clear verb or resource. It does not say whether the tool retrieves, computes, or updates referral state, nor does it differentiate from sibling state tools like hl_clearinghouse_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to guess based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only offers a vague abstraction label. It does not indicate whether this is a read operation, what data it returns, or any side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise. The single sentence does not communicate actionable content, so it does not earn its place and provides no useful structure for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description lacks any behavioral or contextual information necessary to invoke the tool correctly. It provides less utility than minimal alternatives and is wholly inadequate for a tool with such ambiguous naming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'user' with 0% description coverage. The description does not mention this parameter or its meaning, format, or purpose, completely failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unified account / portfolio margin abstraction' lacks a verb and does not state what action the tool performs. It restates the tool name via '(userAbstraction)' and gives no distinction from similar sibling tools like hl_portfolio or hl_user_dex_abstraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided, leaving the agent without criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It provides none: no mention of read-only nature, pagination, time filters, or other operational details. The description is a noun phrase with no behavioral content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words), but this is under-specification rather than effective conciseness. It lacks structure and does not earn its place by adding useful information; it simply repeats the tool name with the word 'Active'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists and the tool is simple, the description is inadequate. It does not explain what constitutes an 'active staking delegation', how this differs from related staking tools, or the context in which this data would be useful. The description adds no value beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'user' with 0% description coverage, and the tool description does not explain the parameter's meaning or format. The description completely fails to compensate for the lack of schema documentation, leaving the agent to guess what value 'user' expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Active staking delegations (delegations)' is essentially a tautology of the tool name, restating 'staking delegations' without specifying an action like 'list' or 'get'. It offers only a vague qualifier 'active' and fails to distinguish from sibling tools such as hl_user_staking_summary or hl_delegator_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. The agent is left to infer the tool's purpose entirely from its name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it says nothing about side effects, permissions, rate limits, or output format. The description is purely a label, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. It is a single fragment that omits critical information, so the brevity is not a positive trait here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools and the existence of an output schema, the description is far too minimal to orient an agent. It does not convey what data the summary returns, how it relates to other staking tools, or when it should be invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain the 'user' parameter at all. It adds no semantic detail about what kind of user identifier is expected or how it should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Staking summary for user (delegatorSummary)' restates the tool's name without a verb or clarification of what the summary contains. It is nearly tautological and does not distinguish this from siblings like hl_user_staking_delegations or hl_user_staking_rewards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or comparisons to related sibling tools, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals nothing about read-only status, output characteristics, or limitations, making any behavioral inference impossible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specifying and tautological. It is not concise in a communicative sense—it simply echoes the name without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description offers no context about what the output means or how this tool differs from closely related siblings. The description is wholly inadequate for a tool in a large family of similar data-access tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already complete. The description adds no parameter information, but none is needed; a baseline of 4 is appropriate for the zero-parameter case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Spot meta plus asset contexts' merely restates the tool name without any functional detail. It does not use a specific verb or resource and fails to distinguish the tool from siblings like hl_meta or hl_meta_and_asset_ctxs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given many sibling tools with overlapping names, the lack of any contextual or alternative-related information is a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what side effects occur, whether authentication is required, or what the response contains. The description only states a static relationship ('linked to user') with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length (one sentence) with no wasted words. However, it is under-specified and essentially repeats the tool name, so it does not earn its place despite being short. It is not verbose, but it also adds little information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description fails to explain what 'extra agents' are and in what context this tool should be used. With no usage guidelines, minimal parameter semantics, and a vague purpose, the description is insufficient for an agent to correctly select and invoke the tool, especially given the large number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'user' with no description, and schema description coverage is 0%. The description's phrase 'linked to user' hints that the 'user' parameter identifies whose extra agents are queried, but it does not explain the expected format (e.g., ID, address) or provide any further semantics. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extra API agents linked to user (extraAgents)' is essentially a restatement of the tool name. It lacks an action verb (e.g., 'Get', 'List') and does not clearly explain what 'extra agents' are or how the tool operates. It provides the resource (agents) and relation (linked to user) but is more of a noun phrase than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus any of the many sibling tools. The description does not mention alternatives, exclusions, or scenarios in which this tool is appropriate. An agent is left without any context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior on its own. It only provides a noun phrase, revealing nothing about return data, side effects, permissions, or whether this is a read-only operation. The agent is left entirely in the dark about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity is not conciseness when it omits essential information. The single phrase 'Sub-accounts for master (subAccounts)' is a vague label, not a functional description. It does not earn its place because it adds no value beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the basic purpose of the tool is undefined. For a one-parameter tool, the description should at minimum state that it retrieves sub-accounts for a given master user. The current text does not even specify what the tool does, making it incomplete for even the simplest invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'user' (string), and schema description coverage is 0%. The description does not mention this parameter at all, so the agent has no context about what 'user' represents (e.g., master account ID, email) or how it should be formatted. The description shoulders the responsibility to compensate for schema gaps, and it completely fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sub-accounts for master (subAccounts)' identifies a resource but lacks a verb to indicate the operation. It is essentially a restatement of the tool name, providing no clear idea whether it fetches, lists, or creates sub-accounts. This is insufficient for an agent to understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it relates to sibling tools like hl_user_portfolio or hl_user_fills. The description does not mention any context, prerequisites, or alternatives, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose the behavior beyond naming the state. No annotations exist, so the description carries the full burden. It doesn't mention read-only nature, authorization needs, or what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but under-specification is not the same as conciseness. It does not use the space to add meaningful structure or key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and no annotations, this simple state query tool could be fully described in one sentence. The current description fails to specify what the tool actually does or what the user parameter represents, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'user' parameter. The parenthetical 'userDexAbstraction' hints at per-user state but adds no details about value format or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('HIP-3 dex abstraction state') and adds the parenthetical '(userDexAbstraction)' which helps identify the tool. However, it lacks a verb (get/fetch/retrieve) and remains vague about what the state contains, so it only partially clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative state query tools like hl_user_abstraction. There are no exclusions, prerequisites, or context cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state that this is a read-only query, what data it returns, or any side effects. The description simply names the resource without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cryptically short, but the single sentence adds no value beyond the name. It is under-specified rather than genuinely concise, and it fails to earn its place by providing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, output schema exists), the description is still too sparse. It does not explain what the status entails, how it relates to deploy auctions, or what the output represents. The agent receives minimal orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter information missing. Baseline for 0 params is 4, and the description does not need to add parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perp deploy auction status (perpDeployAuctionStatus)' is essentially a tautology, restating the tool name with an alias. It lacks a verb or explicit action, so it does not clearly state what the tool does or return. It only hints at the perp vs. spot distinction via the word 'Perp'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance whatsoever on when to use this tool versus alternatives such as hl_spot_deploy_auction_status or other status tools. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It only states a noun phrase without mentioning whether this is a read-only operation, side effects, authentication requirements, or what the response contains. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but this is under-specification rather than conciseness. It lacks structure and fails to earn its place by providing essential context; it reads more like a label than a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one param) and has an output schema, the description does not explain what the returned metadata contains or how to interpret it. The description is too sparse to be considered complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required param 'user' with no description, and schema coverage is 0%. The description does not clarify what 'user' means or how to format it. With no compensation for the undocumented parameter, the semantics are entirely missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Account role metadata (userRole)' identifies a specific resource but lacks an explicit action verb like 'get' or 'retrieve'. It is slightly ambiguous about what the tool does, but it does convey that it relates to account role metadata, which is more than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives like hl_portfolio or hl_user_fills. No exclusions, prerequisites, or alternative tool mentions are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'balances' without stating whether the operation is read-only, what data is returned, or any side effects. It implies a state query but fails to explicitly disclose behavior, leaving the agent to infer safety and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. 'Spot clearinghouse balances (spotClearinghouseState)' is essentially a label, not a self-contained explanation. It leaves crucial information missing, making it more under-specified than concisely sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter and no output schema visible in the prompt, yet the description gives no information about return values, error conditions, or behavioral nuances. It is completely inadequate for an agent to confidently invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a 'user' parameter with zero description coverage, and the description does not explain it at all. The parameter's purpose, format, or how it affects results are completely undocumented. Given the low schema coverage, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (spot clearinghouse balances) and differentiates from sibling 'hl_clearinghouse_state' by including 'spot'. However, it uses a noun phrase without a verb, so it is unclear whether the tool retrieves, updates, or performs some other action. It is not misleading, but it lacks a clear action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention how it relates to hl_clearinghouse_state or other user state tools, nor does it give any context for selecting it. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It merely restates the tool name with 'Recent TWAP slice fills' and gives no details about time windows, ordering, pagination, or what constitutes a 'slice fill'. This is essentially a tautology and adds no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that is under-specification rather than effective conciseness. It reads as a title or subtitle, repeating the tool name, and does not offer any additional information that earns its place. No clear sentence structure or front-loaded verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one required parameter and an output schema exists, the description lacks essential contextual information such as how 'recent' is defined, any default limits, or how this differs from other fill-related tools. The agent has no basis for deciding when to use it or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the single 'user' parameter. It provides no context about what format the user should be in, whether it's an address, ID, or other identifier, or any constraints. The description adds no semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recent TWAP slice fills' clearly identifies the resource (TWAP slice fills) and implies a retrieval operation, distinguishing it from sibling tools like hl_user_fills. However, it lacks a specific verb like 'get' or 'list', and 'recent' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hl_user_fills or hl_user_fills_by_time. The description does not mention any exclusions or preferred contexts, leaving the agent to guess when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It does not state that this is a read-only operation, nor does it describe any edge cases, response format, or limitations. It only states the data content, providing no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short, but this is under-specification rather than meaningful conciseness. It is a noun phrase rather than a complete, structured description. It does not fulfill the basic expected format of a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a single parameter and an output schema, the description does not explain what the response contains, such as a list of vaults with equity values. It is incomplete even for a simple lookup tool, lacking any context about the returned data or usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'user' parameter has 0% schema description coverage, and the description does not mention it at all. The description fails to clarify what format or address is expected, leaving the agent without necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'User's equity across Hyperliquid vaults' clearly identifies the tool's resource (vault equities) and scope (a user). It is specific enough to distinguish it from generic portfolio or clearinghouse tools, though it lacks an explicit verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given many sibling tools relate to user data, the description should indicate, for example, that this is for vault-specific equity rather than overall portfolio or clearinghouse state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, yet it only says 'Delegate / undelegate history' and adds no behavioral context. It does not state whether this is a read-only lookup, what fields or time range are covered, or that it pertains to staking delegations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than efficient conciseness. It reads as a fragment and fails to convey enough information to be useful for tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still lacks essential context: no definition of what constitutes a delegation event, no mention of ordering or pagination, and no differentiation from sibling tools. For a one-parameter tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the 'user' parameter. It does not explain whether 'user' is a wallet address, username, or ID, or how the value should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (delegate/undelegate history) but uses a noun phrase without an explicit verb, making the action implicit. It adds the clarification of both delegate and undelegate, but does not differentiate from sibling tools like hl_user_staking_delegations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hl_user_staking_delegations or hl_user_staking_summary. The description gives no context for selecting this tool over related staking history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints at the return content ('trigger/TPSL-style visibility') but does not state whether the operation is read-only, what side effects may occur, or what the 'frontendOpenOrders' distinction implies behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the parenthetical '(frontendOpenOrders)' is redundant with the tool name and does not add clarity. The phrase is a fragment rather than a complete sentence, and a more direct construction would be equally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description fails to explain how this tool differs from the closely named sibling `hl_open_orders`, nor does it provide usage context for the parameters or any constraints. The description is too minimal to be considered complete for a tool in a large sibling family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description offers no explanation of the `user` or `dex` parameters. The agent receives no semantic guidance beyond the bare parameter names, which is insufficient for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('open orders') and differentiates itself from sibling `hl_open_orders` by mentioning 'trigger/TPSL-style visibility' and 'frontendOpenOrders'. However, it lacks an explicit verb like 'gets' or 'lists', making it slightly less clear than it could be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives like `hl_open_orders` or `hl_order_status_by_oid`. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the metadata contains (universe, decimals) but does not explicitly indicate that it is a read-only operation, nor does it describe any side effects, auth requirements, or output behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it is a fragment rather than a well-formed sentence. It lacks structure and reads more like a terse annotation, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 optional parameter, output schema present), the description gives a basic idea but fails to explain how to invoke it correctly. The parameter is undocumented, and no usage context is provided, making it inadequate for an agent to select and call the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'dex' has 0% schema coverage, and the description does not mention it at all. The agent has no information about what 'dex' means, what values it accepts, or whether it is required (though the schema shows it has a default and is not required).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as perp metadata and specifies its content (universe, size decimals), distinguishing it from sibling tools like hl_spot_meta. However, it lacks an explicit verb such as 'get' or 'fetch', which leaves the action slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like hl_meta_and_asset_ctxs or hl_spot_meta, nor does it mention any prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only states the subject matter. It does not mention that the operation is read-only, the time range semantics, pagination, or any response details. This is a significant gap for a history query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. It is just a fragment without any structure or elaboration, offering minimal value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and an output schema, the description fails to provide essential context about how to call the tool, what the parameters represent, and what the response contains. The output schema covers return values, but the description does not aid in invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 parameters. It does not mention 'user', 'start_time_ms', or 'end_time_ms' at all. The parameter names are somewhat self-explanatory, but no format, units, or meaning are clarified, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'User funding payments' clearly identifies the tool's resource (user funding payments) and scope (user-specific), distinguishing it from the sibling hl_funding_history which is likely global. However, it lacks an explicit verb like 'get' or 'list', making it a label rather than a full statement of action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as hl_funding_history for global funding data. It also fails to mention any prerequisites or context for invoking it, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only says 'info', implying a read operation, but discloses no details about authentication, rate limits, return behavior, or side effects. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise in length, but it is under-specified and lacks substantive content. It is not a waste of words, but it does not fully earn its place given how little it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and minimal description, the tool is incompletely specified. It does not explain what 'userRateLimit' refers to, how the user parameter is used, or how this tool fits among the many sibling tools. The presence of an output schema slightly reduces the need for return details, but the description is still too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'user' with 0% description coverage. The description does not explain the parameter's format, meaning, or relationship to the 'userRateLimit' mention. It adds no explicit value beyond what the parameter name suggests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'User API rate limit info (userRateLimit)' provides the resource but lacks an explicit verb like 'get' or 'return'. It is close to a tautology of the tool name, though it adds 'API' and 'info'. It does not distinguish from sibling tools, so it is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. With many sibling user-related tools, there is no mention of context, exclusions, or preferred scenarios, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only states 'for user' without detailing what is returned (e.g., pagination, time range, order statuses). The word 'historical' implies a read operation, but the description does not confirm read-only nature or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified, reading as a fragment rather than a clear instruction. The parenthetical 'historicalOrders' is redundant and does not earn its place, making the description less effective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one parameter) and has an output schema, the description omits valuable context such as what 'historical' includes (e.g., all order statuses, time window) and how to specify the user. It is a bare minimum that leaves room for confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists only 'user' as a required string, and the description does not explain its format or constraints (e.g., is it an address, ID, or username?). With 0% schema description coverage, the description fails to add meaningful semantics beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource (historical orders) and scope (for user), distinguishing it from siblings like hl_open_orders. However, it lacks a verb, reading as a label rather than an action, and the parenthetical 'historicalOrders' is redundant with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as hl_open_orders or hl_user_fills. It does not mention any prerequites, exclusions, or contexts, leaving the agent to infer usage solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic purpose. It does not disclose whether the 'dex' parameter is optional or how the output is structured, nor does it mention any read-only or rate-limit implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is efficiently front-loaded, though the brevity comes at the cost of omitting important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a parameter and no annotations, the description is too sparse to be considered complete. Although an output schema exists, the description still leaves the agent guessing about the role of 'dex' and the exact nature of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description does not mention the 'dex' parameter at all. Since the description is the only source of parameter meaning, it completely fails to explain what 'dex' does or how it affects the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides mid prices for all assets, which is specific and unambiguous. However, it lacks an explicit verb like 'get' or 'list' and does not differentiate it from sibling tools that might also relate to market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions or preferred contexts, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it mention any potential side effects, authentication requirements, or data freshness. It simply lists the contents of the state without disclosing operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a colon-separated list of contents. It avoids redundancy and is appropriately front-loaded. However, it is under-specified, which slightly detracts from its structural completeness, but for conciseness alone it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description is too sparse. It fails to explain the tool's purpose beyond the name, does not describe parameters, and lacks context on what the state represents or when to use it. The output schema covers return values, but the description still leaves many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (dex and user) with 0% description coverage. The tool description does not explain what 'dex' or 'user' mean, nor how they affect the returned state. This is a significant gap because the description provides no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving perpetual clearinghouse state, listing key components (positions, margin summary, withdrawable). The term 'perpetual' distinguishes it from the sibling hl_spot_clearinghouse_state. However, it lacks an explicit verb like 'get' or 'fetch', making it slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for perp state, nor does it reference sibling tools or specify conditions for use. The only clue is the word 'perpetual', which implicitly distinguishes it from spot, but this is not framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of revealing behavior. It merely states 'Open resting orders for a user' without indicating whether this is a read-only operation, what data is returned, or any limitations. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the core function. However, it is so terse that it sacrifices useful detail, though conciseness itself is appropriate for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not cover input semantics, usage distinction from similar tools, or behavioral expectations. For a tool with two parameters and several sibling tools, the minimal description leaves too many gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines 'user' and 'dex' with no descriptions, and schema description coverage is 0%. The description mentions 'for a user' but does not explain the 'dex' parameter at all. With zero schema descriptions and no parameter details in the description, the agent has essentially no semantic information beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose: to retrieve open resting orders for a user. The phrase 'Open resting orders' is somewhat ambiguous (could be read as a noun phrase), but the intent is clear. It does not differentiate from siblings like hl_frontend_open_orders, which likely serves a similar function, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as hl_frontend_open_orders or hl_order_status_by_oid. The description does not mention exclusions, prerequisites, or preferred contexts, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it provides account value and PnL history payloads but does not clarify whether it is a read-only operation, requires specific permissions, or how the user parameter affects the response. Minimal behavioral detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but the phrase 'payloads' is vague and the sentence lacks a verb. It is front-loaded with the core purpose but could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered, but the description lacks essential context such as the user parameter's role and how this tool differs from similar user-specific data tools. It is under-specified for an agent to confidently select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'user' with no description, and schema description coverage is 0%. The tool description does not mention the 'user' parameter at all, leaving the agent without any guidance on what format or value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as a portfolio performance snapshot, mentioning account value and PnL history. It distinguishes from sibling tools like order/fill history by focusing on performance metrics, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and no mention of exclusions or preferred scenarios. The description is purely descriptive without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the resource name, with no mention of read-only nature, time ranges, pagination, or any other behavioral traits. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and has no wasted words, but it's a fragment without a verb or structured information. It's concise but under-specified, making it an average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and no annotations, the description is still incomplete. It doesn't describe what the returned history includes (e.g., timestamps, amounts) and relies on an output schema that isn't visible. The description alone isn't sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'user' parameter with 0% description coverage. The description doesn't explain the parameter's format or semantics beyond implying the user is a delegator via 'delegatorRewards'. This adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Staking reward history (delegatorRewards)' clearly identifies the resource and domain, distinguishing it from sibling staking tools like summary or delegations. However, it lacks an explicit verb (e.g., 'get', 'list'), so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hl_user_staking_summary or hl_delegator_history. The description simply names the resource without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the purpose and does not clarify whether the operation is read-only, what errors might occur, or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with no unnecessary words. However, it is under-specified, so the conciseness comes at the cost of missing useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema, but the description still leaves gaps: the parameter semantics are vague, no usage guidance is given, and the behavioral scope is unclear. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameter. It loosely implies that multi_sig_user is the address, but does not specify the expected format, type of address, or how it is used, leaving important ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (multi-sig signers for an address) and is distinct from sibling tools. However, it lacks an explicit verb like 'get' or 'list', so it reads as a noun phrase rather than a full action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hl_user_role or hl_user_fees. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only offers a hint about interval format, but does not mention what data is returned, any limits, error behavior, or whether the operation is read-only. This is a significant gap for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the core concept. It wastes no words and is easy to parse. However, the structure is somewhat fragmentary ('OHLCV candles: interval like...') and could be more complete, but for conciseness it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse to be complete. It does not state whether this is a historical data endpoint, how many candles are returned, whether both time bounds are inclusive, or any constraints. For a tool with four parameters, the description provides insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any parameter, and the description only adds meaning for 'interval' by giving examples like 1m, 1h, 1d. It does not clarify the role of coin, start_time_ms, or end_time_ms. With 0% schema coverage, the description should compensate more but only marginally does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (OHLCV candles) and provides an interval format example, which makes the tool's purpose recognizable as a market data retrieval for candlestick data. However, it lacks an explicit verb like 'get' or 'fetch', so it does not fully specify the action. It distinguishes from siblings by naming a specific data type, though not as strongly as a fully explicit phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as hl_l2_book or hl_funding_history. There is no mention of suitable scenarios, prerequisites, or exclusions. The agent is left with no explicit direction beyond inferring from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only specifies the input format and implies a status query, but does not state that this is a read-only operation, mention required permissions, or describe error behavior or response contents beyond the hint '(orderStatus)'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief with no filler content, efficiently front-loading the core purpose. However, it is a fragment rather than a full sentence, which slightly reduces structural polish, though it remains appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple lookup with two parameters and an output schema exists, but the description omits the meaning of `user`, when to use this tool versus siblings, and any behavioral notes. Despite being a simple query, the lack of usage context and partial parameter coverage makes it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters with zero description coverage, and the description only adds meaning for cloid_hex by specifying its format (0x + 32 hex chars). The `user` parameter is not described at all, so the description only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving order status by client order ID (cloid), with a specific format for the ID. It distinguishes from sibling tool hl_order_status_by_oid by using client order ID rather than exchange order ID, though the lack of an explicit verb makes it slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hl_order_status_by_oid or hl_historical_orders. The distinction between client order ID and order ID is implicit in the name, but not explicitly stated, and no use-case scenarios or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It lists some entry types (deposits, transfers, liquidations) but does not describe output format, pagination, ordering, date range handling, or the boundaries of 'etc.', leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it very concise. However, the vague 'etc.' reduces informativeness while still keeping it appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and an output schema, the description is too sparse. It only offers a high-level list of entry types, omitting details about parameter meanings, expected time range, and what exactly falls under 'etc.', making it incomplete for a moderately complex query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the three parameters (user, start_time_ms, end_time_ms). Even though the names are somewhat self-explanatory, the description adds no semantic value beyond what the schema already shows, failing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool covers a non-funding ledger with entries like deposits, transfers, and liquidations. This distinguishes it from the sibling hl_user_funding_history by explicitly stating 'non-funding', though it lacks a direct verb such as 'list' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The 'non-funding' label implies it excludes funding-related updates, but there is no mention of sibling tools, exclusions, or use cases, leaving the applicability largely inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It only states the data content ('historical funding rates') and does not mention safety, pagination, time-range semantics, or any other operational characteristics. It is not misleading but is very thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core purpose and a key distinguishing attribute. It is concise, but its brevity leaves out important contextual and parameter information, though that is captured under other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, 0% schema coverage, and only a one-line description, the tool definition lacks essential context for an agent to correctly invoke it. The presence of an output schema is helpful but does not compensate for missing parameter explanations and behavioral details. The description covers the basic 'what' but not the 'how' or 'when'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the parameters 'coin', 'start_time_ms', or 'end_time_ms'. It only mentions 'perp coin' implicitly but does not clarify time semantics or the meaning of end_time_ms (default null). The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Historical funding rates for a perp coin' and adds 'not user-specific' which distinguishes it from sibling tools like hl_user_funding_history. While the verb is implicit, the resource and scope are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'not user-specific' implies this tool is for market-wide funding rates rather than user-specific ones, providing some context for when to use it. However, it does not explicitly name alternatives or provide explicit when-to-use guidance beyond that single distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not explicitly state that the operation is read-only, whether authentication is required, or any potential side effects. It does not contradict annotations, but it provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 12 words, with no filler or repetition. It front-loads the key terms 'fee tier' and 'daily volume stats' and is appropriately sized for a simple query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which may explain return values), the description is incomplete as a standalone explanation. It does not provide context on when to use the tool, what user identifier to supply, or how it fits among the many sibling user-related tools. The description is a fragment that leaves the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'user' with no description, and schema description coverage is 0%. The description does not mention this parameter or clarify what format the user identifier should take (e.g., address, username). The parameter name 'user' gives only a basic hint, and the description fails to add any additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: user fee tier and daily volume stats. It is a specific noun phrase that distinguishes it from sibling tools, none of which explicitly mention user fees. However, it lacks an explicit verb like 'retrieves' or 'lists', which would make the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it relates to alternatives such as hl_user_fills or hl_user_funding_history. The description only states what information is provided, not when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the time range. It does not mention inclusivity of endpoints, ordering, pagination, or the effect of aggregate_by_time, which is a significant transparency gap for a tool with optional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, making it concise and easy to skim. However, the parenthetical '(userFillsByTime)' is redundant and adds no value, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and a likely complex output schema, the description is too sparse. It fails to explain aggregate_by_time, which likely alters the result structure, and does not clarify the user identifier format or how results are ordered. This is a moderately complex tool, and the description is inadequate for full agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, yet it only references start_time_ms and end_time_ms without adding meaning, and it omits user and aggregate_by_time entirely. This leaves two of four parameters unexplained, and even the time parameters lack details like whether times are inclusive or what units are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as user fills bounded by start_time_ms and optional end_time_ms, making the tool's purpose evident. Though it lacks a formal action verb like 'retrieve', the noun phrase is unambiguous and sufficiently distinguishes it from sibling tools like hl_user_fills without a time window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the time-range description: use this tool when you want user fills within a specific time window. However, it does not explicitly mention alternatives or when not to use it, such as hl_user_fills for unfiltered fills, which would have strengthened the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The word 'status' implies a read-only query, and 'spotDeployState' adds internal context. However, it does not explicitly confirm non-mutating behavior or address any permissions, rate limits, or side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is appropriately sized for a simple tool, though the underspecification in other dimensions prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single-parameter schema and presence of an output schema, the description is adequate for basic invocation. However, it omits usage context, fails to contrast with sibling tools, and leaves the relationship to hl_perp_deploy_auction_status implicit, making it incomplete for an agent choosing among similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It merely repeats the parameter name 'user' without explaining format, constraints, or how it is used to fetch the status. The added '(spotDeployState)' hint provides some semantic context but does not meaningfully clarify the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (spot deploy auction status) and its scope (for user), and the 'Spot' prefix distinguishes it from the sibling hl_perp_deploy_auction_status. However, it lacks an explicit verb like 'get' or 'retrieve', reading more as a noun phrase than a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as hl_perp_deploy_auction_status or other user-state tools. There are no prerequisites, exclusions, or context clues about when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists data fields and indicates official HTTP info, implying a read operation, but does not explicitly state read-only behavior, authentication needs, rate limits, or error handling. This minimal disclosure is insufficient for full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the key data points, and contains no unnecessary words. The note about HTTP vs WS access adds contextual value, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the tool has only two parameters, but the description omits usage context, such as when to prefer this endpoint over siblings, any caveats, or behavior on missing data. It conveys the core purpose but leaves gaps in situational completeness, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It indicates 'per-user per-coin', which clarifies how the 'user' and 'coin' parameters combine to identify the data, but it does not add types, formats, or examples beyond the schema's existing names and types. The added meaning is minimal but partially fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides per-user per-coin leverage, max trade sizes, and available-to-trade data, with the identifier activeAssetData. It clearly identifies the resource and specific data fields, distinguishing it from sibling tools by its unique attributes, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no direct guidance on when to use this tool versus alternatives. It mentions 'Official HTTP Info; SDK exposes mainly via WS', which hints at access mode, but does not specify circumstances, prerequisites, or exclusions. Without naming alternatives or use cases, it fails to inform tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only implies a read-only operation via 'List', but does not mention idempotency, data freshness, authentication requirements, or any side effects. The output schema covers return values, but other behavioral aspects remain undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that gets to the point. It is concise and front-loaded, but it may be slightly under-specified given the lack of usage context. Still, for a no-parameter listing tool, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, output schema exists) and the description is minimally viable. However, it leaves gaps in usage guidance and does not explain what 'perp dex deployments' means in the broader context of sibling tools. It is adequate but could be enhanced with a brief note on when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. There is nothing for the description to add beyond what the schema already conveys, and the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a specific resource 'perp dex deployments' (with the parenthetical 'perpDexs' clarifying the object). It is clear what the tool does, but it does not explicitly distinguish itself from siblings like hl_perp_deploy_auction_status or hl_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or how it relates to other listing tools. The description is purely declarative without any context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the resource type and does not mention read-only safety, return shape, performance, or any operational characteristics. The phrase 'metadata' implies a read operation, but no explicit behavioral detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise fragment with no wasted words. It is appropriately sized for a simple metadata endpoint, though it could be slightly more informative. It is not overly verbose and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description need not explain return values. However, it lacks context on how this tool compares to similar siblings (e.g., hl_meta, hl_spot_meta_and_asset_ctxs), which is a notable gap. The description is minimally adequate but leaves the agent uncertain about which metadata endpoint to choose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100% with an empty object. There are no parameter semantics to explain, so a baseline score of 4 is appropriate; the description adds nothing about parameters because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Spot pair metadata (spotMeta)' clearly identifies the resource (spot pair metadata) and is not a tautology of the tool name. It is clear about what the tool provides, though it lacks an explicit verb and does not differentiate from the sibling hl_spot_meta_and_asset_ctxs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention that this returns all spot pairs, nor does it distinguish from similar metadata endpoints like hl_meta or hl_spot_meta_and_asset_ctxs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds the venue scope and UI reference but does not disclose data freshness, calculation methodology, whether the call is read-only, or any side effects. This is minimal transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core purpose and venue list. It is front-loaded, free of filler, and appropriately sized for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the core purpose of returning predicted funding across venues. However, it lacks any usage context, behavioral caveats, or comparison to similar tools, making it minimally complete for a simple prediction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there are no parameter semantics to explain. The description doesn't need to compensate for any missing parameter information. The baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Predicted funding across venues' with an explicit venue list (HlPerp / BinPerp / BybitPerp), making it clear that the tool returns predicted funding data. It distinguishes itself from likely historical funding tools by using 'predicted' and references the UI component for additional context. However, it lacks an explicit action verb like 'get' or 'retrieve', so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hl_funding_history or hl_user_funding_history. The description offers no exclusions, no alternative naming, and no decision criteria, leaving the agent without a basis to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description provides minimal behavioral disclosure. 'Snapshot' implies a point-in-time read-only view, but there is no mention of depth, aggregation, symbol format requirements, or any side effects. The description adds little beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter snapshot tool, the description is minimally sufficient. However, it lacks any context about how this relates to other tools (e.g., when to prefer l2_book over all_mids) and doesn't mention whether it's specific to spot or perpetual markets, which could be relevant given the sibling tools. An output schema exists but is not visible here, so the description carries extra weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'coin' parameter (0% coverage). The description adds clarity by specifying it is a coin symbol with examples 'BTC, ETH', which helps the agent understand the expected input format. However, it doesn't go further to explain casing or market context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving an L2 order book snapshot for a coin symbol, with specific examples (BTC, ETH) and implicitly distinguishes it from sibling market data tools like hl_candles and hl_all_mids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists content categories and does not indicate whether the tool is read-only, has rate limits, or any side effects. This is a significant gap for a data-access tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, and the parenthetical alias (metaAndAssetCtxs) adds useful endpoint identification without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers the core output categories (meta, mark, oracle, funding, OI) sufficiently. It could elaborate on what 'meta' encompasses or explicitly state read-only usage, but the output schema likely fills those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the baseline, the description does not need to document parameter semantics. It correctly avoids fabricating parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as perp meta plus per-asset context and specifies the exact fields (mark/oracle/funding/OI), which is specific enough to distinguish from the spot sibling. However, it lacks an explicit verb like 'fetch' or 'retrieve', so it's not maximally directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as hl_meta or hl_spot_meta_and_asset_ctxs. The description only states what the tool returns, leaving the agent to infer the appropriate use case from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only query ('order status') but does not explicitly state safety, permissions, or potential errors. The mention of 'orderStatus' adds a field-level hint, but there is no disclosure of behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no redundant words. It is front-loaded with the core action and immediately states the key identifier type, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return values need not be described. However, the description lacks context about the 'user' parameter and does not reference its sibling tool for alternative lookup by cloid, making it barely adequate for independent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'oid' is a numeric order id, but the 'user' parameter is left entirely unexplained. This partial coverage leaves ambiguity, especially since both parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieving order status) and the resource (order by numeric order id). It effectively distinguishes from the sibling tool hl_order_status_by_cloid by specifying 'numeric order id', which tells the agent exactly which identifier type to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hl_order_status_by_cloid. The description does not mention any conditions or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the raw nature, the mapping of request_type to JSON type, the merging of payload, and error behavior. It does not mention auth or rate limits, but given it's a read-only info endpoint with an output schema, the disclosure is reasonably complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: states what it is, provides a clear example, and gives a critical warning. Every sentence earns its place, and the most important qualifier ('Advanced') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an advanced raw endpoint with an output schema, the description adequately explains the tool's mechanism and constraints. It could be improved by explicitly directing users to sibling tools for standard requests, but the example and error warning make it sufficiently complete for its niche role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that request_type maps to the JSON type field and payload is a JSON object merged in, with a concrete example. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a raw POST to /info, with a specific verb and resource, and distinguishes itself from the many specific wrappers by being 'Advanced: raw POST /info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies advanced usage for documented Hyperliquid API types, with a warning about invalid types, but does not explicitly state when to use this raw tool versus the dedicated sibling hl_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are bounded by API constraints, which is a key behavioral trait. It implies a read-only operation, and while it doesn't cover auth or error cases, the disclosure is sufficient for this simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that states the purpose and provides an alternative. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an output schema present, the description covers the key behavioral constraint (API-bounded) and the alternative for time windows. It does not need to explain return values since the output schema exists. It is complete enough for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'user' parameter. The description mentions 'user fills' but does not explain the parameter's format or expected values beyond the parameter name. This adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent user fills, with 'recent' and 'user fills' defining the resource and scope. It also distinguishes itself from hl_user_fills_by_time by noting the API-bounded nature and pointing to the alternative for time-window queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use hl_user_fills_by_time for a window, providing a clear alternative. This tells the agent when to use this tool versus the sibling, even though it doesn't state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucaluca-04/Hyperliquid-MCP-Updated'
If you have feedback or need assistance with the MCP directory API, please join our Discord server