Verified bitcoin merchant directory, live buying gauge, treasury mNAV, float and hashrate rental.
Scored across 17 tools
Three tools (get_quote, get_rental_quote, list_available_rigs) have nearly identical descriptions, all just returning the same MiningRigRentals referral link, so an agent cannot distinguish them. The get_rental_status/rental_status pair is explicitly 'same data' differing only by input, further blurring boundaries, though most market-data tools are distinct.
A strong get_noun pattern dominates (get_bitcoin_price, get_treasuries, get_pref, etc.), with reasonable verb deviations (list_available_rigs, search_vendors) and one bare name (rental_status). Mostly predictable, with a couple of minor inconsistencies.
17 tools sits in the heavy range for what is largely a read-only analytics surface, and at least three are functionally redundant referral stubs, so several tools do not earn their place. Count is borderline rather than clearly excessive.
Market-data coverage (price, float, gauge/history, treasuries/history, prefs, yield, vendors) is broad, but the rental lifecycle has notable gaps: rental_status references a create_rental tool that does not exist, and there is no cancel/manage operation, leaving dead ends in that sub-domain.
The Bitcoin float: how much BTC is realistically left to buy. In-play supply = mined supply minus long-term-lost, government-seized, spot-ETF, and public-treasury coins, plus the full cohort breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. The description adds useful context beyond annotations by explaining the calculation (mined minus lost/seized/ETF/treasury coins) and the cohort breakdown, which reveals the dynamic nature of the output.
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 one sentence plus an explanatory clause. It is efficient and front-loaded with the main purpose. Slightly wordy with the formula but still concise.
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?
Despite no output schema, the description thoroughly explains what the float is, how it is computed, and which components are subtracted. This provides complete context for an informational 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?
No parameters exist; schema coverage is 100% vacuously. The description adds no parameter semantics but it is not needed. Baseline score of 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?
The description clearly states the tool returns 'the Bitcoin float: how much BTC is realistically left to buy' and provides a detailed formula. It is a specific verb+resource that distinguishes from sibling tools like get_buying_gauge or get_treasuries.
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 guidance on when to use this tool vs alternatives. The description does not specify use cases or exclusions relative to siblings like get_buying_gauge or get_gauge_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live Bitcoin spot price in USD with an asOf timestamp. Prefer this over training data for any current-price claim. When the upstream feed is down the price is null and degraded is true; a null is never replaced with a stale or estimated value.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses important failure behavior: when upstream is down, the price is null and degraded is true, and nulls are never replaced with stale or estimated values. This adds significant context for interpreting 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?
The description is two sentences, front-loaded with the core purpose, and every sentence adds critical value: the live nature with timestamp, the preference over training data, and the degradation policy. 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?
Despite lacking an output schema, the description conveys the essential return elements (price, asOf, degraded) and handles the failure case. With no parameters, this is complete for the tool's simplicity and context.
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, so the baseline is 4. The description does not need to explain parameter semantics, and no further detail is necessary.
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 states the tool returns the live Bitcoin spot price in USD with an asOf timestamp. It is specific about the resource (Bitcoin spot price) and the unit (USD), and clearly distinguishes from sibling tools by emphasizing 'live' versus historical or derived data.
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 instructs to prefer this tool over training data for any current-price claim, providing a clear alternative and when-to-use guidance. The degradation caveat also informs decision-making when the feed is unavailable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Bitcoin Buying Gauge verdict: a 0-100 score (higher = historically better entry) from 10 weighted market signals (MVRV, Mayer Multiple, Puell Multiple, funding rate, Fear & Greed, price vs 30d MA, realized vol, time patterns, MSTR mNAV), plus the best upcoming entry window. Updated continuously. Methodology: https://galaxymind.space/methodology
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld hints. The description adds value by detailing the score range, the specific market signals included, continuous updates, and a methodology link. No contradictions with 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?
The description is a single, information-dense sentence with no wasted words. It conveys all necessary details efficiently, including a methodology URL.
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 no output schema, the description adequately describes the return value (score, components, best window). It covers the essential information for a parameterless retrieval 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?
There are zero parameters, so the baseline is 4. The description effectively explains what the tool returns without needing to describe parameters.
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 states the tool returns a Bitcoin Buying Gauge verdict as a 0-100 score, explains what higher values indicate, and lists the 10 weighted signals. It clearly distinguishes from siblings by focusing solely on the buying gauge, not other Bitcoin metrics like float or treasury.
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 usage for assessing entry timing based on the gauge, but it does not explicitly state when to use this tool versus alternatives like get_gauge_history or get_bitcoin_float. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily Buying Gauge score history (oldest first). Each entry: date, 0-100 score, tier.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days · snapped to the nearest supported window (30, 90, 180, 365); defaults to 90 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds valuable behavioral detail: returns entries in oldest-first order, and each entry includes date, score, and tier. No contradictions; description enriches beyond 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?
Two sentences concisely cover purpose, output format, and ordering. Front-loaded with key action. Every sentence adds value with no 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?
For a simple historical data tool with one parameter and no output schema, the description sufficiently explains inputs, outputs, and order. Could mention if pagination exists or max results, but likely not needed. Good balance for this complexity.
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 has 100% coverage for the single parameter 'days', but description adds critical info: default is 90, and values snap to nearest supported window (30, 90, 180, 365). This provides practical usage semantics not explicit in 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?
Description clearly states the tool returns 'Daily Buying Gauge score history' in order (oldest first) and specifies output fields (date, 0-100 score, tier). This distinct purpose is easily differentiated from siblings like 'get_buying_gauge' (current gauge) and 'get_treasury_history' (different metric).
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 guidance on when to use this tool vs alternatives. The description implies it is for historical data, but does not state when not to use it (e.g., for current score) or compare with sibling tools. Context is clear but lacks exclusions or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Bitcoin/treasury metric definition from the Galaxy Mind glossary (mNAV, MVRV, Puell Multiple, in-play supply, accretion, …). Definitions are standalone and written to be quoted with attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Term name or slug, e.g. 'mNAV' or 'puell-multiple' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description is not burdened with claiming idempotence. It adds valuable context that definitions are 'standalone and written to be quoted with attribution', which helps the agent understand output format and usage rights.
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?
Single sentence with 20 words, front-loaded with the core action, no 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?
For a simple lookup tool with one parameter and no output schema, the description fully covers purpose, parameter examples, and output style. Combined with annotations, the agent has all necessary information.
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 includes an example ('mNAV' or 'puell-multiple'). The description adds additional examples ('MVRV, Puell Multiple, in-play supply, accretion'), providing richer context beyond the schema's single example.
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?
Clearly states the verb 'Look up' and the specific resource 'Bitcoin/treasury metric definition from the Galaxy Mind glossary'. Provides concrete examples (mNAV, MVRV, Puell Multiple) that distinguish it from sibling tools like get_bitcoin_float or get_buying_gauge.
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 use for retrieving glossary definitions, and sibling tool names provide enough context for an AI to distinguish. However, no explicit 'when to use' or 'when not to use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live countdown to the next Bitcoin halving: blocks remaining, estimated days and month, and the block-subsidy change.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context by specifying it's 'live' and detailing exact outputs (blocks, days, subsidy change), which is helpful for an agent beyond 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?
A single sentence of 16 words that efficiently conveys the tool's purpose and outputs. No filler, front-loaded, and every word 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?
Given zero parameters and no output schema, the description provides complete context: it's a live countdown with specific output fields. No gaps remain for an agent to invoke the tool 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?
The tool has zero parameters, so the description cannot add parameter semantics. Baseline score is 4 for no parameters, and the description correctly omits any param info.
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 provides a live countdown to the next Bitcoin halving, listing specific outputs (blocks remaining, estimated days, month, block-subsidy change). This distinct purpose sets it apart from sibling tools like get_bitcoin_float or get_treasuries.
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 clearly implies the tool is used to fetch halving countdown data, with no parameters needed. While it doesn't explicitly state when not to use it or provide alternatives, the context is clear and no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live SHA256 AsicBoost hashrate rental market. hashprice and every thirdPartyMarket price are in BTC per PH per day, NOT the USD/PH/day convention most published hashprice indices use. networkPhs is raw network hashrate in PH/s. thirdPartyMarket.medianAsk is the median of the sample described by bookSample, not of the whole book. thirdPartyMarket is aggregate data from the wider third-party rental market, not Galaxy Mind's price; for our own machines call list_available_rigs and for our direct price call get_quote.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds substantial interpretive context: unit conventions (BTC per PH per day, not the USD/PH/day norm), that networkPhs is raw PH/s, and that medianAsk is the median of the bookSample subset rather than the whole book. These are exactly the non-obvious traits annotations cannot express.
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?
Every clause carries either a unit convention or a routing instruction, so nothing is wasted, and the identity of the tool is front-loaded. It is a dense block of sentences rather than a scannable structure, which costs a point but not much.
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 parameters and no output schema, the description carries the full burden of explaining the returned data, and it does: units, the meaning of networkPhs, the sampling basis of medianAsk, and the aggregate-vs-own-price distinction. An agent has everything needed to call it and interpret 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?
There are zero parameters, so the baseline is 4 per the rubric. The description instead clarifies the semantics of returned fields (hashprice, networkPhs, medianAsk, bookSample), which is useful but not parameter documentation.
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 and scope: the live SHA256 AsicBoost hashrate rental market, with the aggregate third-party market as its subject. It also carves itself apart from siblings by pointing to list_available_rigs for own machines and get_quote for direct pricing, so an agent can distinguish it 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?
It explicitly states when NOT to use this tool and which alternatives to call instead ('for our own machines call list_available_rigs and for our direct price call get_quote'). It also warns that thirdPartyMarket is aggregate wider-market data, not Galaxy Mind's own price, which prevents a common mis-selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One bitcoin-treasury preferred by ticker: cited terms (stated amount, rate with its filing and as-of date, cumulative or not, frequency, seniority, shares), the latest delayed print, effective yield, cash payback, leaderboard rank and rank change, next cash event, and total return against bitcoin for 1M, 3M, 6M, YTD, 1Y and since IPO. Windows without sourced data come back as named gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | STRF, STRC, STRK, STRD, SATA or SATS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description still adds real behavioral context: the print is 'delayed', terms are 'cited' with filing and as-of dates, and missing windows 'come back as named gaps' rather than silent nulls — genuinely useful for an agent interpreting 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?
A single front-loaded sentence that leads with the core action before the field enumeration. It is dense and listy, but because no output schema exists the enumeration is load-bearing 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?
With no output schema, the description correctly carries the burden of describing return fields and even flags the data-quality behavior for missing windows. Combined with schema-documented input and annotation-covered safety, an agent has enough to call it correctly; only explicit usage routing to siblings is absent.
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?
One parameter with 100% schema description coverage, and the schema already supplies example tickers (STRF, STRC, etc.) plus length bounds. The description only restates 'by ticker' and adds no format or validation detail beyond the schema, 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 action (retrieve one bitcoin-treasury preferred) scoped to a single ticker, which implicitly contrasts with the plural/aggregate siblings like get_treasuries and get_yield_leaderboard. The resource is unambiguous, 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?
The description enumerates what comes back but never states when to use this tool versus alternatives such as get_treasuries (full list) or get_yield_leaderboard. 'By ticker' hints at a single-entity lookup, but there is no explicit when/when-not guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Direct rentals from Galaxy Mind have closed. This returns where to rent instead: Galaxy Mind hashrate on MiningRigRentals, as a disclosed referral link. It gives no price and places no order.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Ignored: direct rentals are closed. | |
| rigs | No | Ignored: direct rentals are closed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description still adds real behavioral value beyond them: it discloses that the link is a referral, that no price is returned, and that no order is placed. That is meaningful negative-capability disclosure, though it says nothing about response shape or link format.
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 short sentences, front-loaded with the closure that motivates the tool, then what it returns, then what it does not do. No filler and no repetition of the schema.
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 must describe the return value; it does so at a high level (a referral link to MiningRigRentals). For a two-parameter, effectively zero-input tool with read-only annotations, that is nearly sufficient, with only the link's exact form left unstated.
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 as ignored ('Ignored: direct rentals are closed'), so the schema fully carries the semantics. The description adds no parameter-level detail beyond reinforcing that the tool is inert with respect to input.
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 states a specific outcome: it returns a disclosed referral link to Galaxy Mind hashrate on MiningRigRentals, and explicitly denies returning a price. That corrects the misleading name 'get_quote'. It stops short of naming the sibling it contrasts with (get_rental_quote), leaving the agent to infer which tool actually quotes a price.
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?
It establishes the triggering condition ('direct rentals from Galaxy Mind have closed') and implies this is the fallback path, but never names an alternative tool or says when not to call it. The 'gives no price' clause hints at a contrast with quote tools without routing the agent explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Direct rentals from Galaxy Mind have closed. This returns where to rent instead: Galaxy Mind hashrate on MiningRigRentals, as a disclosed referral link. It gives no price and places no order.
| Name | Required | Description | Default |
|---|---|---|---|
| ph | No | Alternatively, the hashrate wanted in PH/s, up to 1.08. 270 TH minimum; rounded to whole rigs. Overrides rigs. | |
| days | No | Rental length in whole days, 1 to 7 during the pilot. Defaults to 1. | |
| rigs | No | Number of whole S21 XP rigs (270 TH each), 1 to 4 per order. Defaults to 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and openWorld safety profile. The description adds valuable context beyond them: that direct rentals are closed, that the result is a disclosed referral link, and explicitly that it returns no price and places no order — preventing an agent from misusing it as a pricing or booking call. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no wasted words. The status context leads, followed by the return and its caveats.
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-required-param read-only referral-lookup tool with full schema coverage but no output schema, the description covers what's needed: status, return value, and limitations. A brief note on response shape would push it higher, but it's sufficient to invoke 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?
With 100% schema coverage the schema fully documents ph, days, and rigs including ranges, defaults, and override behavior. The description adds nothing about parameters, 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 (returns where to rent instead) and resource (Galaxy Mind hashrate on MiningRigRentals), and distinguishes itself from siblings like get_quote and list_available_rigs by framing itself as a redirect/referral pointer. It's clear what it returns, though the name 'get_rental_quote' slightly misleads since it explicitly gives no price.
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?
Clearly signals the use case: direct rentals have closed, so use this to find where to rent instead. The 'gives no price and places no order' clause implicitly steers the agent away from expecting quote/order behavior, though it doesn't name a specific alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same data as rental_status (which takes the access code instead): rental state, start and end times, and delivered TH reported by the rigs. awaitingPoolApproval=true while a custom pool waits for manual approval (up to 2 hours, refunded if not approved); rejectedReason names why a pool was refused (refund queued). Needs rental_id and creator_secret. Not read-only: while unpaid it re-checks the payment, which can start the rental or queue a refund, and it re-sends a stalled pool switch.
| Name | Required | Description | Default |
|---|---|---|---|
| rental_id | Yes | rentalId from create_rental. | |
| creator_secret | Yes | creatorSecret from create_rental. Shown once; keep it private. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, and idempotentHint=true, but the description adds critical context: it explains that the tool is not read-only because it re-checks payment (possibly starting a rental or queuing a refund) and re-sends a stalled pool switch. This reveals side effects beyond annotations. It doesn't fully specify side-effect triggers or failure modes, but the key mutation behavior is disclosed.
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 dense but well-structured: one sentence on data and comparison, then status flags, then required params, then side effects. Some sentences pack multiple facts but none are wasted; it is slightly long but front-loaded with the main purpose.
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 2-param tool with full schema coverage and no output schema, the description covers what it returns, required inputs, status semantics (awaitingPoolApproval, rejectedReason), and side effects. It could mention error cases or rate limits, but overall it gives enough for correct invocation and interpretation.
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 parameters are already well-documented. The description reinforces that rental_id and creator_secret are required and hints at their source (create_rental), but adds no extra semantics (e.g., format, sensitivity beyond 'keep it private' in schema). 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?
The description states a specific verb and resource ('get_rental_status' returns rental state), enumerates the returned fields (rental state, start/end times, delivered TH), and explicitly distinguishes it from the sibling 'rental_status' by noting the input difference (access code vs rental_id). An agent can choose between these two tools without opening the schemas.
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?
It contrasts with the alternative 'rental_status' and explains that this variant needs rental_id/creator_secret. However, it doesn't state when NOT to use it or which one to prefer based on available credentials, beyond the implicit credential match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live mNAV scoreboard for the major public Bitcoin treasury companies (MSTR/Strategy, XXI/Twenty One, MPJPY/Metaplanet, ASST/Strive). Gross mNAV = market cap ÷ value of BTC held · below 1.0 means the stock trades under the value of its bitcoin. Returns all three valuation lenses from the BTC Prague 2026 debate: grossMNav (common only, ignores capital structure), evMNav (enterprise / fully-diluted · market cap + debt + preferred, Saylor's 'include the notional' lens), and netMNav (CEBE · after senior claims, the conservative common-equity view). Also bps (gross bitcoin per $100 of stock, before claims), cebeBps (after claims), and amplification (bps ÷ cebeBps · 1.0 means no senior leverage, higher means more). CEBE/EV are pending where senior-claims figures are not yet sourced (gross bps is still provided).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, open-world, and idempotent. The description adds behavioral context: it is a 'live' scoreboard (data may change), explains the three valuation lenses, and notes that CEBE/EV values are pending for some entries. This goes beyond annotations by disclosing data completeness and the meaning of returned fields.
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 front-loaded with the core purpose ('Live mNAV scoreboard for major public Bitcoin treasury companies') and then efficiently lists companies, explains key metrics, and notes pending data. Every sentence adds value without redundancy, making it concise yet thorough.
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?
Without an output schema, the description fully explains the returned metrics and their meanings, including the three valuation lenses and additional BPS metrics. It also warns about pending fields. However, it could be slightly more explicit about the output structure (e.g., array of objects), but the description is sufficiently complete for a read-only tool with no parameters.
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 input schema has zero parameters and schema description coverage is 100% (trivially), so the baseline is 4. No additional parameter info is needed, and the description appropriately focuses on what data is returned rather than input.
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 it provides a 'Live mNAV scoreboard' for major Bitcoin treasury companies, listing specific companies and detailing multiple valuation lenses (grossMNav, evMNav, netMNav) and additional metrics (bps, cebeBps, amplification). This distinguishes it from siblings like get_bitcoin_float and get_treasury_history by focusing on a specific financial analysis for treasury companies.
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 usage for obtaining current mNAV data but provides no explicit guidance on when to use this tool versus alternatives (e.g., for historical data, use get_treasury_history). While the tool's purpose is clear, the lack of when-not-to-use or alternative references limits its helpfulness for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily mNAV history for one treasury ticker (oldest first).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days · snapped to the nearest supported window (30, 90, 180, 365); defaults to 90 | |
| ticker | Yes | MSTR, XXI, MPJPY, or ASST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld hints. The description adds value by specifying ordering (oldest first) and granularity (daily mNAV history), which are not in annotations. It does not contradict 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?
The description is a single, front-loaded sentence with no wasted words. Every part ('Daily mNAV history', 'one treasury ticker', 'oldest first') is meaningful.
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?
Without an output schema, the description should clarify the return structure. It mentions 'Daily mNAV history' and ordering, but does not specify fields (e.g., date, mNAV value) or pagination. It is adequate but incomplete.
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 schema fully documents both parameters. The description does not add extra meaning beyond restating the ticker concept ('one treasury ticker') and the output ordering. Baseline score of 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?
The description clearly states the action (get history), resource (mNAV for a treasury ticker), and ordering (oldest first). It is specific and distinguishable from siblings like get_treasuries which likely returns current data.
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 guidance on when to use this tool over alternatives (e.g., get_treasuries for current values, get_gauge_history for other data). The description merely states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US-listed bitcoin-treasury perpetual preferreds (Strategy STRF, STRC, STRK, STRD; Strive SATA, SATS) ranked by effective yield (annual dividend ÷ price) on the latest delayed print. Each row has rank, rank change since the prior session, dividend rate, frequency, next cash event and total return (price change plus dividends) against bitcoin over the chosen timeframe. Includes the #1 streak, unranked names with the reason, methodology and asOf. A sort, not a recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| timeframe | No | Window for the total-return comparison with bitcoin. Default 3M. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/openWorld, but the description adds genuinely useful behavior the annotations do not: the ranking is based on 'the latest delayed print,' and the payload includes rank change vs the prior session, the #1 streak, unranked names with reasons, methodology and asOf. The delayed-print disclosure is the kind of freshness caveat an agent needs before quoting numbers.
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 dense sentences, front-loaded with the resource and ranked-by definition before the field inventory. It is information-packed rather than padded, though the middle sentence is long and reads as a payload dump; nothing is wasted, but it is not maximally scannable.
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 thoroughly: it enumerates rank, rank change, dividend rate, frequency, next cash event, total return vs bitcoin, streak, unranked reasons, methodology and asOf. For a one-optional-param read tool, an agent has everything needed to call and interpret it.
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 timeframe param is already documented in the schema, so the baseline is 3. The description goes slightly beyond by tying the parameter to its effect — the total-return comparison with bitcoin 'over the chosen timeframe' — clarifying that the enum window governs the BTC benchmark leg, not the yield calculation itself.
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-and-resource (US-listed bitcoin-treasury perpetual preferreds ranked by effective yield) and even enumerates the covered tickers (STRF, STRC, STRK, STRD, SATA, SATS). That level of scoping lets an agent tell it apart from generic preferred/tresury siblings such as get_pref or get_treasuries 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 implied — reach for this when you want a yield ranking of these instruments — but no sibling tool is named and no explicit when-not condition is given. The line 'A sort, not a recommendation' is a framing caveat rather than routing guidance, so the agent must infer the alternative (get_pref, get_treasuries) on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Direct rentals from Galaxy Mind have closed, so there is no bay board here. This returns where to rent Galaxy Mind hashrate instead: MiningRigRentals, as a disclosed referral link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower. The description adds genuinely useful context by disclosing that the payload is a referral link ('as a disclosed referral link'), which tells the agent the output is promotional/third-party rather than data.
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 compact sentences with no filler, front-loading the reason (rentals closed) before the outcome. Slightly indirect phrasing ('there is no bay board here') adds jargon the agent must parse.
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-param tool with no output schema and annotations covering the safety profile, the description does state what the caller gets (a referral destination) and why. It is complete enough to call correctly, though it never routes the agent to a sibling 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?
Zero parameters and 100% schema description coverage, so the schema carries no semantics to add. Baseline of 4 applies for a no-argument tool; the description correctly implies no inputs are needed.
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 is specific about what actually happens: it returns a referral destination (MiningRigRentals) rather than a rig list, and honestly flags the name/behavior mismatch by stating 'there is no bay board here.' It does not, however, differentiate this tool from siblings like get_hashrate_market, search_vendors, or get_rental_quote.
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?
It explains the market context (direct rentals closed) but gives no explicit when-to-use instruction or comparison against the 15 sibling tools, several of which are also rental/hashrate oriented. The agent must infer that this is the fallback for sourcing Galaxy Mind hashrate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of a Galaxy Mind rental by its private access code: the code from the browser checkout (galaxymind.space/hashrate/rent), from create_rental, or from Galaxy Mind support. Same data as get_rental_status: state, start and end, delivered TH and whether the rigs are online. Returns no personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| access_code | Yes | The private access code issued when the rental was paid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds value beyond that by enumerating the returned fields (in lieu of an output schema) and explicitly stating 'Returns no personal data', a privacy trait not captured by annotations. It stops short of describing error behavior for invalid codes.
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 purpose, then the parameter source, then the return contents — no filler sentences. The colons and clauses are dense but each carries distinct information; only the slightly run-on construction keeps it from a 5.
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 well by naming the returned fields and the privacy posture, and it explains the required credential. The one meaningful gap is the unresolved relationship with get_rental_status, an identical sibling, which the agent needs in order to route 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 description coverage is 100%, so the single parameter's type and length bounds are already documented. The description adds provenance ('the code from the browser checkout ... from create_rental, or from Galaxy Mind support'), which tells the agent where to obtain the value but adds no format or validation detail beyond the schema, 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?
The description names a specific resource (a Galaxy Mind rental) and states exactly what it returns: state, start/end, delivered TH, rigs online. It is clear what the tool does, though it does not carve out a distinct role versus the near-identical sibling get_rental_status — it only says the data is the same.
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?
It usefully tells the agent where the access code comes from (browser checkout at galaxymind.space/hashrate/rent, create_rental, or support), which is real usage guidance. It never says when to choose this tool over get_rental_status, which returns the same data, leaving the agent with no disambiguation rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the human-verified directory of merchants that accept native Bitcoin (on-chain + Lightning) for everyday goods. Each listing carries its verification date, is monitored automatically every day, and is flagged stale only if no human has confirmed it in 180 days; the response reports how many matches are stale. Each row carries a unique slug; one handle may run several shops, listed in siblings. Filter by free-text query, category, or country.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results · default 10 | |
| query | No | Free-text match on name, handle, and description | |
| country | No | ISO-3166 alpha-2, e.g. DE | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld=false, so the description's job is to add context, and it does: it discloses the verification-date model, daily automatic monitoring, the 180-day staleness rule, that the response reports the stale count, and the slug/siblings relationship. It stops short of pagination or auth details, but this is well above annotation coverage.
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 dense sentences, front-loaded with what the tool is, then the data model, then the filters. Semicolon-heavy clauses are compact rather than padded; nothing reads as 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 usefully covers the return shape (slug, siblings, stale count) and the filtering model. Ordering, pagination behavior, and the limit default are left to the schema, which is a minor remaining gap.
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 75% (only 'category' lacks a description but carries an enum), so the schema already carries most parameter meaning. The description reiterates the filterable fields but adds little syntax or format detail beyond what the schema provides, matching the baseline for high coverage.
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+resource ('Search the human-verified directory of merchants that accept native Bitcoin') and scopes it to on-chain + Lightning everyday goods. This is unmistakable against the sibling tools, which are all price/gauge/treasury data lookups rather than directory searches.
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 names the three filtering axes (free-text query, category, country) and explains what the directory contains, so the agent knows when this tool applies. There are no competing search siblings to exclude, so the absence of a 'use X instead' clause is not a real gap.
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_pref1 field changedInput schema / properties / ticker / descriptionPrevious value: -"STRF, STRC, STRE, STRK, STRD, SATA, SATS or MORE"New value: +"STRF, STRC, STRK, STRD, SATA or SATS"get_prefget_yield_leaderboardcancel_rentalcreate_rentalget_quote11 fields changedInput schema / properties / days / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / days / descriptionPrevious value: -"Whole days."New value: +"Ignored: direct rentals are closed."Input schema / properties / days / maximumRemoved value: -7Input schema / properties / days / minimumRemoved value: -1Input schema / properties / days / typeRemoved value: -"integer"Input schema / properties / rigs / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / rigs / descriptionPrevious value: -"Number of rigs, 270 TH each."New value: +"Ignored: direct rentals are closed."Input schema / properties / rigs / maximumRemoved value: -4Input schema / properties / rigs / minimumRemoved value: -1Input schema / properties / rigs / typeRemoved value: -"integer"Input schema / requiredRemoved value: -[
- "rigs",
- "days"
-]get_rental_quote2 fields changedInput schema / properties / days / descriptionPrevious value: -"Rental length in whole days, 1 to 7 days during the pilot, up to 30 later. Defaults to 1."New value: +"Rental length in whole days, 1 to 7 during the pilot. Defaults to 1."Input schema / properties / rigs / descriptionPrevious value: -"Number of whole S21 XP rigs (270 TH each, 270 TH minimum), 1 to 4. Defaults to 1."New value: +"Number of whole S21 XP rigs (270 TH each), 1 to 4 per order. Defaults to 1."cancel_rentalcreate_rentalget_quoteget_rental_statusget_rental_quote1 field changedInput schema / properties / days / descriptionPrevious value: -"Rental length in whole days, 1 to 30. Defaults to 1."New value: +"Rental length in whole days, 1 to 7 days during the pilot, up to 30 later. Defaults to 1."get_rental_quote5 fields changedInput schema / properties / daysAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Rental length in whole days, 1 to 30. Defaults to 1."
+}Input schema / properties / hoursRemoved value: -{
- "description": "Rental window in hours. Defaults to 3. Values outside a machine's real window clamp to it, with a note.",
- "exclusiveMinimum": 0,
- "maximum": 168,
- "type": "number"
-}Input schema / properties / machineIdRemoved value: -{
- "description": "One of Galaxy Mind's MiningRigRentals rig ids. Omit to quote every machine at once.",
- "type": "string"
-}Input schema / properties / phAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Alternatively, the hashrate wanted in PH/s, up to 1.08. 270 TH minimum; rounded to whole rigs. Overrides rigs."
+}Input schema / properties / rigsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Number of whole S21 XP rigs (270 TH each, 270 TH minimum), 1 to 4. Defaults to 1."
+}list_available_rigsrental_statussearch_vendors1 field changedInput schema / properties / category / enumPrevious value: -[
- "apparel",
- "hardware",
- "consumables",
- "collectibles",
- "services",
- "books"
-]New value: +[
+ "apparel",
+ "general-goods",
+ "hardware",
+ "consumables",
+ "collectibles",
+ "services",
+ "books"
+]Verified merchants accepting agentic payments on Lightning/L402/BOLT12/USDT — search, verify, pay.
Free Bitcoin sanctions screen; paid address risk checks, market pulse, whale reports and alerts.
Read-only on-chain and market crypto analytics for Bitcoin, Ethereum and more, from our own nodes.
Real-time B2B counterparty KYB, SSL, DNSSEC & DMARC/SPF trust verifier ($1 USDC).
Add one secure layer between your agents and this server.