Sourced, scored comparisons of crypto exchanges, wallets, savings accounts and brokerages.
Scored across 11 tools
Tools generally separate cleanly into discovery, platform detail, comparison, calculators, and market-data workflows. A few boundaries are soft: check_platform_safety overlaps with get_platform, and get_verdict could be confused with compare_platforms, though the descriptions help distinguish them.
All tools use snake_case with a predictable verb_noun pattern such as get_platform, compare_platforms, and search_platforms. Longer names like calculate_savings_interest remain readable and consistent with the convention.
Eleven tools are well-scoped for a read-only finance comparison server, with each tool covering a distinct workflow. The set is neither thin nor bloated.
The surface covers category discovery, search, platform detail, comparison, safety, fee/interest estimation, published verdicts, and supplemental market data. Minor gaps exist, such as no explicit wallet-specific detail tool or standalone rates listing, but agents can work around them.
Project interest on a balance over N months at every high-yield savings account VaultRubric tracks, using sourced standard APYs (promos shown separately), minimum balances and monthly fees. Estimates, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Holding period in months (1-120); default 12 | |
| balance | Yes | Deposit balance in USD, e.g. 10000 |
| Name | Required | Description |
|---|---|---|
| page | Yes | Shareable calculator URL for this result |
| method | No | |
| months | No | |
| balance | No | |
| license | No | Data license / reuse terms |
| results | Yes | |
| disclaimer | No | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description nonetheless adds real behavioral context: standard APYs are sourced, promos are shown separately, and minimum balances and monthly fees are factored in, plus an 'estimates, not advice' disclaimer. It doesn't discuss result ordering or per-account detail, keeping it short of a 5.
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 tight sentences with the computational scope front-loaded and the methodology and disclaimer trailing. Every clause carries information, though the parenthetical '(promos shown separately)' and disclaimer make it slightly denser than strictly necessary.
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 an output schema present, return values need not be described, and annotations carry the safety profile. The description supplies methodology and a disclaimer, leaving only minor gaps such as how many accounts are returned and any ordering, which the output schema presumably covers.
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 explicit ranges (1-120 months, 0-10M balance), so the schema already documents semantics fully. The description mentions the N-month horizon and a balance but adds no format or interpretation beyond the schema, matching the baseline 3.
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 ('Project interest') and resource ('a balance over N months'), plus the scope ('at every high-yield savings account VaultRubric tracks'). This clearly separates it from siblings like estimate_fees and compare_platforms without the agent opening any 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 implied by the description's scope (projecting savings interest across tracked accounts), but there is no explicit when-to-use, when-not-to-use, or named alternative vs estimate_fees or compare_platforms. The 'Estimates, not advice' caveat hints at positioning but doesn't route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safety record for a platform: customer-funds hacks, incidents, regulatory actions and security score, with sources and the safety page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform name, e.g. 'Coinbase', 'Ledger', 'Robinhood' |
| Name | Required | Description |
|---|---|---|
| answer | Yes | One-paragraph direct answer |
| caveat | No | |
| license | No | Data license / reuse terms |
| category | No | |
| platform | Yes | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
| safety_page | No | |
| security_criterion | No | |
| customer_funds_hack | No | |
| related_comparisons | No | |
| incidents_and_regulatory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the nature of the returned content but no operational behaviors (rate limits, caching, auth). No contradiction with the annotations.
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 compact sentence that front-loads the resource and then lists contents; no filler or repetition. It is a noun fragment rather than a sentence, but every clause earns its place.
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 an output schema present, the description need not explain return values, and annotations cover the safety profile; the field enumeration gives enough for a one-parameter read tool to be called correctly. The missing piece is usage context versus get_platform and compare_platforms.
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?
There is a single parameter with 100% schema description coverage ('Platform name, e.g. Coinbase, Ledger, Robinhood'). The description adds nothing about the platform parameter beyond the schema, so the baseline 3 for high-coverage schemas 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?
The description names a specific resource — the safety record for a platform — and enumerates its contents (hacks, incidents, regulatory actions, security score, sources, safety page URL), which distinguishes it from the generic get_platform sibling. It lacks an explicit verb and never names the sibling it differs from, so it falls short of a 5.
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?
There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as get_platform or compare_platforms. The agent must infer usage entirely from the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-6 platforms in one category with optional criterion weights. Applies VaultRubric's 75% coverage gate, 60% hack cap and too-close-to-call (<3 points) rules.
| Name | Required | Description | Default |
|---|---|---|---|
| weights | No | Optional importance 0-10 per criterion key (keys from get_platform criteria, e.g. {'fees': 10, 'security': 8}); unspecified criteria default to 5 | |
| platforms | Yes | 2-6 platform names from the same category, e.g. ['Coinbase', 'Kraken'] |
| Name | Required | Description |
|---|---|---|
| note | No | |
| page | Yes | Most relevant VaultRubric page URL |
| rules | No | |
| winner | No | Winning platform, or null if too close / none eligible |
| license | No | Data license / reuse terms |
| results | Yes | |
| weights | No | Weights applied (object) or 'equal (5 each)' |
| category | Yes | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
| too_close_to_call | No |
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), and the description adds genuine behavioral rules beyond them: a 75% coverage gate, a 60% hack cap, and too-close-to-call handling below 3 points. These disclose that results may be gated or flagged, though the description doesn't state what the agent sees when a gate trips.
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 tightly packed sentences with the scope and constraints front-loaded and no filler. It is slightly jargon-dense ('60% hack cap') in a way that assumes familiarity, but nothing 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?
An output schema exists, so return shape need not be explained, and the annotations carry the safety profile. The description covers scope, weighting, and the rubric gates, leaving only the practical consequence of a failed gate unstated — a minor gap for a read-only comparison tool with rich structured fields.
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 the weights map (0-10, default 5, keyed by get_platform criteria) and the platforms array are already fully documented in the schema. The description only restates 'optional criterion weights' and the 2-6 count, adding no syntax or meaning beyond the structured fields.
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 ('Compare platforms') plus scope constraints ('2-6 platforms in one category') that separate it from single-platform siblings like get_platform. It does not explicitly name or route against alternatives such as get_verdict, so it falls just short of full sibling differentiation.
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-6 same-category constraint and optional weights imply when the tool is appropriate, but there is no explicit 'use this when...' statement and no named alternative for cases like single-platform lookups or verdicts. Usage is inferable but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate annual cost at every brokerage or crypto exchange VaultRubric tracks from sourced fees (commissions, options per-contract, transfer-out; exchange taker fees). Unknown fees are flagged, never assumed.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | 'brokerage' or 'exchange' | |
| avg_trade_size | No | Average trade size in USD (used for exchange percentage fees); default 1000 | |
| trades_per_month | No | Number of trades per month; default 4 | |
| transfers_per_year | No | Full account transfers out per year; default 0 | |
| options_contracts_per_month | No | Options contracts per month (brokerages); default 0 |
| Name | Required | Description |
|---|---|---|
| page | Yes | Shareable calculator URL for this result |
| inputs | No | |
| method | No | |
| license | No | Data license / reuse terms |
| results | Yes | |
| category | No | |
| disclaimer | No | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
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 bar is lower. The description nonetheless adds a genuinely useful trait beyond them: 'Unknown fees are flagged, never assumed,' telling the agent how missing data is surfaced rather than silently imputed.
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 tightly packed sentences that front-load the purpose before the data-quality caveat. The parenthetical fee list is dense but each item maps to a real cost dimension, so little 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?
An output schema exists, so return values need not be described, and the schema documents all five parameters with defaults. The description covers scope, cost components, and unknown-fee handling; only the relative role of inputs versus alternatives is left implicit.
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, and the description adds a little on top by tying parameters to the fee model ('options per-contract', 'transfer-out', 'exchange taker fees'). It stops short of explaining how inputs like trades_per_month or transfers_per_year combine, leaving that to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Estimate') plus resource ('annual cost') and an explicit scope ('every brokerage or crypto exchange VaultRubric tracks'), with the cost model components enumerated. This is clearly distinguishable from siblings like compare_platforms or get_verdict that answer different questions.
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?
Implied usage is clear (cost projection to support a platform decision), but there is no explicit when-to-use, when-not-to-use, or named alternative such as compare_platforms. The agent must infer the routing from the scope sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delayed price and latest headlines (Google News, with source URLs) for a stock ticker or a top-250 crypto asset. Headlines are quoted as reported; no predictions.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | 'stock' (default) or 'crypto' | |
| asset | Yes | Stock ticker (e.g. 'AAPL') or coin id/symbol/name (e.g. 'bitcoin', 'ETH') |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| news | Yes | |
| page | No | |
| asset | Yes | |
| quote | No | |
| license | No | Data license / reuse terms |
| disclaimer | No | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive behavior, and the description still adds real context: 'Delayed' flags data latency, 'Google News, with source URLs' identifies the external source and provenance, and 'quoted as reported; no predictions' sets editorial expectations. That goes meaningfully beyond the structured hints.
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 tight sentences, front-loaded with what the tool returns and where the data comes from. The trailing 'no predictions' clause earns its place by preempting a likely agent misreading of the output.
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 an output schema present and annotations covering the safety profile, the description only needs to frame purpose, source and scope, which it does. The one gap is the absence of usage guidance relative to alternatives, but for a two-parameter read tool this is minor.
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 the baseline is 3, but the description adds a constraint absent from the schema: crypto support is limited to 'top-250' assets. It also ties the asset/kind parameters to stock tickers vs crypto identifiers, giving useful scope beyond the schema text.
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 resource and content set: 'Delayed price and latest headlines ... for a stock ticker or a top-250 crypto asset.' An agent immediately knows it returns market data plus news, and it is clearly distinguishable from the fee/savings/platform siblings.
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 scope is stated ('stock ticker or a top-250 crypto asset'), which implies when it applies, but there is no explicit when-to-use/when-not guidance or reference to any alternative sibling. Usage must be inferred from the asset-scope phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upcoming and recently priced IPOs (Nasdaq IPO calendar) with price ranges, exchanges and first-day results, plus the latest SEC EDGAR S-1/F-1 filings.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | 'all' (default), 'upcoming', 'recent_priced', 'recently_filed' or 'sec_filings' |
| Name | Required | Description |
|---|---|---|
| page | No | |
| as_of | Yes | |
| license | No | Data license / reuse terms |
| sources | No | |
| upcoming | No | |
| disclaimer | No | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
| sec_filings | No | |
| recent_priced | No | |
| recently_filed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real context beyond that: it names the upstream sources (Nasdaq IPO calendar, SEC EDGAR) and the kinds of records returned, though it says nothing about freshness windows or update cadence for 'recently' items.
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?
A single front-loaded sentence that packs the data sources and covered fields with no filler or redundancy. Every clause earns its place.
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?
An output schema exists, so return-value detail is not required, and annotations cover the safety profile. The description is nearly complete for a zero-required-param read tool, with only minor gaps around how 'recent' items are defined and how sections affect output.
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 the single 'section' parameter is fully documented with its enum values in the schema, so the baseline is 3. The description's mention of upcoming/priced/filings content loosely mirrors those options but adds no syntax or default-selection guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (IPO calendar) with concrete contents: upcoming and recently priced IPOs, price ranges, exchanges, first-day results, plus SEC EDGAR S-1/F-1 filings. This is unambiguous and clearly distinct from siblings like get_market_movers or compare_platforms, which cover unrelated domains.
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 implies coverage of several data categories (upcoming, priced, filings), which maps loosely to the section options, but it never states when to pick this tool over an alternative or which section to choose for a given intent. Usage is only inferable from the enum values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top crypto (24h, CoinGecko) or US stock (delayed, Yahoo/Nasdaq) gainers and losers, each with the latest sourced headline that names it. News and data only, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per list, 1-8 (default 8) | |
| market | Yes | 'crypto' or 'stocks' | |
| direction | No | 'gainers', 'losers' or 'both' (default) |
| Name | Required | Description |
|---|---|---|
| page | No | |
| as_of | Yes | |
| delay | No | |
| losers | No | |
| market | Yes | |
| source | No | |
| gainers | No | |
| license | No | Data license / reuse terms |
| disclaimer | No | |
| source_url | No | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description is free to add the traits that matter: the 24h window for crypto, the delayed nature of stock quotes, the upstream sources, and the 'news and data only, not advice' scope limit. Minor gap: nothing about ranking methodology or how stale a headline can be.
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?
A single dense opening sentence front-loads what the tool returns, followed by a short scope disclaimer that earns its place for a financial tool. No filler, no restatement of the title.
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 an output schema present, the description needn't explain return shape, and it correctly covers the two markets, the direction options, and the sourcing. It stops short of explaining feed cadence or how 'movers' are ranked, a small gap for a data-discovery tool.
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 all three parameters (limit, market, direction) are already documented with enums and defaults, making 3 the baseline. The description adds only context about the market values (crypto = 24h CoinGecko, stocks = delayed US), not new syntax or constraints.
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 outcome (top gainers/losers) plus the data sources (CoinGecko 24h crypto, delayed Yahoo/Nasdaq stocks) and the enrichment (a sourced headline naming each mover). An agent can distinguish it from get_asset_news, which returns headlines for a specified asset rather than ranked movers.
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 description: use it for a broad market-movement snapshot rather than per-asset news. However, it never names get_asset_news or any sibling as an alternative, nor states when this tool should not be used, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full sourced record for one platform: per-criterion scores with basis and source URLs, incidents, regulatory actions, as-of dates, and related page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Platform name as listed by search_platforms, e.g. 'Coinbase', 'Trezor Safe 5', 'Fidelity' |
| Name | Required | Description |
|---|---|---|
| note | No | |
| license | No | Data license / reuse terms |
| platform | Yes | Full platform record |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
| safety_page | No | URL of the 'Is X safe?' page, if any |
| related_comparisons | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds content-level context (sourced basis, as-of dates implying data freshness), but says nothing about behavior such as unknown-name handling or rate limits, and much of it restates return payload that the output schema already defines.
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?
A single front-loaded sentence that leads with the resource and scope, then enumerates payload contents. Slightly list-heavy, but every element is a distinct, useful field category rather than 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?
For a one-parameter read tool with full annotation coverage and an output schema, the description covers what the record contains and that it is sourced, so an agent has enough to invoke it correctly. The remaining gap is routing guidance against sibling tools, which is not strictly required here.
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?
Only one parameter and schema description coverage is 100%, so the schema fully documents 'name' including its naming convention. The description adds no syntax or format detail beyond that, so the baseline of 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 ('Full sourced record for one platform') and enumerates the payload: per-criterion scores, incidents, regulatory actions, as-of dates, page URLs. An agent can tell this is the detail-fetch counterpart to a list/search, though no sibling is named explicitly.
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 platform' suggests a single-record lookup following a listing, and the sibling search_platforms is referenced only inside the parameter schema, not the description. No when-not or explicit alternative (search_platforms, check_platform_safety, compare_platforms) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the published verdict (direct answer, key facts, as-of date, URL) for a VaultRubric comparison page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Comparison page slug, e.g. 'coinbase-vs-kraken', 'best-hardware-wallet', 'is-coinbase-safe' |
| Name | Required | Description |
|---|---|---|
| license | No | Data license / reuse terms |
| verdict | Yes | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the notion that the verdict is 'published' (i.e. authoritative/precomputed) but no details on staleness beyond the as-of field, failures for unknown slugs, or rate limits.
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?
A single, front-loaded sentence with no filler; the parenthetical enumerates the returned fields compactly. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one required param) with a full output schema and complete annotations, so return values and safety behavior are covered elsewhere. The only gap is the absence of routing guidance relative to sibling verdict/safety/comparison tools, which is minor.
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?
With a single parameter at 100% schema description coverage, the schema already documents the slug fully, including concrete examples. The description adds no syntax, format, or validation nuance beyond what the schema provides, so the baseline of 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 ('Get') and resource ('the published verdict') and names the fields returned (direct answer, key facts, as-of date, URL). It hints at the domain object ('VaultRubric comparison page') but does not explicitly contrast itself with close siblings like compare_platforms, check_platform_safety, or get_platform.
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?
There is no statement of when to use this tool versus alternatives such as compare_platforms or check_platform_safety, and no prerequisites or exclusions. The phrase 'comparison page' implies context but an agent must infer the routing decision from the slug format alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VaultRubric's public categories (high-yield savings, brokerages, crypto exchanges, hardware/software wallets) with platform counts and data URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| license | No | Data license / reuse terms |
| categories | Yes | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
| data_generated | No | Date the data was generated (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered without the description. The description adds that results carry platform counts and data URLs, which is mild contextual value, but it does not explain ordering, pagination, or scale of the result set.
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?
A single front-loaded sentence with the resource first and the illustrative category examples and return contents second. No filler or redundancy.
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?
An output schema exists and the tool takes no parameters, so the description does not need to explain return structure. For a simple discovery call with full annotation coverage, nothing an agent needs in order to invoke 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless listing operation.
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 gives a specific verb and resource ('List VaultRubric's public categories') and enumerates what those categories actually are (savings, brokerages, exchanges, wallets), which clearly separates it from single-entity siblings like get_platform and search_platforms. It stops short of explicitly naming an alternative, so it is clear but not fully differentiated.
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?
No explicit statement of when to call this versus search_platforms or get_platform, and no preconditions are given. The 'list categories' framing implies it is a discovery entry point, so usage is inferable but never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search tracked platforms by name and/or category; returns VaultRubric score, data coverage and pick eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Name fragment to match, e.g. 'trezor' or 'coin'. Empty returns all (max 50). | |
| category | No | Optional category id to filter by |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| license | No | Data license / reuse terms |
| results | Yes | |
| attribution | Yes | Always 'Source: VaultRubric (vaultrubric.com)'; include when citing. |
| methodology | No | URL of the scoring methodology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the return payload (VaultRubric score, coverage, pick eligibility), and since an output schema exists, this contributes limited extra value.
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?
A single front-loaded sentence with the operation, filters, and outputs in that order. No filler or redundancy.
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 full schema coverage, an output schema, and rich annotations, the description only needs to orient the agent, which it does. The remaining gap is the lack of guidance on choosing among the many sibling platform tools.
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%, including the empty-returns-all/max-50 behavior and the category enum, so the schema carries the parameter burden. The description's 'by name and/or category' merely restates what the schema documents; 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?
The description names a specific verb (search) and resource (tracked platforms), and adds the filter axes (name and/or category) plus the return payload. It is clearly distinguishable from singular/plural siblings like get_platform and compare_platforms, though it never names an alternative explicitly.
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: the name/category filters suggest when this is the right entry point, but there is no statement of when to prefer get_platform or compare_platforms, nor any exclusion or prerequisite. Adequate but leaves routing to inference.
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.
calculate_savings_interest1 field changedOutput schema / properties / results / items / properties / promo_separate / typeAdded value: +[
+ "string",
+ "null"
+]get_asset_newsget_ipo_calendarget_market_moverscalculate_savings_interestestimate_feescheck_platform_safetycompare_platformsget_platformget_verdictlist_categoriessearch_platformsAnalyse crypto wallets (EVM, Solana, Bitcoin) and compare DeFi lending, borrowing and pool rates.
Read-only ChainChoice rankings: sourced, dated comparisons of crypto services, with evidence.
Honest buying guides for crypto exchanges and hardware wallets, with disclosed affiliate links.
Best live crypto yield at each A-D risk grade on BTC, ETH, SOL and stablecoins, DeFi and CeFi.
Add one secure layer between your agents and this server.
