The Bitcoin credit markets, measured. Cross-venue rates, venue criteria, chain indicators.
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. | |
| collateral | No | Collateral asset symbol, e.g. 'BTC'. | |
| tenor_days | No | Loan term in days to compare at. | |
| denomination | No | Loan denomination, e.g. 'USD'. |
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. It does this well by stating the output shape (one row per venue in coverage-matrix order) and explicitly ruling out ranking, default sorting, and 'best' selection. It does not mention side effects or permissions, but for a comparison/query tool this is reasonable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core purpose front-loaded and the key output behavior stated next. Every sentence adds useful information and there is no padding.
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 four optional params, no output schema, and no annotations, the description provides the essential behavioral guarantees: one row per venue, fixed coverage-matrix order, and no ranking. It could be slightly stronger by defining 'coverage-matrix order' or clarifying what a row contains, but it is sufficient for an agent to understand the tool's role.
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 parameters are already fully documented in the input schema. The description adds context by framing the query around tenor and LTV, but it does not add meaning beyond the schema for collateral or denomination.
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 what the tool does: it reports credit cost at a given tenor and LTV across every venue Aletheia covers. It also distinguishes the tool from siblings by explicitly saying output is one row per venue with no ranking or default sort, which separates it from singular venue tools like get_venue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for cross-venue credit-cost comparison. However, it does not explicitly state when to use it versus alternatives such as get_venue or list_venues, nor does it provide exclusion criteria.
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 provided, the description carries the full behavioral burden and does so exceptionally well. It discloses that 'match' may mean 'unchecked', that unverified claims will be shown rather than silently omitted, that mainnet and testnet can return different answers due to different builds, and that no safety score or badge exists. This prevents serious misinterpretation of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but it is organized into a clear overview, a detailed field list, and a necessary caveat section. Every sentence contributes meaningful information; the warning about reading fields rather than impressions is especially valuable. It is somewhat dense but appropriate for a tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description must fully orient the agent, and it does: it enumerates the payload categories, explains the falsification-check semantics, and highlights the most dangerous misunderstanding (treating 'match' as verified). Nothing critical for a correct call or interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema coverage, so the baseline is 3, but the parameter description adds real meaning beyond the enum: it explains the default network, the testnet use case, and the fact that different builds mean different results. The main description reinforces this with a warning about mainnet and testnet divergence, going well beyond structured schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('verification bundle') and clearly states what it contains: observations, contract addresses, bytecode hashes, upgradeability, privileged functions, audit references, and structural promises. It opens with a concrete question, 'What can be checked about the contracts, and what did the last check return?', making the tool's purpose immediately clear and distinct from the unrelated 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?
No explicit alternative tools are named, but the description gives clear guidance on when to use each network and why: 'Use arbitrum-sepolia for the testnet deployment, which carries a far deeper book' and warns that testnet observations are not mainnet facts. This provides usable context and an important exclusion, even though it does not compare against sibling tools.
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. Dates show when Glama detected each change.
compare_venuesget_credit_stateget_credit_state_historyget_indicatorget_lensget_market_compositionget_market_flowsget_mvrvget_venueget_verification_bundlelist_indicatorslist_onchain_indicatorslist_venuesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Oracle-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.
Crypto and DeFi benchmarks: gas fees, chain TVL, stablecoin yields, options IV, and correlations.
Add one secure layer between your agents and this server.
Most tools have clearly distinct scopes: compare_venues is per-venue pricing, get_credit_state is a cross-venue aggregate, and get_market_composition/get_market_flows are explicitly Morpho Blue-only. The main ambiguity is between list_indicators and list_onchain_indicators, which overlap significantly since the former already includes an onchain family.
Tool names consistently follow a lowercase snake_case verb_noun pattern: get_credit_state, get_venue, list_indicators, list_venues. compare_venues is the only non-get/list verb but still fits the verb_noun convention, so the set reads predictably.
Thirteen tools is well within the ideal 3-15 range for a read-only market-data server. Each tool covers a distinct retrieval need: aggregates, histories, venue details, indicators, verification, market composition, flows, and presentation lenses.
The server covers discovery and lookup well: list_indicators/get_indicator, list_venues/get_venue, aggregate credit state with history, market composition/flows, MVRV, verification bundles, and lenses. Minor gaps exist: list_onchain_indicators implies multiple onchain indicator tools but only get_mvrv is actually exposed, and there is no historical series for market composition or flows.
