Hardware wallet comparison for agents: BitBox, Ledger, Trezor – sourced data, buying checklist
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 4 tools
The four tools split cleanly along two axes: search vs. fetch-by-id for wallets, and list vs. fetch-by-slug for guides. Descriptions explicitly state the ordering relationship (use search before get_hardware_wallet, use list_guides before get_guide), leaving no realistic misselection.
All names follow a consistent verb_noun snake_case pattern: search_hardware_wallets, get_hardware_wallet, list_guides, get_guide. The singular/plural distinction between list and get mirrors the collection-vs-item semantics precisely.
Four tools is well-scoped for a narrow read-only site about three wallet makers plus three guides; each tool covers a distinct access path (collection listing, item fetch, search). It is on the lean side and the two guide tools are close cousins, but nothing feels padded.
Both content types (wallets, guides) have collection listing, search/listing, and full-record retrieval, so there are no dead ends for the read-only domain; mutation tools are correctly absent. Minor gaps: no way to look up a guide by keyword, and listing all wallets requires a documented empty-query trick rather than a dedicated call.
Return the full Markdown text of one guide by slug (see list_guides): the BitBox/Ledger/Trezor comparison, the buyer's checklist, or the security basics, with sources.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Guide slug from list_guides. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the return format ('full Markdown text') and notes the guides include sources, which is useful but modest extra context.
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 sentence, front-loaded with the verb and return format, with the slug-source pointer trailing. No wasted words.
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?
A single-parameter read tool with full schema coverage, a closed enum, and annotations covering safety; the description states what is returned and where slugs come from, leaving nothing an agent needs unresolved.
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 enum already lists the three slugs, so the baseline is 3. The description earns an extra point by mapping the slugs to human-readable topics (comparison, buyer's checklist, security basics), telling the agent what each guide actually contains.
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 precise verb and resource ('Return the full Markdown text of one guide by slug') and enumerates the three possible guides, so an agent distinguishes this from list_guides and search_hardware_wallets immediately.
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?
Points explicitly to list_guides for slug discovery, which is the key routing condition. It does not state any when-not or prerequisites, but for a simple read tool the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full sourced record for one hardware wallet maker by id (bitbox, ledger, trezor): facts, notes, the maker's own description and store link. Use after search_hardware_wallets when a user wants details on a single wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds value beyond that by disclosing what the record contains (facts, notes, maker's own description, store link). It doesn't cover error behavior for an unknown id, but the enum constrains inputs.
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 the core action and payload, followed by the usage cue. Every clause earns its place, with zero 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?
There is no output schema, so the description usefully enumerates the returned fields (facts, notes, description, store link), which an agent needs to set expectations. Complete enough for a simple single-lookup tool, though it could mention behavior on a missing id.
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 id parameter has an enum of bitbox/ledger/trezor, so the schema does the heavy lifting. The description restates the same ids (mildly redundant) but adds no new syntax or format meaning, so baseline 3 is appropriate.
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?
Names a specific verb (Get) and resource (full sourced record for one hardware wallet maker by id), and even enumerates the valid ids. It clearly contrasts with search_hardware_wallets, so an agent can distinguish it from siblings 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?
Explicitly states the sequencing: 'Use after search_hardware_wallets when a user wants details on a single wallet.' That gives clear when-to-use context relative to a sibling. It doesn't explicitly say when-not to use it, but the contrast with the search tool is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the guides: hardware wallet comparison, buyer's checklist and recovery-phrase security basics (title, url, slug). Use to find the right guide before get_guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, closed-world profile, so the description's job is to add content context — which it does by naming the return fields (title, url, slug) and the specific guide set. No pagination or result-count behavior is mentioned, which is the only notable gap for a list operation.
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 sentences, no filler: the first states contents and returned fields, the second states purpose and the downstream call. Everything is front-loaded.
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 zero-parameter list tool with no output schema, the description supplies the missing return-shape information and the intended follow-up call. An agent has everything needed to call it and use the result.
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 to disambiguate and the baseline is 4. The description correctly implies an unfiltered full listing rather than suggesting any filtering inputs.
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 (guides) and it enumerates exactly what the collection contains (hardware wallet comparison, buyer's checklist, recovery-phrase security basics) and what fields come back. That level of specificity clearly separates it from get_hardware_wallet and search_hardware_wallets.
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?
"Use to find the right guide before get_guide" gives an explicit ordering rule and names the sibling it feeds into. It doesn't state any when-not condition (e.g., don't call if you already know the slug), but the intended workflow is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and compare hardware wallets (cold wallets for crypto). Use this whenever a user asks which hardware wallet to buy, wants BitBox vs Ledger vs Trezor compared, or asks about a specific maker. Returns structured, sourced records: maker, country, official store, the maker's own description and a link. Pass an empty query to list every maker; a name or keyword to filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20, max 50). | |
| query | No | Optional filter: maker name or keyword (e.g. 'ledger', 'open source'). Empty returns all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond annotations by disclosing the return shape (maker, country, official store, maker's description, link) and that records are sourced, which matters because there is no output schema. No mention of result ordering or pagination behavior beyond limit.
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: purpose first, then usage triggers, then return shape and query mechanics. Every sentence carries distinct information and nothing is repeated wastefully.
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 enumerating the returned fields and stating records are sourced. Combined with annotation coverage and full schema docs, an agent has everything needed to call this correctly.
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 both parameters are documented in the schema, including the 'Empty returns all' behavior and the default/max limit. The description largely restates the query semantics rather than adding new meaning, so 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 pair ('Search and compare hardware wallets') and scopes it with concrete makers (BitBox, Ledger, Trezor). It does not explicitly name the sibling get_hardware_wallet as the alternative for single-wallet lookups, so sibling differentiation is only implied.
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 clear trigger scenarios ('user asks which hardware wallet to buy', comparison requests, specific maker questions) and explains the empty-query behavior for listing all makers. It stops short of stating when NOT to use this versus get_hardware_wallet for detail on one device.
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.
get_guideget_hardware_walletlist_guidessearch_hardware_walletsCrypto address risk checks for agents: USDT/USDC blacklists, sanctions, scam lists, poisoning
Honest buying guides for crypto exchanges and hardware wallets, with disclosed affiliate links.
Crypto tax ledger for Switzerland, Germany and Austria: review, tax figures, source of funds.
Bitcoin wallet intelligence for AI agents: trust, labels, tx verify, fees, and timestamps.
Add one secure layer between your agents and this server.
