DeFi vault judgment for agents: 16-factor Atlas Score, route survival, blowup alerts. Read-only.
Scored across 7 tools
Each tool targets a distinct job: discovery (find_vaults), single-vault lookup (get_vault_score), score breakdown (explain_vault_score), multi-vault comparison (compare_vaults), index metadata (get_coverage), alerts (list_open_alerts), and deposit route screening (check_route_survival). The descriptions explicitly state when to use each (e.g. find_vaults 'start here when you do not already have a vault address', check_route_survival 'call this BEFORE moving money'), removing overlap between get_vault_score and explain_vault_score.
All names follow a consistent verb_noun snake_case pattern: check_route_survival, compare_vaults, explain_vault_score, find_vaults, get_coverage, get_vault_score, list_open_alerts. Verbs are distinct and meaningful, and the resource noun is always clear.
Seven tools is well-scoped for a read-only vault scoring and route-screening index. Every tool covers a distinct workflow stage (discover, score, explain, compare, screen, monitor, coverage), with no filler.
The surface covers the full read-only lifecycle: discovery, per-vault scoring, score explanation, comparison, coverage metadata, alerts, and deposit-route safety. Minor gaps remain—no historical score time-series and no bridging/cross-chain route check (explicitly out of scope), but agents can work around these.
Can a deposit into this vault be exited at size, measured today? Returns the daily round-trip route screen (USDC -> position -> USDC): verdict, USD in/out, fraction retained, the path probed, and when. blocking:true means refuse the deposit (NO_ROUTE, DANGEROUS, UNPRICEABLE). reasonClass says why: protocol_refused (the protocol's own router refuses, the vault is dead) vs no_aggregator_quote (no same-chain swap into the underlying, common for LP vaults; redeeming by hand may still work). The probe is SAME-CHAIN only: USDC on the vault's own chain. It says nothing about bridging in from elsewhere. Route tracking covers EVM chains only: a Solana vault returns tracked:false (not tracked, neither a pass nor a failure). A vault that was never screened returns screened:false with no verdict — never a fabricated one. Call this BEFORE moving money. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Vault contract address (0x…) | |
| chainId | Yes | EVM chain id of the vault |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations: it decodes blocking:true into the exact refusal conditions (NO_ROUTE, DANGEROUS, UNPRICEABLE), enumerates reasonClass values with what each implies, and discloses edge-case return states (tracked:false for Solana, screened:false for never-screened vaults, explicitly 'never a fabricated' verdict). The annotations only cover safety; the description supplies the decision semantics.
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?
Front-loads the core question and the return shape before moving into interpretation, and nearly every sentence adds a distinct fact (blocking semantics, reasonClass, chain scope). It is dense and runs long within one block, but no sentence is filler.
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?
With no output schema, the description takes on the return-value burden and fully discharges it: it names the fields (verdict, USD in/out, fraction retained, path probed, when) and explains the two boolean flags that gate action. Nothing needed to interpret or act on the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with only two self-evident parameters (address, chainId), so the schema already carries the parameter burden. The description adds no format or syntax detail beyond what the schema states, which lands at the baseline.
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?
Opens with a precise framing question ('Can a deposit into this vault be exited at size, measured today?') and states exactly what is returned: a daily round-trip route screen USDC -> position -> USDC. This is a specific verb+resource that no sibling (compare_vaults, get_vault_score, etc.) covers, so an agent can differentiate it without opening the schema.
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?
Explicit invocation timing is given ('Call this BEFORE moving money'), which is strong actionable guidance. It also states scope limits (same-chain, EVM-only) that implicitly tell the agent when not to rely on it, but it never names a sibling alternative for the bridging or Solana cases, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side Atlas Scores for 2-8 vaults: composite, label, four pillars, live APY/TVL, data quality, yieldQuality and exitSafety, with a ranking by composite. Unscored vaults come back found:false rather than silently dropped. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| vaults | Yes | 2-8 vaults to compare, any mix of chains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuine context beyond that: unscored vaults return found:false rather than being silently dropped, which tells the agent how to interpret partial results.
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?
One dense sentence front-loads the core purpose and the return contents, with no filler. The field enumeration is long but each item earns its place by telling the agent what to expect back.
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?
With no output schema, the description carries the burden of describing returns and does so thoroughly, including the found:false edge case and the ranking. The only gap is the absence of when-to-use guidance relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single array parameter is fully documented (chainId, address, min/maxItems). The description only restates the 2-8 count already enforced by the schema, adding no format or addressing detail beyond it. Baseline 3 applies.
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?
States a specific verb and resource ('Side-by-side Atlas Scores for 2-8 vaults') and enumerates exactly what is returned (composite, label, four pillars, APY/TVL, data quality, yieldQuality, exitSafety, ranking). It is clearly distinguishable from the single-vault siblings get_vault_score and explain_vault_score.
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 2-8 vault bound and the comparison framing imply the usage context (multi-vault side-by-side rather than single lookup), but it never explicitly says when to use this instead of get_vault_score, find_vaults, or explain_vault_score. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Why a vault has its Atlas Score: all 16 factors (15 additive across four pillars + the multiplicative exploit-history modifier), each with sub-score (0-100), weight, raw input and a plain-English label, grouped by pillar, plus the three weakest factors. Exactly what the engine computed at scoredAt, not a recomputation. Returns found:false when unscored. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Vault contract address (0x…); case-insensitive | |
| chainId | Yes | EVM chain id, e.g. 1 (Ethereum), 8453 (Base), 42161 (Arbitrum) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial behavioral context beyond them: the 16-factor structure, the multiplicative exploit-history modifier, the three weakest factors, the found:false unscored case, and the explicit non-recomputation guarantee.
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?
Front-loaded with the core 'Why…' framing, and the dense factor inventory is informative rather than filler. Slightly clause-heavy, but no sentence is wasted.
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?
With no output schema, the description compensates by spelling out the return shape (factors, sub-scores, weights, weakest three) and the unscored fallback. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (address, chainId) are fully documented in the schema. The description adds no syntax or format detail for either parameter, so the baseline 3 applies.
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?
States a specific verb ('explain') and resource ('vault score'), and details exactly what is returned: all 16 factors grouped by pillar with sub-score, weight, raw input and label. An agent can distinguish this from get_vault_score (the score itself) without opening either schema.
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?
Gives useful context ('exactly what the engine computed at scoredAt, not a recomputation' and 'found:false when unscored'), which implies when the breakdown is authoritative, but never names an alternative tool or states when to prefer get_vault_score or compare_vaults. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here when you do not already have a vault address. Answers "which vaults for this asset on this chain?": returns a short ranked list (default 5, max 10) of scored vaults with composite, label, live APY/TVL, risk flags (thin_tvl, apy_outlier, ...), whether a deposit can reach it (routable), and a citable page URL. It also returns what the filters REMOVED: counts per filter, the best-ranked dropped vaults with reasons, near-miss asset symbols, and whether more matched than were returned. Vaults with no deposit route and rows scored on fallback data are excluded. Ranked by the chosen metric, a ranking and not a recommendation. A flag is a caution, not a verdict, and no flag does not mean safe. Take a chosen vaultId/address to check_route_survival before any deposit. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Underlying asset symbol, or a list of up to 10, e.g. USDC or ["USDC","USDT0"]. Exact match: USDC does not include syrupUSDC (similarAssets lists near misses) | |
| chain | No | Chain name (base, ethereum, arbitrum, optimism, bnb, solana) or EVM chain id | |
| limit | No | Rows to return, default 5, max 10 | |
| minApy | No | Minimum live APY in percentage points, e.g. 10 for 10% | |
| sortBy | No | Rank by this, descending. Default composite | |
| minScore | No | Minimum Atlas composite (0-100) | |
| minTvlUsd | No | Minimum live TVL in USD | |
| protocolId | No | Protocol slug, e.g. morpho, aave-v3, pendle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description then adds uncommon behavioral detail: which rows are excluded (no deposit route, fallback-scored), that filters' removals are reported with counts and reasons, and that flags are cautions rather than verdicts. It stops short of explaining pagination or performance but is well above the annotation bar.
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?
Front-loaded with the routing guidance, then return shape, then caveats — a sensible order. It is dense and somewhat long, with a few clauses ('a ranking and not a recommendation', 'a flag is a caution, not a verdict') that verge on repetition, but nearly every sentence conveys actionable constraint.
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?
No output schema exists, so the description carries the return-value burden and does so thoroughly: ranked list, score/label/APY/TVL, risk flags, routability, citable URL, plus dropped-vault accounting. An agent can call this and interpret the result without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds meaning the schema lacks: that filters also report what they REMOVED, that asset matching is exact with near-miss symbols surfaced, and the 5/10 result bounds in context. It enriches how the parameters behave rather than restating them.
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?
Opens with a specific verb+resource framing — 'Start here when you do not already have a vault address' — and states the exact question it answers ('which vaults for this asset on this chain?'). It is clearly distinguishable from siblings like compare_vaults, get_vault_score and check_route_survival.
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?
Gives an explicit entry condition ('when you do not already have a vault address') and an explicit hand-off ('Take a chosen vaultId/address to check_route_survival before any deposit'). The when-to-use and the next-step alternative are both stated, nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the Atlas Score Index covers right now: number of scored vaults, total TVL, composite score spread, and counts by protocol and chain. Use it before asking about a vault to learn whether a protocol or chain is in the scored universe at all. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Restrict to one chain id | |
| protocolId | No | Restrict to one protocol id, e.g. morpho, aave-v3, pendle, beefy, yearn-v3, euler |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the trailing 'Read-only' is redundant. The description does add real value not covered elsewhere: because there is no output schema, describing the returned payload (vault counts, TVL, score spread, per-protocol/chain counts) tells the agent what to expect from the response.
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?
Three tight sentences with zero filler: payload contents, usage timing, and safety profile. The most decision-relevant information (what it covers) is front-loaded, and nothing is repeated unnecessarily.
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?
With no output schema, the description correctly compensates by enumerating the returned metrics, and it supplies the usage context an agent needs for a zero-required-parameter read tool. Minor omissions (ordering, result size, whether counts are point-in-time snapshots) keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (chainId, protocolId) are already fully documented in the schema, including the protocol id examples. The phrase 'counts by protocol and chain' hints that the filters scope the aggregation, but adds no syntax or semantic detail beyond the schema. Baseline 3 applies.
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?
States a specific verb+resource (what the Atlas Score Index covers) and enumerates the exact payload contents: scored vault count, total TVL, composite score spread, and breakdowns by protocol and chain. This is clearly distinguishable from siblings like get_vault_score or find_vaults, which operate on individual vaults rather than the index universe.
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?
Gives explicit sequencing guidance: 'Use it before asking about a vault to learn whether a protocol or chain is in the scored universe at all.' That tells the agent when to reach for this tool relative to vault-level siblings. It stops short of naming a specific alternative tool or stating exclusions, so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest Atlas Score for one vault: composite (0-100), label, the four pillar scores (yield, safety, liquidity, sustainability), live APY/TVL, data quality and the scoring timestamp. Returns found:false when the vault is not in the scored universe. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Vault contract address (0x…); case-insensitive | |
| chainId | Yes | EVM chain id, e.g. 1 (Ethereum), 8453 (Base), 42161 (Arbitrum) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world, so 'Read-only' adds nothing. The description does add real behavioral context beyond them: the found:false response when a vault is outside the scored universe, and the fact that APY/TVL are live values. It stops short of describing staleness or caching semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the payload contents front-loaded and the edge case (found:false) placed immediately after. No filler, no redundancy with the name or annotations.
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?
With no output schema, the description usefully enumerates the returned fields and the not-found case, which is what an agent needs to interpret results. It omits error handling for malformed chainId/address and any freshness guarantees on the 'live' APY/TVL values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both address (case-insensitive 0x…) and chainId (with chain examples) are fully documented in the schema. The description adds no syntax or format detail beyond what is already there, so the baseline 3 applies.
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?
States a specific verb and resource ('Latest Atlas Score for one vault') and enumerates exactly what it returns: composite 0-100, label, four pillar scores, live APY/TVL, data quality, timestamp. This is enough to tell it apart from compare_vaults and find_vaults without opening a schema.
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?
Usage is only implied — 'for one vault' signals the single-vault lookup case and implicitly contrasts with compare_vaults, but it never names an alternative or says when to prefer this over explain_vault_score, which likely exists for the same data. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open blowup-monitor alerts from the published daily snapshot: score-band exits, fast composite breaks, yield collapse, TVL flight, exploit flags, delistings. Each event carries score before/after and pillar deltas. Published once a day; the date field says when. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Restrict to one chain id | |
| minSeverity | No | Only alerts at or above this severity (1 = lowest) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly focuses on data-freshness behavior: alerts come from a snapshot published once per day, not live state, and each event carries score before/after plus pillar deltas. It stops short of pagination, retention across days, or whether an alert can disappear between snapshots.
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?
Three tight sentences with the resource and its categories front-loaded, followed by return content and then cadence. The long category list is dense but each item earns its place by telling the agent what kinds of events to expect.
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?
With no output schema, the description carries the return-value burden and does so reasonably by naming the per-event fields (score before/after, pillar deltas). The daily-snapshot cadence is the key operational caveat. Remaining gaps are minor: no pagination/limit behavior and no indication of typical volume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both chainId and minSeverity, so the schema already carries the semantics and the baseline of 3 applies. The description adds no filtering guidance and its mention of 'the date field says when' refers to returned data rather than either declared parameter, so it does not enrich parameter meaning.
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?
Specific verb (list) plus resource (open blowup-monitor alerts) and an enumeration of the alert categories it returns (score-band exits, composite breaks, yield collapse, TVL flight, exploit flags, delistings). This makes it unmistakable against siblings like get_vault_score or check_route_survival, which are per-vault tools.
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?
Usage is implied by the content, but there is no explicit when-to-use statement, no when-not-to-use, and no mention of any sibling tool as an alternative. The daily-cadence note hints at freshness expectations but does not tell the agent when this tool is the right pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_vaults5 fields changedInput schema / properties / asset / anyOfAdded value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / asset / descriptionPrevious value: -"Underlying asset symbol, e.g. USDC, WETH, USDT"New value: +"Underlying asset symbol, or a list of up to 10, e.g. USDC or [\"USDC\",\"USDT0\"]. Exact match: USDC does not include syrupUSDC (similarAssets lists near misses)"Input schema / properties / asset / minLengthRemoved value: -1Input schema / properties / asset / typeRemoved value: -"string"Input schema / properties / minApyAdded value: +{
+ "description": "Minimum live APY in percentage points, e.g. 10 for 10%",
+ "minimum": 0,
+ "type": "number"
+}check_route_survivalcompare_vaultsexplain_vault_scorefind_vaultsget_coverageget_vault_scorelist_open_alertsRead-only Hyperliquid vault search, risk, drawdown, rankings, TVL, alerts, and comparisons.
Search 700+ DeFi vaults, compare risk scores, analyze protocols. No API key needed.
Read-only smart-contract security intelligence for autonomous agents.
0-100 risk score for stablecoin yield venues (Aave, Morpho, Ondo, Ethena). Pay per call via x402.
Add one secure layer between your agents and this server.
