The Bitcoin credit markets, measured. Cross-venue rates, venue criteria, chain indicators.
Scored across 13 tools
Most tools target clearly distinct artifacts (credit state, venue registry, verification bundle, market composition/flows), and descriptions are unusually explicit about scope. However, there is real overlap between list_indicators (which covers the 'onchain' family including MVRV) and list_onchain_indicators, and get_mvrv duplicates an indicator that list_indicators also advertises, which could cause misselection.
Every tool follows a strict verb_noun snake_case pattern (get_*, list_*, compare_*), with the only variation being the natural get_credit_state_history suffix. No mixed conventions or vague verbs.
13 tools is a well-scoped set for a descriptive credit/onchain data server. The only bloat is the pair of indicator catalog tools, which could plausibly be merged into one.
The read-only surface covers CRUD-equivalent discovery (list/get) for venues, credit state, history, composition, flows, verification and indicators, and it is explicitly and intentionally write-free. A minor gap: list_indicators names SOPR and other onchain metrics, but only MVRV gets a dedicated tool, leaving those indicators reachable only via generic get_indicator.
What does credit at this tenor and LTV cost across every venue Aletheia covers? One row per venue in coverage-matrix order — no ranking, no default sort, no "best".
| Name | Required | Description | Default |
|---|---|---|---|
| ltv | No | Loan-to-value as a decimal 0–1, not a percentage. | |
| side | No | 'borrow' (what a borrower pays, the default) or 'lend' (what a capital provider earns). | |
| class | No | Restrict to one credit class. The full matrix is ~160 rows; one class is far lighter. | |
| venues | No | Comma-separated registry ids to restrict the rows to, e.g. 'aave_v3_ethereum,cefi_ledn'. | |
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. | |
| tenor_days | No | Loan term in days to compare at. |
Returns one series from Aletheia's vintage store, by id (see list_chain_series): every value with its date and kind, the series' unit, source and limitation, and the vintages the values came from. With as_known_on, returns the series exactly as the store held it at the end of that day (UTC), so a past answer can be reproduced.
Chain series reach back to 2009 and are day-granular. Priced values (realised value, MVRV, SOPR, hashprice in USD) value each coin at the price of the day it was created: Aletheia's on-chain fixing from 2020-07-13, CoinGecko's daily price before. Such points carry coingecko_share and price_today, and the response's licence block carries the attribution: show it with them. This tool returns data; it does not advise, forecast, or characterise the market.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Series id, e.g. chain.cohort.supply_btc, chain.cohort.mvrv, miner.hpx_btc, price.btc_in_basket, fx.eur | |
| to | No | Last date, YYYY-MM-DD | |
| from | No | First date, YYYY-MM-DD | |
| as_known_on | No | YYYY-MM-DD: the series as the store held it at the end of that day (UTC) |
Returns Bitcoin's supply alive at the end of one UTC day, grouped by the BTC price on the day each coin was created, in logarithmic price buckets of a chosen width (ratio, default 1.02: each bucket spans 2%). Built from Aletheia's own node, block by block; day-granular.
Creation prices are Aletheia's on-chain fixing from 2020-07-13 and CoinGecko's daily price before; each bucket states how much of it is CoinGecko-priced (coingecko_btc), and the licence block carries the attribution. Coins created before 2010-07-17 have no price and form one bucket at 0. This tool returns data; it does not advise, forecast, or characterise the market.
Returns: { date, ratio, unit, buckets: [{ low_usd, high_usd, btc, coingecko_btc }], limitation, licence }.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The day, YYYY-MM-DD (a complete day: up to the day before the latest) | |
| ratio | No | Bucket width as a price ratio, 1.005 to 2 (default 1.02) |
What does Bitcoin-collateralised credit cost and how much of it is outstanding, across the venues this dataset covers? One reading aggregated over the venue universe, not any single venue's book.
Carries the term structure, outstanding quantity, valuation, collateral mix and quality composition, with the coverage block stating how many venues contributed and naming the ones that did not. No venue is weighted up, floated or reported under its own heading.
⚠ Read coverage before reading the figures. A venue absent from this reading is a declared gap, not a zero, and the rows it would have contributed are counted separately as unavailable.
Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. With collateral: 'eth' this returns the ether market: the same six figures at market and class level, books per loan currency (ether lent against ether is its own book, outside the headline).
| Name | Required | Description | Default |
|---|---|---|---|
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. |
How has the Bitcoin credit surface moved? The same cross-venue reading as get_credit_state, as a daily series.
Each point carries the coverage that produced it, so a change in the series and a change in which venues were observable can be told apart. This is descriptive data; it does not forecast and it does not characterise a trend.
⚠ Coverage is not constant through the series. A move in a figure may be a move in the market or a venue entering or leaving observation — the per-point coverage is what distinguishes them.
Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. The ether series starts on 2026-10-08 and runs forward; earlier ether history is not back-filled yet.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days of history. Default 365, capped at 3650. | |
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. |
Returns the current value of a single Aletheia indicator by id, with its methodology reference. This server serves the venue-independent indicator set; an indicator anchored on a single venue's own rate is served by that venue's own MCP and answers here with a pointer to it. Call list_indicators first to discover valid ids.
Optionally returns the historical series instead of the current value (set include_history). History is free and unmetered on the same terms as the current value.
This is descriptive data; no recommendation is provided. An indicator that has no reading on this network says so explicitly rather than returning a null or a zero that could be mistaken for a value.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Indicator id from list_indicators, e.g. 'intermediation-spread', 'capital-stack', 'benchmark-curves'. | |
| to | No | History end, ISO 8601 date. Only meaningful with include_history. | |
| from | No | History start, ISO 8601 date. Only meaningful with include_history. | |
| include_history | No | If true, return the historical series instead of the current value. Not every indicator has one. |
Returns a READING LENS: a presentation procedure for this dataset, written for a particular kind of reader. A lens selects which tools to use and frames how their output is presented; it never concludes, never ranks, and carries no write tool — this server has none.
Call with no argument to list the lenses. Call with one to get its full procedure: what to lead with, the tools in its scope, and — the part that matters most — what that lens explicitly does not do.
Reading a lens before presenting anything from this dataset is the intended use. It is guidance for presentation, not data about the market, and it adds no figures of its own.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Which lens. Omit to list all of them. 'orientation' — Orientation — what this dataset is, and what it will not tell you; 'holder' — Holder — the cost of credit against bitcoin you already hold; 'treasurer' — Treasurer — tenor, maturity and counterparty structure; 'analyst' — Analyst — methodology, provenance and coverage; 'risk' — Risk — what stands behind a position, and what can change under it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool never concludes, never ranks, carries no write tool, and adds no figures of its own, giving the agent an accurate behavioral model before calling.
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 slightly longer than typical but every sentence earns its place, defining the concept, explaining both call modes, and setting usage expectations. The key behavioral constraints are front-loaded in the first paragraph.
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 explains what the agent receives in both invocation modes and outlines the contents of a full lens procedure. It also clarifies what the lens explicitly does not do, making the tool's behavior and return semantics complete for safe invocation.
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?
Although the schema enum already documents each lens value, the description adds crucial parameter semantics: omitting the argument lists all lenses, while supplying one returns the full procedure. This goes beyond the schema's per-value descriptions.
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 opens with a specific verb and resource: 'Returns a READING LENS' and then defines what a lens is. It clearly distinguishes itself from the sibling data tools by stating it is presentation guidance, not market data, and that it adds no figures.
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 when to use it: 'Reading a lens before presenting anything from this dataset is the intended use.' It also explains exactly how to invoke it depending on whether the agent wants a list or a full procedure, and clarifies it is 'not data about the market'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much bitcoin-secured dollar debt is liquidated at which bitcoin price, for the market, a class or a venue? An identity on observed positions: each bitcoin-only position at the price its OWN venue's rule liquidates it, summed into $1,000 buckets, with the debt within 10/20/30% of each venue's own mark, the debt already past its venue's test, and overflow.
It does not forecast what a fall in the price would do, it does not rank venues (they are listed by name) and it gives no verdict such as "at risk".
⚠ Read coverage and not_bucketed first. Only venues read position by position are in the map (the pooled venues, Morpho on Ethereum and Base, Sky); every other venue with debt is named with its reason and is never scaled up. With history=true the bands come as a daily series: Sky from 2020-05-03, the rest from 2026-10-08 — a step there is coverage, not the market.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A class id (algorithmic, minted, ...) or a venue id; required below the market. | |
| to | No | With history: the last day. | |
| date | No | A day held; default the latest. | |
| from | No | With history: the first day. | |
| level | No | Default market. | |
| history | No | Return the bands through time instead of one day's buckets. | |
| as_known_on | No | With history: the bands as published at the end of that day (UTC). |
What kinds of credit make up this market, and in what proportions? ⚠ These series are computed from MORPHO BLUE ONLY, on Ethereum and Base. They are not market-wide.
Composition by rate type, recourse and instrument, reported as observed shares with the scope that produced them. There is no ranking of venues or instrument types and no judgement about which composition is preferable.
⚠ The scope block names the contributing venues and states why the others are absent — Aave v3 is mid-backfill, Compound v3 and Sky are not yet ingested. Read it before quoting any share. A percentage from this tool describes one venue family, not Bitcoin-collateralised credit.
Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. No ether composition series is served yet; with collateral: 'eth' this says so and points to the ether figures.
| Name | Required | Description | Default |
|---|---|---|---|
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. |
How much credit was created and retired, and over what period? Latest, trailing 30 days, and since inception. ⚠ These series are computed from MORPHO BLUE ONLY, on Ethereum and Base. They are not market-wide.
Counts and amounts as observed, with the scope, coverage and validation state that produced them. Not a forecast, not a momentum signal, and not a characterisation of demand.
⚠ Creation and retirement are GROSS and are never netted into one signed series: a day of heavy churn and a quiet day can net to the same number and are not the same market. USD-denominated debt only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses source limitations, gross vs net treatment ('Creation and retirement are GROSS and are never netted into one signed series'), currency scope ('USD-denominated debt only'), and validation/coverage context, which gives an agent an accurate picture of the data's meaning and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core question and available periods, then follows with necessary caveats. It is slightly lengthy with repeated warnings, but each sentence contributes a meaningful constraint or clarification, so it remains informative without becoming bloated.
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 has no output schema, so the description must explain what the agent can expect. It covers the metrics, periods, source blockchain network, geographic/source scope, units, gross accounting behavior, and non-forecast interpretation. This is sufficient for an agent to understand what the tool will return and how to 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?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter detail for the description to add. The baseline for zero-parameter tools applies, and the description correctly focuses on output semantics rather than invented parameter guidance.
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 identifies what the tool reports: credit created and retired, with coverage windows ('Latest, trailing 30 days, and since inception'). It also distinguishes itself by explicitly stating it is computed from 'MORPHO BLUE ONLY, on Ethereum and Base' and 'not market-wide', helping an agent differentiate it from potentially broader sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the opening question ('How much credit was created and retired...') and provides interpretive exclusions ('Not a forecast, not a momentum signal, and not a characterisation of demand'). However, it does not explicitly name when to prefer this tool over alternatives such as get_credit_state or get_credit_state_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current Bitcoin MVRV ratio: market capitalisation divided by realised capitalisation, where realised cap values each coin at the price it last moved.
MVRV is therefore an identity on observed chain data. It states the aggregate unrealised position of the supply — how far the market values coins above or below what was last paid for them — and nothing about what follows from that. This tool returns data; it does not advise, forecast, or characterise the market.
Computed nightly from Aletheia's own full node and UTXO set. Since 2026-10-05 the current price and the creation prices from 2020-07-13 are Aletheia's own on-chain BTC fixing; coins created before 2020-07-13 are valued at CoinGecko's daily price (price): the supply and each coin's age are Aletheia's, the prices are not. 'mvrv_z_score' is returned alongside it: the same numerator measured in standard deviations of the historical market-cap series.
Returns: { value, mvrv_z_score, as_of, inputs: { market_cap_usd, realised_cap_usd, realised_price_usd, spot_price_usd }, methodology, attribution, disclaimer }. 'attribution' carries the source credit for third-party figures; show it with them.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | No | ISO 8601 date. Currently ignored: the upstream serves the latest computed row only. Historical MVRV is available through get_indicator with include_history. |
What is known about this venue, criterion by criterion? The three pillars — Price, Quality, Composition — each cell with its value and the source it came from.
The criteria are published and versioned before any venue is measured against them, applied evenly to every row, and the spec version rides in this payload. There is no composite score, no stars and no reliability index: a reader weighs the criteria, and this server does not weigh them for the reader.
⚠ 'unknown' is a value, not an omission — a criterion that cannot be established from public sources says so with its reason. A class-specific 'not_applicable' and an unresearched 'unknown' are different answers and are never conflated.
Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. With collateral: 'eth' the criteria come with the venue's ether figures (the six tiles and books); a venue that does not take ether says so.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | Yes | Registry id, e.g. 'aave_v3_arbitrum'. Call list_venues to discover valid ids. | |
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. |
What can be checked about the contracts, and what did the last check return? Observations with their block heights; the verdict is the reader's.
Contract addresses and their implementations, the bytecode hash of each, the upgradeability position, the privileged-function map with whether each can touch user funds, the audit reference, and five structural promises — each with the check that would falsify it and what that check returned.
⚠ Read the fields, not the impression. 'match' is "unchecked" where Aletheia has not compared deployed bytecode against verified source; a promise that did not settle says so; and mainnet and testnet return different answers because they run different builds. There is no safety score, rating or verified badge in this payload, and none will be added.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network. Default 'arbitrum-one' (mainnet). Use 'arbitrum-sepolia' for the testnet deployment, which carries a far deeper book — but note the two run different contract builds, so a testnet observation is not a mainnet fact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It transparently states that 'match' can be 'unchecked' when bytecode comparison hasn't happened, that unresolved promises 'say so,' that mainnet and testnet return different answers due to different builds, and that no safety score/rating/badge exists and none will be added. This goes far beyond basic behavioral description.
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 a purpose sentence, then a detailed contents list, then a warning paragraph. While moderately long, every sentence adds value and the structure is logical. Some redundancy could be trimmed, but it remains well-organized for a complex payload.
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 fully covers what the agent will receive: specific fields, the meaning of key values (including edge cases like unchecked matches and unresolved promises), and network-dependent behavior. It leaves no critical ambiguity for correct invocation.
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 covers 100% of the single parameter (network) with enumeration and a default. The description adds meaningful context: testnet carries a 'far deeper book' and the two networks run different builds, so a testnet observation isn't a mainnet fact. This enriches the parameter's semantics 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?
The description states the tool's purpose as returning what can be checked about contracts and the last check's results, then enumerates the specific contents: addresses, implementations, bytecode hashes, upgradeability position, privileged-function map, audit reference, and five structural promises. It clearly differentiates from a verdict-provider by saying 'the verdict is the reader's,' making its scope precise.
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 gives no explicit when-to-use vs. alternatives, but it does provide practical usage context: it warns about interpreting 'match' as unchecked where bytecode hasn't been compared, notes that mainnet and testnet differ, and advises reading fields rather than impressions. This is helpful but not a comprehensive usage guide or alternative exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every series served from Aletheia's vintage store: the chain series built from one pass over every Bitcoin block on Aletheia's own node (chain.cohort.: supply, supply by age band, long- and short-term holder supply, BTC moved, coin-days destroyed, dormancy, realised cap and price, MVRV, SOPR, supply in profit and loss, cost-basis percentiles), the miner series (miner.: blocks, transactions, subsidy, fees, difficulty, hashrate, hashprice), the on-chain BTC/ETH/TRX price fixings and staked-ether contract rates (price.), and the Federal Reserve H.10 exchange rates (fx.).
Returns: { count, series: [{ id, dataset, unit, kinds, first, last, latest_vintage, licence }] }. licence 'free_attributed_only' marks series with values priced from CoinGecko before 2020-07-13.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Returns the catalogue of Aletheia indicators measured across the Bitcoin-collateralised credit markets and the Bitcoin chain: id, name, family, units, description, and whether the indicator is currently live on this network.
Three families: 'credit' (credit-market assessments), 'onchain' (commodity chain metrics such as MVRV and SOPR), and 'market' (external context — DeFi rates, stablecoin supply, macro).
Use this to discover what is available, then call get_indicator with an id. This tool returns a catalogue; it does not rank indicators or advise which to use.
Indicators anchored on a single venue's own rate are not served here; they are listed as withheld, with the server that serves them.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Restrict to one family. Omit to return the whole catalogue. | |
| live_only | No | If true, omit indicators that are not currently live on this network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full disclosure burden and does a strong job: it names the returned fields, defines the three family categories, states that only live indicators can be filtered via 'live_only', and explains that some indicators are deliberately withheld and listed with a server. It stops short of disclosing operational details such as pagination or response shape, but those are minor for a catalogue tool.
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 and return content, then organises family definitions, usage guidance, and limitations into compact sentences. Every sentence contributes new information; there is no filler or repetition.
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 there is no output schema and no annotations, the description is remarkably complete: it covers return fields, family taxonomy, the live flag, the discovery workflow, and the withheld-indicator caveat. The only contextual gap is not explicitly positioning this tool against list_onchain_indicators, but the three-family scope makes the distinction inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value by defining what each family means ('credit', 'onchain', 'market' with concrete examples like MVRV and SOPR) and by explaining the meaning of 'live' in context. It also explains the withheld-indicator behavior, which clarifies how results are organised.
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 opening sentence states a specific verb ('Returns') and resource ('catalogue of Aletheia indicators') and enumerates the exact fields returned, so an agent knows what this tool produces. It also distinguishes itself from get_indicator by saying to discover first here and then call get_indicator with an id, and by disclaiming ranking/advising behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover what is available, then call get_indicator with an id' and clarifies that it does not rank or advise, which is useful when/not-to guidance. It does not, however, contrast itself with the overlapping sibling list_onchain_indicators, so the when-to-use guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the catalog of available on-chain indicator tools, including tool name, indicator name, brief description, units, an example invocation, and current readiness status ('live' or 'pending'). Use this when you need to discover which tools are available for on-chain analysis without inspecting every tool definition.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates this is a read-only catalog operation and describes the return contents, including readiness status. It does not discuss caching, staleness, or whether statuses update dynamically, but those are minor for a discovery tool.
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 with no wasted words. The first sentence states the action and the catalog contents, and the second provides the exact usage scenario. Everything included 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?
For a zero-parameter discovery tool with no output schema, the description is complete: it names the resource, the fields returned, and the readiness status values. An agent can decide whether to call this tool without needing additional 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 and the schema is empty, so there are no parameters to document. Baseline 4 applies because no parameter information is needed; the description appropriately focuses on the return value instead.
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 clear verb and resource: returns the catalog of available on-chain indicator tools with specific fields like tool name, units, and readiness status. It does not explicitly differentiate itself from the sibling list_indicators, but the on-chain scoping and catalog description make the purpose understandable.
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 says to use this when needing to discover which on-chain analysis tools are available without inspecting every tool definition. It gives clear context for use, though it does not mention alternatives or cases where listing tools would not be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which credit venues does this dataset cover, and what is known about each? Returns the registry rows matching the filters you supply.
One row per venue across four classes — on-chain protocols, CeFi desks, the corporate layer, and auction venues — each carrying its coverage state per pillar and how many of its criteria cells have been researched. Does not rank, score or order by any rate: rows are returned in the registry's own order. All filters are optional and unspecified means no constraint.
⚠ A venue's presence is not a statement about it. Coverage 'none' means nothing is ingested yet, which is a declared gap, not an observation about the venue.
Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. With collateral: 'eth' only the venues that take ether as collateral are returned (a venue taking both appears under both).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cap the rows returned. Default 50. The response always states the unfiltered total. | |
| status | No | Restrict by registry status: 'live', 'ingesting', 'registered', 'unresolved', 'defunct'. | |
| chain_id | No | Restrict to venues on one EVM chain id. | |
| collateral | No | Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin. | |
| venue_type | No | Restrict to one class, e.g. 'onchain_pooled', 'cefi_desk', 'corporate_debt', 'auction'. | |
| complete_attributes_only | No | Only venues whose criteria cells are fully researched (8 of 8). Default false. |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_indicator1 field changedInput schema / properties / id / descriptionPrevious value: -"Indicator id from list_indicators, e.g. 'intermediation-spread', 'benchmark-curves', 'onchain-latest'."New value: +"Indicator id from list_indicators, e.g. 'intermediation-spread', 'capital-stack', 'benchmark-curves'."get_indicator1 field changedInput schema / properties / id / descriptionPrevious value: -"Indicator id from list_indicators, e.g. 'tci', 'tsr', 'cdr'."New value: +"Indicator id from list_indicators, e.g. 'intermediation-spread', 'benchmark-curves', 'onchain-latest'."get_chain_seriesget_cost_basislist_chain_seriescompare_venues1 field changedInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}get_credit_state2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}get_credit_state_history1 field changedInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}get_market_composition2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}get_venue1 field changedInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}list_venues1 field changedInput schema / properties / collateralAdded value: +{
+ "description": "Bitcoin by default; pass collateral: 'eth' for credit secured by ether (ether, staking and restaking tokens at their own contract rates), measured the same way and never added to bitcoin.",
+ "enum": [
+ "btc",
+ "eth"
+ ],
+ "type": "string"
+}get_liquidation_mapcompare_venues5 fields changedInput schema / properties / classAdded value: +{
+ "description": "Restrict to one credit class. The full matrix is ~160 rows; one class is far lighter.",
+ "enum": [
+ "algorithmic",
+ "minted",
+ "auction",
+ "posted-card",
+ "corporate"
+ ],
+ "type": "string"
+}Input schema / properties / collateralRemoved value: -{
- "description": "Collateral asset symbol, e.g. 'BTC'.",
- "type": "string"
-}Input schema / properties / denominationRemoved value: -{
- "description": "Loan denomination, e.g. 'USD'.",
- "type": "string"
-}Input schema / properties / sideAdded value: +{
+ "description": "'borrow' (what a borrower pays, the default) or 'lend' (what a capital provider earns).",
+ "enum": [
+ "borrow",
+ "lend"
+ ],
+ "type": "string"
+}Input schema / properties / venuesAdded value: +{
+ "description": "Comma-separated registry ids to restrict the rows to, e.g. 'aave_v3_ethereum,cefi_ledn'.",
+ "type": "string"
+}compare_venuesget_credit_stateget_credit_state_historyget_indicatorget_lensget_market_compositionget_market_flowsget_mvrvget_venueget_verification_bundlelist_indicatorslist_onchain_indicatorslist_venuesOracle-free fixed-rate, fixed-term BTC credit on Arbitrum One. Data and unsigned blueprints.
Cross-chain markets: prices, DeFi TVL, yields, stablecoins, gas, order books, perps funding.
Bitcoin and macro market briefings for AI agents: trend signals, regimes, liquidity and ETF flows.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Add one secure layer between your agents and this server.
