Crypto and DeFi benchmarks: gas fees, chain TVL, stablecoin yields, options IV, and correlations.
Live TVL by blockchain — Ethereum, Base, Solana, Arbitrum, and 50+ chains from DeFiLlama. Rankings, 1D and 7D change, protocol counts, Ethereum dominance, and Base vs ETH TVL comparison for x402 agent context.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, conveying a safe read operation. The description adds beyond this by identifying DeFiLlama as the data source, indicating 'live' data, and enumerating the metrics returned (e.g., Ethereum dominance, Base vs ETH comparison), which enriches behavioral understanding.
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 that begins with the core action ('Live TVL by blockchain') and packs all relevant details—chains, source, metrics—without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional params and no output schema, the description lists the key return metrics and data source, giving a solid idea of the output. Minor omissions like default sorting or response format do not detract significantly given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter explanation. It implicitly maps to sort_by through '1D and 7D change' and 'Rankings', but does not explicitly explain the limit parameter. Given only two simple optional parameters, the partial compensation is adequate but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides live TVL by blockchain, lists specific chains (Ethereum, Base, Solana, Arbitrum, 50+), and details metrics like rankings, 1D/7D change, protocol counts, and dominance. This differentiates it from sibling benchmark tools such as gas, yield, or correlation benchmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for obtaining TVL comparisons and mentions the 'x402 agent context' as a use case, providing clear context. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
30-day rolling correlation matrix for BTC, ETH, and SOL — Pearson correlation pairs, beta to BTC, dominance context, and portfolio diversification signal. Source: DeFiLlama historical prices. For crypto portfolio agents. Live source. Returns HTTP 503 (no charge) if upstream source unavailable for >50% of fields. | x402 SLA: $0.10 USDC per call. Returns HTTP 503 (no charge) when upstream data sources unavailable. data_source field discloses provenance (fred_api/fred_csv/fred_mixed).
| Name | Required | Description | Default |
|---|---|---|---|
| period | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint and destructiveHint annotations: it discloses HTTP 503 responses with no charge when upstream sources are unavailable, an SLA of $0.10 USDC per call, and a data_source field for provenance. The repeated 503 sentence and irrelevant FRED provenance mention detract slightly, but the disclosure is substantial.
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 front-loads the core purpose but becomes repetitive, with two identical statements about HTTP 503 behavior and an out-of-place reference to 'fred_api/fred_csv/fred_mixed' that is irrelevant to crypto. These redundancies and inconsistencies make it longer than necessary without adding value.
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 covers the output components (Pearson pairs, beta, dominance, diversification signal), source, error behavior, and cost, which is good for a tool without an output schema. However, it fails to explain the only parameter (period), and the duplicate 503 text plus FRED provenance error leave gaps in the tool's operational semantics.
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 one optional parameter 'period' with an enum of 7d/30d/90d, yet the description never explains this parameter. It mentions '30-day rolling' as a fixed attribute, which conflicts with the parameter's ability to vary the window. With 0% schema description coverage, the description should compensate but does not.
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's function with a specific verb and resource: it computes a 30-day rolling correlation matrix for BTC, ETH, and SOL, including Pearson pairs, beta, dominance, and diversification signals. This distinguishes it from sibling benchmark tools, which focus on different asset classes or metrics.
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 implicitly targets 'crypto portfolio agents' and mentions a live source, giving some usage context. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DAO treasury benchmarks — top DAOs by treasury size, stablecoin percentage, runway, and governance token concentration. Median benchmarks: $550M treasury, 61% stablecoin, 48-month runway. Source: DeepDAO public data.
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | ||
| min_treasury_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds context on the data source (DeepDAO public data) and the specific metrics included, which is valuable beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that get straight to the point. No filler or redundant information.
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 is simple with two optional parameters and no output schema. The description covers the output's content and source, but it fails to explain the parameters, leaving a gap for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions for either parameter (0% coverage). The description does not mention sort_by or min_treasury_usd, so an agent cannot infer their meaning or usage from the description.
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 providing DAO treasury benchmarks with specific metrics (treasury size, stablecoin percentage, runway, and governance token concentration). It distinguishes from sibling benchmark tools by specifying the DAO treasury domain.
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 clear context that this tool is for DAO treasury benchmarks, allowing an agent to select it when relevant. However, it does not explicitly compare with sibling benchmarks or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DeFi lending and stable yield benchmark from DeFiLlama Yields — top pools by APY with p25/p50/p75 APY bands, TVL, chain, and pool id. Optional protocol (project slug substring) and/or asset (symbol substring). With no filters, universe is stablecoin-marked pools (typical lending / money-market supply). Free public API, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Filter by pool symbol substring, e.g. USDC, DAI, ETH | |
| protocol | No | Filter by DeFiLlama project slug substring, e.g. aave-v3, compound-v3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: 'Free public API, no key' indicates no authentication required, and 'With no filters, universe is stablecoin-marked pools' discloses the default selection behavior. This goes beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: core benchmark definition, filter options, and API access details. Information is front-loaded and there is no waste or redundancy. The structure is ideal for agent consumption.
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 read-only tool with two optional string parameters, the description covers the data source, output contents, default behavior, and authentication requirements. It omits details like exact response format or potential rate limits, but given the tool's simplicity and strong annotations, this is adequately complete for reliable 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 both parameters are already documented as substring filters. The description echoes the same semantics ('project slug substring', 'symbol substring') without adding new meaning beyond the schema. The default universe explanation slightly enhances understanding but does not materially extend parameter semantics.
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: 'DeFi lending and stable yield benchmark from DeFiLlama Yields' and enumerates concrete outputs (top pools by APY with p25/p50/p75 APY bands, TVL, chain, pool id). This clearly distinguishes it from siblings like get_stablecoin_yield_benchmark by specifying the benchmark universe and data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states optional filters (protocol and asset substrings) and explains the default universe when no filters are applied ('stablecoin-marked pools'). It does not explicitly name alternatives or exclusions, but the contextual guidance is sufficient for an agent to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live gas price benchmarks for Ethereum, Base, and Solana. Returns Gwei, USD cost per transfer type, congestion category, and x402 agent economy context. Base vs ETH savings comparison. Source: public chain RPCs. Zero API key required. | x402 SLA: $0.10 USDC per call. Returns HTTP 503 (no charge) when upstream data sources unavailable. data_source field discloses provenance (fred_api/fred_csv/fred_mixed).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: zero API key required, x402 SLA cost of $0.10 USDC, HTTP 503 without charge on upstream failures, and data_source field disclosing provenance. This goes well beyond annotations and gives the agent clear expectations for cost, failure, and data origin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then provides essential details (returns, source, cost, failure behavior) in a compact but complete manner. Every sentence adds value with no fluff or 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?
Despite having only one parameter and no output schema, the description is highly complete: it states what data is returned (Gwei, USD cost, congestion, agent context), the source (public RPCs), cost, and failure response. No critical context is missing for an agent to decide invocation and interpret results.
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 0%, so the description must compensate. It indirectly covers the chain parameter by naming Ethereum, Base, and Solana, which align with the enum values, but it does not explicitly explain the 'chain' parameter or the 'all' option. The enum is self-explanatory, and the description provides partial semantic support, earning a baseline 3.
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 'Live gas price benchmarks for Ethereum, Base, and Solana' with specific verb and resource, and distinguishes it from sibling benchmark tools by focusing on gas prices. It lists exact outputs (Gwei, USD cost, congestion category), leaving no ambiguity about the tool's purpose.
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 context by naming the supported chains and mentioning x402 agent economy context, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools are clearly different benchmarks, so a user can infer when to use it, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto options implied volatility benchmarks — BTC and ETH 7D/30D IV, put/call ratio, fear/greed signal, term structure shape, and VIX comparison. Source: Deribit public API + FRED. For options traders and volatility agents. Live source. Returns HTTP 503 (no charge) if upstream source unavailable for >50% of fields. | x402 SLA: $0.10 USDC per call. Returns HTTP 503 (no charge) when upstream data sources unavailable. data_source field discloses provenance (fred_api/fred_csv/fred_mixed).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description does not contradict this. It adds valuable behavioral context about HTTP 503 responses when upstream data is unavailable, SLA pricing, and provenance disclosure via data_source field—all beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly efficient but contains redundant statements about HTTP 503 behavior (appears twice). It is front-loaded with purpose and key details, but the duplication makes it slightly less polished than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists the key metrics returned (IV, put/call ratio, fear/greed, term structure, VIX) and mentions the data_source field for provenance. It also covers failure modes and SLA. This is fairly complete for a data-retrieval tool, though minor details like units are omitted.
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 schema has one parameter `asset` with enum values BTC/ETH/all, and schema coverage is 0%. The description mentions BTC and ETH in the metric list, which implies the asset selection, but it never directly explains the `asset` parameter or how to use it. The enum schema carries most of the burden, but the description adds some context about the covered assets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides crypto options implied volatility benchmarks for BTC and ETH, listing specific metrics (7D/30D IV, put/call ratio, fear/greed, term structure, VIX). This is specific and distinguishes it from sibling benchmark tools like TVL or yield.
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 says 'For options traders and volatility agents,' implying the target user but not explicitly stating when to prefer this over alternatives. It does not mention exclusions or sibling comparisons, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-world asset tokenization benchmarks — tokenized T-bill yields (Ondo, BlackRock BUIDL, Superstate, Franklin Templeton), RWA market TVL by category, YoY growth. $12.8B total RWA market. Source: DeFiLlama + public data.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so the description adds valuable context beyond that: it reveals the source (DeFiLlama), the included metrics (T-bill yields, TVL, YoY growth), and a concrete market size. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and adds specific details without redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description covers the data contents and source but omits the category parameter behavior and does not describe the output format. Adequate but with notable gaps.
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 description does not mention the `category` parameter at all, despite the schema having 0% description coverage. It uses the phrase 'by category' but never maps that to the input parameter or its enum values, leaving the agent to guess how filtering works.
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 a specific resource: real-world asset tokenization benchmarks, with concrete data points like tokenized T-bill yields and TVL by category. This distinguishes it from sibling benchmark tools such as get_chain_tvl_benchmark or get_crypto_correlation_benchmark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for RWA-related metrics and quotes specific data categories, but it does not explicitly state when to choose this tool over alternatives or provide exclusions. The inclusion of specific examples makes the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stablecoin lending yield benchmarks — USDC/USDT/DAI supply APY across Aave, Compound, Morpho, Spark by chain. p25/p50/p75 bands, TVL filter, and spread vs 3-month T-bill. Source: DeFiLlama + FRED. Live source. Returns HTTP 503 (no charge) if upstream source unavailable for >50% of fields.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/destructiveHint annotations, the description discloses the live data source, the HTTP 503 error behavior with no charge on upstream unavailability, and data provenance (DeFiLlama + FRED). This adds substantial operational context beyond what annotations provide.
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 information-dense but structured with clear fragments: benchmark scope, output metrics, data sources, and error behavior. Every phrase contributes value 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?
Given there is no output schema, the description adequately describes the return data (APY, p25/p50/p75 bands, spread vs T-bill) and the tool's behavior (live source, 503 on upstream failure). It is complete for a simple read-only benchmark tool with one parameter.
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 schema has one parameter (asset) with no description (0% coverage). The description lists the stablecoins covered (USDC/USDT/DAI) and implies the asset filter, but does not explicitly explain the 'asset' parameter, the 'all' option, or the mismatched 'TVL filter' mention without a corresponding schema parameter.
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 specifies a specific verb+resource: provides stablecoin lending yield benchmarks for USDC/USDT/DAI across named protocols (Aave, Compound, Morpho, Spark) and by chain. It distinguishes itself from sibling tools by focusing specifically on stablecoin yields.
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 its use for stablecoin yield data but does not explicitly state when to choose it over sibling tools like get_defi_yield_benchmark, nor does it provide exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE — Returns the complete Stratalize tool catalog: governed MCP tools across finance, healthcare, governance, real estate, crypto, and intelligence. Available via public MCP (no auth) or x402 micropayments on Base ($0.02 atomic · $0.10 benchmark · $0.50 synthesis · $1.00 premium · $3.00 outcome pack). Org intelligence, agent governance, and role briefs require OAuth. Call this first to discover tools by role or vertical.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds substantial context beyond that, including access methods (public MCP no auth, x402 micropayments on Base with exact pricing tiers, and OAuth for specific features). This discloses authentication requirements and cost implications, which are valuable behavioral traits.
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 'START HERE' and immediately states the purpose. It then efficiently lists access methods and pricing in a structured format, followed by a direct call-to-action. Every sentence provides actionable information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only catalog tool, the description fully covers purpose, access, pricing, and usage timing. Since there is no output schema, the description sufficiently implies the return value (a catalog) through its explicit statement. It is complete for the tool's intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered. The description adds context about the tool's role as a discovery catalog, but no parameter-level detail is needed. Baseline 4 is appropriate per the rubric for 0-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 clearly states the tool 'Returns the complete Stratalize tool catalog' with a specific verb and resource. It also distinguishes itself from sibling benchmark tools by serving as the entry-point discovery tool, making its purpose unambiguous.
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 'START HERE' and 'Call this first to discover tools by role or vertical,' providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools for exclusions, so it falls short of a perfect 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.
get_chain_tvl_benchmarkget_dao_treasury_benchmarkget_defi_yield_benchmarkget_gas_benchmarkget_options_iv_benchmarkget_rwa_benchmarkget_stablecoin_yield_benchmarkget_crypto_correlation_benchmarkget_chain_tvl_benchmarkget_crypto_correlation_benchmarkget_dao_treasury_benchmarkget_defi_yield_benchmarkget_gas_benchmarkget_options_iv_benchmarkget_rwa_benchmarkget_stablecoin_yield_benchmarkget_stratalize_overviewget_adoption_stageget_ai_consensus_on_topicget_aml_regulatory_benchmarkget_asc_benchmarkget_audit_fee_benchmarkget_bank_financial_intelligenceget_bank_regulatory_benchmarkget_billing_coding_riskget_bls_inflation_componentsget_bls_sector_employmentget_brand_momentumget_cac_benchmarkget_cap_rate_benchmarkget_category_ai_leadersget_category_disruption_signalget_category_spend_benchmarkget_cfpb_complaint_intelligenceget_climate_risk_benchmarkget_climate_risk_scoreget_cms_facility_benchmarkget_cms_open_payments_profileget_cms_star_ratingget_colorado_ai_act_requirementsget_commodity_benchmarkget_company_salary_disclosureget_competitive_displacement_signalget_construction_cost_benchmarkget_consumer_sentiment_benchmarkget_corporate_debt_benchmarkget_cra_performance_ratingsget_cre_debt_benchmarkget_credit_spread_benchmarkget_credit_union_benchmarkget_development_pro_forma_benchmarkget_dol_labor_violationsget_earnings_quality_benchmarkget_ehr_cost_per_bedget_eia_energy_public_snapshotget_elliott_wavesget_employer_h1b_wagesget_esg_benchmarkget_eu_ai_act_coverageget_fda_recall_historyget_federal_contract_intelligenceget_federal_court_casesget_fomc_rate_probabilityget_ftc_enforcement_historyget_fx_rate_benchmarkget_github_ecosystem_intelligenceget_global_equity_benchmarkget_gpo_contract_benchmarkget_healthcare_category_intelligenceget_healthcare_vendor_market_rateget_hospital_care_compare_qualityget_hospital_supply_chain_benchmarkget_housing_supply_benchmarkget_hud_fair_market_rentget_imf_weo_macro_snapshotget_industry_spend_benchmarkget_industry_spend_profileget_inflation_benchmarkget_insurance_benchmarkget_investment_category_signalget_irs_industry_tax_statisticsget_labor_market_benchmarkget_ma_multiples_benchmarkget_macro_market_signalget_macro_playbookget_market_intelligence_briefget_market_structure_signalget_model_risk_management_standardsget_mortgage_market_benchmarkget_ncreif_return_benchmarkget_ncua_credit_union_financialsget_nist_ai_rmf_requirementsget_noaa_disaster_economicsget_occ_enforcement_actionsget_payer_intelligenceget_pe_portfolio_benchmarkget_pe_return_benchmarkget_pharmacy_spend_benchmarkget_physician_group_benchmarkget_platform_divergenceget_portfolio_vendor_intelligenceget_property_operating_benchmarkget_property_tax_benchmarkget_provider_market_intelligenceget_public_company_financialsget_public_market_multiplesget_real_estate_debt_stress_benchmarkget_reit_benchmarkget_rental_market_benchmarkget_residential_market_benchmarkget_saas_market_intelligenceget_saas_metrics_benchmarkget_saas_negotiation_playbookget_salary_benchmarkget_sba_loan_market_dataget_sector_ai_intelligenceget_software_pricing_intelligenceget_spend_by_company_sizeget_staffing_agency_markup_analysisget_storm_event_historyget_stratalize_overviewget_top_vendors_by_categoryget_travel_nurse_rate_benchmarkget_uk_fca_coverageget_us_state_ai_legislationget_uspto_patent_intelligenceget_value_based_care_performanceget_vendor_alternativesget_vendor_contract_intelligenceget_vendor_market_rateget_vendor_negotiation_intelligenceget_vendor_risk_signalget_venture_benchmarkget_wacc_benchmarkget_weather_delay_riskget_working_capital_benchmarkget_workplace_safety_benchmarkget_world_bank_country_indicatorsget_yield_curve_benchmarkget_yield_curve_dataClaiming 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!
Crypto prices, market overview, DeFi TVL, whale flows & anomaly scans for trading agents.
Crypto market intelligence: prices, funding rates, narratives, regime, and delta-neutral research.
DeFi protocol data: TVL, yield pools, and cross-chain analytics
DeFi Protocol Activity Index -- quantitative on-chain activity metric from DefiLlama data
Add one secure layer between your agents and this server.
Each tool targets a distinct benchmark category (e.g., chain TVL, yield, options IV, RWA), with no overlapping purposes. The overview tool is clearly different. Agents can easily distinguish them.
Most tools follow 'get_<descriptor>_benchmark' pattern, but 'get_stratalize_overview' breaks the pattern. The naming is otherwise consistent and descriptive.
With 9 tools covering major DeFi and crypto benchmarks (TVL, yields, gas, options, RWA, etc.), the set is well-scoped and each tool serves a clear purpose.
The tool surface covers a broad range of crypto/DeFi benchmarks. Minor gaps exist (e.g., spot price feeds, exchange data), but the set is sufficient for benchmarking and agent discovery.
