healthLiveness and capability check for yieldhunter (yieldhunter.eth).
Returns service status, schemaVersion, scoringVersion, feature flags, and the list of available tools.
Use this first to verify connectivity. Research estimates only — non-custodial; never holds keys or executes transactions.
Copy-paste path starts here, then list_yields. Example input: {}
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context: it states the tool is non-custodial, never holds keys or executes transactions, and that research estimates are provided. This goes beyond annotations by clarifying the tool's operational nature and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It includes a copy-paste path and example input, which are useful but slightly verbose. The structure is clear: purpose, return values, usage instruction, and example. It earns its sentences without excessive fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It covers what the tool returns, how to use it, and its safety profile. The only minor gap is not detailing the exact structure of the response, but since there's no output schema, the description's mention of the return fields is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description doesn't need to explain parameters, but it does mention an example input '{}' which confirms the no-parameter expectation. Since there are no parameters to document, a baseline of 4 is appropriate as the description handles the no-parameter case clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a liveness and capability check for yieldhunter, returning service status, schemaVersion, scoringVersion, feature flags, and available tools. It distinguishes itself from siblings by being the first tool to call for connectivity verification, which is a specific use case not covered by other tools like list_yields or score_opportunity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool first to verify connectivity, and provides a copy-paste path that starts here before list_yields. This gives clear when-to-use guidance. However, it doesn't explicitly state when not to use it or mention alternatives, but the context of being a health check is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools are mostly distinct: list_yields for ranking, score_opportunity for detailed scoring of one, explain_score for explaining a score, compare_opportunities for side-by-side comparison, get_protocol_risk for protocol-level risk, and health for connectivity. However, score_opportunity and explain_score have overlapping purposes (both return factor scores and rationale), which could cause some confusion, though they serve different output formats.
The naming pattern is mostly consistent using verb_noun (e.g., list_yields, get_protocol_risk, explain_score, compare_opportunities, score_opportunity). One deviation: 'health' is a single-word name that breaks the verb_noun pattern, but it's a minor deviation and still readable.
With 6 tools, this is well-scoped for a yield research server. Each tool has a distinct role: listing, scoring, explaining, comparing, protocol risk, and health check. The count feels appropriate for the domain, not overly heavy or thin.
The server covers core research needs: listing opportunities, detailed scoring, explanation, comparison, protocol risk, and health check. However, there are some minor gaps: no direct way to filter by specific pool ID without first listing, no tool to get historical trends or detailed market info beyond the scoring. But the domain is research-only non-custodial, so a full CRUD lifecycle isn't expected; still, a tool to fetch specific opportunity details without scoring could be missing.