The Bitcoin credit markets, measured. Cross-venue rates, venue criteria, chain indicators.
Scored across 13 tools
The core market-state, venue, and verification tools are mostly well separated, and the detailed scope warnings help differentiate get_credit_state, get_market_composition, and compare_venues. However, the indicator area is muddled: list_indicators already covers on-chain indicators while list_onchain_indicators repeats a subset, and get_mvrv overlaps with what get_indicator could return as an on-chain indicator. These redundancies create real misselection risk.
Every tool follows a clean verb_noun snake_case pattern using only get, list, and compare. Singular and plural object names vary appropriately by resource, and there is no camelCase or inconsistent verb style.
Thirteen tools is within a reasonable range for a read-only analytics server covering venue registry, market state, flows, composition, indicators, and verification bundles. The count is slightly inflated by redundant indicator-surface tools such as list_onchain_indicators and get_mvrv, but most tools do earn their place.
The server covers the domain well: venue discovery and detail, market state and history, flows, composition, comparisons, verification bundles, indicator catalogues and retrieval, and presentation lenses. Minor gaps exist, such as the lack of a single uniform indicator history endpoint and the fact that some on-chain indicators are only reachable via get_indicator rather than dedicated tools, but the surface is broadly complete for a read-only data service.
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'. | |
| tenor_days | No | Loan term in days to compare at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: output is one row per venue, in coverage-matrix order, with no ranking, default sort, or 'best' recommendation. This meaningfully sets output expectations.
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 followed by a precise clarifying clause. Every phrase earns its place, and the critical ordering caveat is included without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, it covers selection context and return shape: one row per venue in coverage-matrix order. It doesn't define 'coverage-matrix order' or the units of credit cost, but parameter details are fully handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces 'tenor and LTV' as the core comparison dimensions but adds no parameter-level detail beyond what the schema already provides.
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 the tool's purpose: compare credit cost across every venue at a given tenor and LTV. The 'one row per venue' detail and the 'no ranking, no default sort, no best' caveat strongly distinguish it from ranking or venue-listing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly conveys when to use the tool: when the user wants credit cost across all Aletheia-covered venues at a specified tenor and LTV. It doesn't name alternatives or state when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 of behavioral disclosure, and it does so thoroughly. It reveals that the result is aggregated, that no venue is individually reported, and that absent venues are 'a declared gap, not a zero.' It also explains that unavailable rows are counted separately, which is exactly the kind of caveat an agent needs to avoid misinterpreting 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 organized into a clear question, an explanatory summary, and a crucial warning. It is slightly verbose in places ('weighted up, floated or reported under its own heading'), but every sentence contributes useful meaning. The important coverage warning is bolded and placed at the end, making it memorable.
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 parameterless read-only aggregation tool with no output schema, the description gives enough detail about what is returned: term structure, outstanding quantity, valuation, collateral mix, quality composition, and a coverage block. It does not spell out the exact output shape, but that is less critical given the rich content description and zero input requirements.
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 100% schema description coverage, so the schema already fully documents the input surface. The description adds value by explaining what the single parameterless reading contains and what dimensions are covered, going beyond the empty schema. This matches the baseline for zero-parameter tools.
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 exactly what the tool does: it reports the cost and outstanding amount of Bitcoin-collateralised credit aggregated across the covered venue universe. It clearly differentiates itself from single-venue tools by saying it is 'not any single venue's book.' The description also enumerates the specific content carried (term structure, outstanding quantity, valuation, collateral mix, quality composition).
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 establishes clear usage context: use this for an aggregate current reading across venues, not for any one venue's detailed book. It gives explicit instructions to 'read coverage before reading the figures,' which is practical usage guidance. It does not name sibling alternatives explicitly, but the context is clear enough for a capable agent to select the tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days of history. Default 365, capped at 3650. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the transparency burden and does it well: it discloses that each point carries per-point coverage, coverage is not constant, and a movement can reflect venue observation changes rather than market moves. It also clarifies that the data is descriptive and non-predictive.
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 compact and front-loaded with a clear question plus the key get_credit_state comparison. The coverage warning is repeated in slightly different ways across two paragraphs, but the repetition is purposeful and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter historical tool with no output schema, the description provides the essential context: daily series, per-point coverage, and how to interpret changes. It does not spell out the exact return shape (e.g., array of date/value/coverage objects), but the series language and reference to get_credit_state make the calling intent clear.
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 sole parameter, days, is fully described in the input schema with default and bounds, so schema description coverage is 100%. The description adds no additional parameter semantics, which is acceptable and lands at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource ('Bitcoin credit surface'), the format ('daily series'), and explicitly ties it to the sibling get_credit_state so an agent can tell historical from current-state tools. The rhetorical opening is reinforced by a concrete comparison to get_credit_state.
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 makes the historical, daily-series usage explicit and references get_credit_state as the non-series counterpart. It explicitly excludes forecasting and trend characterization, but it does not enumerate other sibling alternatives or state a crisp 'use this when...' condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'tci', 'tsr', 'cdr'. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does well: it discloses that history is free and unmetered, that the data is descriptive and carries no recommendation, and that missing readings are reported explicitly rather than as null or zero. It does not cover every possible behavior, but the most decision-relevant traits are clearly surfaced.
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 well-structured: the primary behavior is in the first sentence, followed by scope clarification, prerequisite, optional behavior, and edge-case semantics. Every sentence contributes useful information, and there is no redundancy or 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?
Given the absence of annotations and output schema, the description compensates well by explaining the return semantics, the venue-pointer behavior, the free history option, and the non-null handling of missing readings. An agent has enough context to select and invoke the tool correctly, and the schema covers parameter details.
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 schema already documents all four parameters. The description adds only modest semantic value by clarifying that include_history switches the return to a historical series and that from/to are only meaningful with it, but this largely reinforces schema text rather than going substantially beyond it.
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 the current value of a single Aletheia indicator by id, with its methodology reference.' It further distinguishes this server's venue-independent indicator set from venue-owned indicators, which helps an agent understand exactly what this tool is for and how it differs from related 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 explicitly instructs the agent to call list_indicators first to discover valid ids, which is a clear prerequisite. It also states that venue-anchored indicators are served by that venue's own MCP and answered here with a pointer, effectively telling the agent when this tool is not the right one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
| 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 behavioral burden and largely succeeds. It discloses the narrow data scope, naming missing venues and their ingestion status, plus the absence of ranking or judgement. It does not describe the response format or whether shares are normalized, but the caveats are substantial and decision-relevant.
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 longer than average but every sentence adds interpretive value, and the key warning is front-loaded. The repeated emphasis on scope justifies its length; minor redundancy exists between 'no ranking' and 'no judgement'.
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 is fairly complete: it explains what is measured, the scope, and how to read results safely. It could mention the response shape or whether shares sum to 100%, but an agent can correctly interpret the tool's output and caveats from this description alone.
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 empty input schema, so there is nothing to document; the baseline of 4 applies. The description correctly focuses on output interpretation rather than parameter details.
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 reports credit market composition by rate type, recourse, and instrument, as observed shares. It differentiates the output by explicitly saying it is not a ranking and is limited to a specific venue family, though it does not name a sibling tool as an alternative.
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 gives clear context for interpreting results: the data is Morpho Blue only, on Ethereum and Base, not market-wide, and the scope block must be read before quoting shares. It does not explicitly say when to choose this tool over siblings like compare_venues, but it provides enough exclusionary guidance to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '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, disclaimer }.
| 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. |
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 states the tool is computed nightly from Aletheia's own node and UTXO set, explicitly says it returns data and does not advise or forecast, and lists the full return shape. This is strong transparency for a read-only data 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 well organized: purpose first, then calculation rationale, then caveats, then return object. Every sentence adds distinct value—methodology, limitations, and output shape—without 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?
There is no output schema, so the description compensates by enumerating the exact returned fields and the inputs used. The tool has only one optional ignored parameter, and the description explains that and the alternative for historical queries, making it complete for 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 coverage is 100%, so the baseline is 3. The description reinforces the current-only behavior and the ignored timestamp, but the parameter semantics are already fully documented in the schema; the description adds little beyond that.
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 the current Bitcoin MVRV ratio' and precisely defines the calculation. It also distinguishes itself from a sibling by noting that historical MVRV is available through get_indicator with include_history.
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 states that the timestamp parameter is currently ignored and the upstream serves only the latest computed row, then points to get_indicator for historical data. This gives an agent clear direction on when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_id | Yes | Registry id, e.g. 'aave_v3_arbitrum'. Call list_venues to discover valid ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it clarifies there is no composite score/stars/reliability index, that 'unknown' is a meaningful value, and that 'not_applicable' versus 'unknown' are distinct. It also notes the criteria are versioned and the spec version is in the payload, which is useful behavioral context beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and front-loads the primary output, then adds necessary interpretive caveats. Some phrasing is slightly elaborate, but each section earns its place and the key information is not buried.
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 description is complete enough for a single-parameter read tool with no output schema: it explains what is returned, how values are sourced, that no composite score is provided, and how special values behave. Minor omissions like response format are not critical given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains venue_id with an example and a pointer to list_venues. The description adds no additional parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a criterion-by-criterion assessment of a single venue across the three pillars (Price, Quality, Composition), including values and sources. The title 'One venue against the published criteria' and the contrast with the sibling compare_venues helps distinguish it from other venue-related 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 tool's purpose implies use for a single venue rather than comparison, but it does not explicitly state when to use this tool versus alternatives such as compare_venues or list_venues. Usage context is present but not made explicit through when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: one row per venue, four venue classes, per-pillar coverage state, researched criteria counts, registry order, no ranking, optional filters, and a caution that presence does not imply a statement about the venue. This is thorough behavioral disclosure.
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, then orders supporting details logically: row granularity, ordering behavior, filter semantics, and a necessary caveat. Every sentence earns its place without 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 filtered list tool with no required parameters and a fully documented schema, the description is complete. It covers what rows represent, ordering, filter optionality, response total, and interpretive guardrails, so an agent can invoke it correctly without 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?
Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds general guidance that all filters are optional and non-constraining by default, but it does not add significant per-parameter meaning beyond what the schema provides.
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 direct question and states a specific verb and resource: it returns registry rows for credit venues matching supplied filters. It clearly establishes the list/registry nature, differentiates from singular lookup and comparison siblings by emphasizing multiple rows, classes, and no ranking.
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 gives clear usage context: query the dataset's venue coverage, filters are optional, and unspecified means no constraint. It does not explicitly name sibling alternatives like get_venue or compare_venues or state when not to use this tool, so it stops short of a full 5.
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.
compare_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.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Evidence-based market data for AI agents deploying capital in DeFi. Empirical, not advertised.
Real-time crypto asset intel for trading AIs: liquidity grades, transfer routes, spreads, BTI
Add one secure layer between your agents and this server.
