hyperd-mcp

Official

by hyperd-ai

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation5/5
Every tool has a clearly distinct purpose within its domain. For example, wallet tools split risk, anomaly, persona, and P&L without overlap. The watch subcategory has create, list, cancel with distinct roles.
Naming Consistency5/5
All tools follow the consistent pattern 'hyperd.<category>.<action>' in snake_case (e.g., hyperd.wallet.pnl, hyperd.watch.create). No mixing of styles or ambiguous verbs.
Tool Count4/5
At 23 tools, the count is on the higher side but justified by the broad scope of DeFi and wallet analytics. The tools cover balance, DEX, governance, yield, watch, and more without being bloated.
Completeness4/5
The tool set covers most major data retrieval needs for DeFi and wallet analysis. Minor gaps like NFT data or raw transaction execution exist, but for an analytical API it's nearly complete.
Average 4.2/5 across 23 of 23 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on May 12, 2026
- 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to 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

Behavior3/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 mentions the tool's cost ($0.10 in USDC), which is a behavioral trait, and implies read-only analysis (detecting anomalies). However, it does not disclose side effects, destruction, rate limits, or authorization requirements. The description is fairly transparent but lacks some behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences. First sentence states purpose, second sentence enumerates detected patterns, third sentence gives use cases and cost. Each sentence adds value without redundancy. It's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description does not explain return values. It also omits error conditions or rate limits. Given the tool's complexity (analysis, cost), the description is moderately complete but could mention expected output format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described adequately. The description adds context about the 180-day baseline and cost, but does not further enrich the meaning of parameters beyond what the schema already provides. Per guidelines, baseline is 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wallet behavioral anomaly detection.' It explains what it does (compares recent activity against a 180-day baseline, surfaces specific patterns) and provides use cases (catches compromised hot wallets, dormant whales, MEV-bot strategy shifts). This distinguishes it from siblings like hyperd.wallet.persona or hyperd.wallet.risk, which likely focus on profiling or risk scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies use for anomaly detection, but lacks guidance such as 'use this when you need to detect behavioral anomalies' or 'for overall wallet risk, use hyperd.wallet.risk instead.' Some implicit guidance exists but is not explicit.
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 full burden. It discloses a cost of $0.005 USDC, but does not clarify if the operation is read-only or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key action and cost, no wasted words, front-loaded with primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 optional parameter, no output schema), the description adequately covers what is returned and the cost, though it could briefly mention return format or units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'chain' is already described in the schema as 'Chain. Default ''base'''. The description adds no new semantic information beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current gas price + base fee + tip percentiles for fast/standard/slow inclusion', distinguishing it from sibling tools like balance.get or dex.quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for gas estimates but provides no explicit guidance on when to use or not, nor any alternatives.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions a cost of $0.10 USDC, which is useful, but does not clarify if the tool is read-only, any side effects, or rate limits, leaving some behavioral characteristics unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and each sentence adds value: purpose, outputs/protocols, usage hint and cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 fully-described params and no output schema, the description covers outputs (health factor, USD-at-risk, recommendations) and cost, but lacks detail on the return structure or format. Still, it provides sufficient context for an agent to understand the tool's purpose and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both address and chain already well-described. The description adds context by listing protocols and outputs, but for the parameters themselves it adds little beyond the schema, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses cross-protocol liquidation risk for a wallet, listing specific protocols (Aave V3, Compound v3, Spark Lend, Morpho Blue) and outputs (health factor, USD-at-risk, recommendations), distinguishing it from sibling tools like hyperd.wallet.risk or hyperd.health.check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking liquidation risk and mentions passing chain='all' for cross-chain aggregate, but does not explicitly state when to use this tool versus alternatives or any prerequisites or limitations.
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?
Discloses cost ($0.05 USDC) and output objects (score, band, volume, trend, sample casts). Lacks explicit statement on idempotency or failure behavior, but 'Get' implies read-only. Since annotations are absent, the description does a reasonable job conveying 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. First sentence covers purpose and output; second adds cost. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no output schema, the description explains output fields and cost. Missing error handling details (e.g., unknown token) but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so description does not add extra meaning beyond schema. Both parameters are adequately described in schema, and description does not elaborate further or include examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets a token's sentiment score from Farcaster discussion, specifying range (0-100) and output fields. Differentiates from siblings like hyperd.pricing.get by focusing on sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like hyperd.token.info or hyperd.pricing.get. The description implies usage for sentiment analysis but does not provide when-not-to-use context.
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?
No annotations provided, but description adds valuable behavioral context: it is LLM-summarized and costs $0.10 USDC. This helps the agent understand side effects and resource consumption. However, it doesn't mention latency or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add critical details (cost, LLM usage, output structure). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately describes the return structure. Mentions cost and LLM usage. Could be improved by noting any limits on proposal size or response time, but sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description in the schema already explains it. The tool description adds no new semantic detail about the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool summarizes DAO governance proposals from Snapshot or Tally URLs. Specifies structured output (impact analysis). Distinguishes itself from sibling tools by being governance-proposal specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states what the tool does but does not explicitly specify when to use it over alternatives or when not to use it. No guidance on prerequisites or exclusions.
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?
The tool has no annotations, so the description carries the full burden. It discloses the input, output format, cost, and signal sources, effectively conveying a read-only, safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences cover purpose, signals, output, and cost, with no filler. Essential details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return shape (score, band, findings) and cost. However, band thresholds or error handling are not covered, which would fully complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the description adds no extra meaning beyond the schema, such as valid chain values or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a token's security risk score (0-100) using GoPlus signals, differentiating it from other risk tools by its focus on a composite score with bands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the cost ($0.05), implying it's a paid tool, but does not explicitly state when to use this tool over siblings like hyperd.contract.audit or hyperd.wallet.risk.
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 discloses data sources, expected outputs (sanctioned flag, 0-100 score), and cost ($0.10). It does not mention idempotency, side effects, or latency, but the core behavioral traits are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise three sentences, front-loaded with the main purpose. Every sentence adds value: purpose, data sources/outputs, cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately explains return values (sanctioned flag + score). It also mentions cost. However, it could cover error conditions or response format in more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds no additional meaning beyond what is in the schema (e.g., no elaboration on 'deep' cross-check). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check a wallet's risk profile' with specific verb and resource. It distinguishes from siblings by detailing data sources (Chainalysis, GoPlus) and outputs (sanctioned flag + heuristic score), making it clear what this tool does uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when checking risk, but provides no explicit guidance on when to use this tool versus siblings like hyperd.wallet.anomaly or hyperd.wallet.persona. It does not state exclusions or alternatives.
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?
No annotations are present, so the description carries the full burden. It discloses the cost ($0.01) and data source (DefiLlama), implying it's a read operation. However, it does not explicitly state read-only behavior, rate limits, or potential impacts, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two sentences that front-load the core purpose. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should elaborate on return values. It mentions 'TVL, audits, chain distribution' but omits format, pagination, or error scenarios. This leaves the agent partially uninformed about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented. The description adds value by providing real-world examples and clarifying the behavior of `list=true` (returns top 50). This enriches the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves TVL, audits, and chain distribution from DefiLlama for a specific DeFi protocol. It provides examples of slugs (e.g., 'aave', 'morpho-blue') and distinguishes itself from sibling tools by explicitly mentioning the data source and type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: providing a slug for detailed info or setting list=true for top 50 protocols. This gives clear context for parameter selection, though it doesn't explicitly mention when not to use the tool or suggest alternatives among siblings.
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 full burden; it discloses cost ($0.10 USDC) and the composite analysis (GoPlus, Sourcify, DefiLlama, heuristics), giving the agent good behavioral insight into the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and key details without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, composite sources, risk score range, cost, and usage timing. Lacks details on return format beyond 'structured findings', but given no output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning beyond what the schema already provides for contract address and chain enum. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a contract security audit composing multiple sources into a single risk score, distinguishing it from sibling tools like hyperd.token.security by specifying the pre-trade and composite nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'BEFORE interacting with any unfamiliar contract' and mentions the $0.10 cost, providing clear context for when to invoke. Does not specify when not to use it.
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?
No annotations provided, so description carries full burden. It discloses cost ($0.02 USDC) and summarizes output (highest output amount and per-source quotes). It could mention that it does not execute trades, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey purpose, scope, and cost with no fluff. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a quoting tool with 6 params and no output schema, the description covers key aspects: what it does, what it returns, and cost. Lacks details on error handling or return structure, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining aggregator usage and output, but does not elaborate on individual parameters beyond what schema provides. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets the best DEX swap route across multiple aggregators and returns highest output and per-source quotes. The name and description together differentiate it from sibling tools like pricing.get or token.info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use (to obtain optimal swap quotes) but does not explicitly state when not to use or mention alternatives. However, the context is clear for a quoting tool.
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?
No annotations provided; description mentions cost ($0.01 in USDC) but does not disclose other behavioral traits such as rate limits, authentication requirements, or whether it is read-only. Partial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both highly informative: first states purpose and data, second adds value proposition and cost. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description enumerates returned data fields. For a simple parameter set (3 optional params, no enums, no nested objects), the description is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds examples and clarifies the relationship between query, contract, and chain. Explains that query accepts symbol, name, or coingecko id, and that contract is an alternative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get aggregated token metadata' and lists specific data fields (market cap, supply, contract addresses, recent volume). Distinguishes from sibling tools by noting it replaces multiple lookups from CoinGecko, Etherscan, DefiLlama.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage to replace multiple lookups but does not explicitly state when to use this tool versus siblings like hyperd.token.security or hyperd.pricing.get. No explicit when-not-to-use guidance.
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 full burden. It discloses the return type (persona, confidence, signals) and cost ($0.10). However, it does not mention rate limits, permissions, or whether it's a read-only operation. The cost disclosure adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and resource, each sentence informative. Could be slightly restructured for easier scanning, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return value (list of persona types plus confidence and supporting signals) and mentions cost. All necessary information for an agent to invoke and interpret results is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal extra meaning. It confirms address is EVM and chain default is 'base', which matches the schema. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Classify'), the resource ('wallet's persona'), and the output (list of personas plus confidence and signals). It distinguishes from sibling tools like hyperd.wallet.anomaly, hyperd.wallet.pnl, and hyperd.wallet.risk, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when behavioral classification is needed. While it doesn't explicitly state when not to use it or list alternatives, the sibling context signals suggest an agent can differentiate. A minor gap is the lack of exclusions.
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 discloses the ops fee, x402 auth path, and 404 vs 403 behavior to prevent side-channel leaks. However, it does not mention the success response or any other side effects beyond cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, fee, auth, and error behavior. Lacks description of success response or return value, but the tool is simple and no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for watch_id. The tool description adds no additional meaning beyond what the schema already provides for the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it cancels a watch owned by the user. Verb 'cancel' plus resource 'a watch you own' distinguishes it from sibling tools like create and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (cancel a watch you own) and includes context on the fee and auth path, but does not provide explicit when-not-to-use or comparisons to alternatives.
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?
No annotations exist, so description bears full burden. It discloses no side effects (free, no wallet), but doesn't detail potential error behaviors or rate limits. For a health check, this is adequate; the tool is read-only and safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Each piece of information (what it checks, cost) earns its place. Front-loaded with the action 'Check the health' and specific details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers what the tool checks and that it's free, but lacks output schema. Without one, the agent doesn't know the response format. For completeness, it could mention that it returns a health status object. Still, it's adequate for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (100% coverage trivially). Description adds value by explaining what the tool returns, which goes beyond the empty schema. It compensates well for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks health of the hyperD API, listing specific components (network, payment facilitator, backend keys, cache stats). It distinguishes from siblings like hyperd.balance.get or hyperd.pricing.get which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates it is free and requires no wallet, making it clear for diagnostic use. While it doesn't explicitly list when not to use, the context implies it's for health checks, not data retrieval. Sibling tools provide alternatives for specific queries.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool is free and requires no wallet, but does not mention error handling, rate limits, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence followed by a brief note. It is front-loaded with the action and has no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description provides all essential information: what it does, the currency, network, and accessibility. Suitable for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, baseline score is 4 when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the current price list for hyperD paid endpoints, specifying the currency (USDC) and network (Base). This distinguishes it from sibling tools like hyperd.balance.get or hyperd.dex.quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is free and requires no wallet, which implies ease of use. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions.
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 this is a read operation (get), that it costs $0.01 in USDC on Base, and that it supports multiple chains and parallel lookup. This is strong behavioral context, though it could mention potential rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, scope, and special usage. Every sentence adds essential information. No redundant or filler content. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main inputs and behavior. It lacks mention of the return format (e.g., raw amount vs. formatted) or error scenarios, but overall it provides enough context for an AI to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'token' can be a symbol or contract address, and that 'chain' accepts 'all' for parallel lookup, which is not obvious from the enum alone. This gives agents practical guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource combination: 'Get the on-chain balance for an EVM wallet address'. It immediately distinguishes from siblings by specifying EVM, multi-chain support, and ERC-20 token lookup, making the tool's purpose highly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (get balance) and notably explains the 'chain=all' parallel multi-chain option. However, it does not provide explicit when-not-to-use guidance or mention alternatives among siblings, though the usage context is clear.
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?
No annotations exist, so description carries full burden. It discloses cost-basis methods, per-token breakdown, coverage gaps, deferred gas fees, and cost. Fully transparent about limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences packed with info; first sentence immediately states purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions per-token breakdown and coverage fields. Addresses key behavioral aspects, though response format is not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds context: default time window, default method, chain restrictions, and real-world labels (IRS standard, tax-loss-harvesting). Adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes realized and unrealized P&L for a wallet over a time window, single chain, with cost-basis methods. It differentiates from siblings like hyperd.balance.get (balance) and hyperd.wallet.anomaly (anomalies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (P&L computation) and notes limitations like unpriced trades and deferred gas attribution, but does not explicitly state when not to use it vs alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool costs $0.05 in USDC, which is important for agent decision-making. It describes the filtering and ranking process without omitting critical behavioral traits. It could detail the exact output format but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the primary purpose, then details and cost. Every sentence provides unique value; no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the output as 'top picks plus projected $ yield over your duration.' While this is high-level, it covers the key result. Cost and filtering process are also explained. Could be slightly more precise on output structure, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the schema, but the description adds context: e.g., 'risk tier (low/medium/high)' matches the enum, and 'stables default false (true for low risk)' clarifies a non-obvious behavior. The description enriches the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get an opinionated DeFi yield recommendation.' It specifies the filtering criteria (risk tier, TVL, IL exposure) and ranking by APY, distinguishing it from sibling tools like balance or quote tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for yield optimization by mentioning DeFi yield recommendation and filtering. However, it does not explicitly state when to use or not use this tool versus alternatives. The sibling tools cover different domains (balance, audit, quotes), so the context is clear.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool is free and requires no wallet, which are important behavioral traits. It does not describe rate limits or other traits, but for a list endpoint this seems adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with the action. No unnecessary words. Every sentence adds value: first states the function, second states the use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers purpose, usage guidance, and behavioral context sufficiently. It is complete for a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description does not add parameter info because none is needed. Per guidelines, schema coverage is 100% and zero parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all available hyperD x402 API endpoints with prices, descriptions, and example responses. It specifies a distinct action (list) and resource (catalog), and it distinguishes itself from sibling tools which are specific endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use this to discover what tools are available before configuring a wallet.' This implies a prerequisite action. However, it does not explicitly mention when not to use it or list alternatives, but given it's a catalog, alternatives are not necessary.
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?
Without annotations, the description carries full burden. It discloses the $0.001 USDC fee, x402 auth requirement, and importantly that webhook_secret is never returned. This adds significant value, though it does not describe the return format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: purpose, cost/auth, and a critical caveat. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, the description covers purpose, cost, auth, and a key behavioral note. However, it lacks output schema details (what fields are returned for each watch), which would be helpful given no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). The description adds no parameter information because none is needed. It appropriately notes that webhook_secret is not a parameter but a return field, which is helpful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active watches owned by the wallet. The verb 'List' and resource 'active watches' are specific, and the context of wallet ownership distinguishes it from sibling tools like watch.create and watch.cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to list active watches) and provides context about the fee and auth path. However, it does not explicitly state when not to use it or mention alternatives like hyperd.watch.create, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses aggregation behavior, configurable window, return fields, exclusion of bridged USDC.e, and cost ($0.01 USDC) – all beyond what the input schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding unique value: function, usage guidance, and exclusions/cost. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return data (total spend, breakdown, projected rate, under_cap flags) and cost. Covers all important aspects for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for cap_usd, explaining what response fields are included when it's provided, which adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it aggregates USDC transfers for agent spend visibility, with a specific use case for budget enforcement before x402 calls. It distinguishes from sibling tools like balance.get or wallet.pnl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this BEFORE initiating the next paid x402 call' and notes what it does not count (bridged USDC.e). However, no explicit alternatives or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses parallelism (up to 10 sub-calls, concurrency cap 4), pricing ($0.20 USDC), best-effort execution, and refund policy (no refunds in v1.0). These traits go well 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 clear, front-loaded sentences. No extraneous content; every sentence adds critical information about purpose, behavior, pricing, and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers usage and behavioral details well, it omits the structure of the return envelope. Since there is no output schema, the agent lacks information about what the response will look like, which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters are used in practice (parallelism, pricing, error handling), but does not introduce new parameter constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool bundles multiple paid GET calls into one x402 settlement. This is a specific verb+resource combination and clearly distinguishes it from sibling tools like hyperd.balance.get or hyperd.wallet.balance which are individual calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this tool when needing 3+ paid calls, and provides a cost comparison (fixed $0.20 vs. à la carte total > $0.24). This gives clear when-to-use guidance, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description covers key behaviors: webhook_secret shown once, alerts HMAC-SHA256 signed, prepayment $3 USDC, duration defaults, and supported protocols. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: states purpose, return values, behavioral notes, pricing, duration, and protocol support in a few sentences. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (watch_id, webhook_secret) and covers pricing, duration, protocols, and limitations. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context like 'store secret once', prepayment, and duration defaults which are not in schema. Provides moderate additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it subscribes to a continuous watch on a wallet/position, specifies return of watch_id and webhook_secret, and mentions liquidation focus. Differentiates from siblings like watch.cancel and watch.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (liquidation watches), notes v1.0 limitations and multi-target reserved for v1.1 Pro tier. Could explicitly mention when not to use, but is clear on context.
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:

[![hyperd-mcp MCP server](https://glama.ai/mcp/servers/hyperd-ai/hyperd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hyperd-ai/hyperd-mcp)

Score Badge

Copy to your README.md:

[![hyperd-mcp MCP server](https://glama.ai/mcp/servers/hyperd-ai/hyperd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hyperd-ai/hyperd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/hyperd-ai/hyperd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server