Skip to main content
Glama

Get Historical Scores

get_historical_scores
Read-onlyIdempotent

Free slice, paid full record. Score history of one coin: every recorded change to its 8 metric scores as a dated record with the TVR Score, the method version, a source label (baseline for the opening record, auto_captured for rows written from the change itself), the public reason where recorded and a SHA-256 hash per record; forward-only from the day the record began. Without scope (or scope "free"): the last 90 days or the last 3 records, free, no payment, no key. scope "full": the whole record, $0.05 per pull paid in-band with x402 (USDC on Base) or MPP (USDC.e on Tempo) once the record extends beyond the free slice; until then the free record is returned and nothing is charged. Data from True Value Rankings (truevaluerankings.com).

Input Schema

NameRequiredDescriptionDefault
coinYesTicker or name of a coin covered by TVR (BTC, Bitcoin, ETH, LTC, XMR, SOL, ADA, AVAX, DOT, POL, LINK)
scopeNofree (default): the last 90 days or the last 3 records, no payment. full: the whole record, paid per pull once the record extends beyond the free slice; until then the free record is returned and nothing is charged.

Output Schema

NameRequiredDescriptionDefault
nameNo
noteNo
errorNo
legalNo
scopeNo
accessNo
periodNo
reasonNo
statusNo
symbolNo
contextNo
paymentNo
productNo
recordsNoDated score states, newest first: as_of, revision, source, scores, tvr_score, method_version, changed_metrics, reason_public, published_at, record_hash
successNo
coverageNo
hash_noteNo
disclaimerNo
how_to_payNo
learn_moreNo
redeliveryNo
full_recordNo
hash_formatNo
method_versionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / scope / description
      Previous value: -"free (default): the last 90 days or the last 3 records, no payment. full: the whole record; included with a Premium agent key, or paid per pull once the record extends beyond the free slice."New value: +"free (default): the last 90 days or the last 3 records, no payment. full: the whole record, paid per pull once the record extends beyond the free slice; until then the free record is returned and nothing is charged."
  2. Added
  3. Removed
  4. Added

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only, idempotent, non-destructive profile, and the description goes well beyond them: payment rails (x402 USDC on Base, MPP USDC.e on Tempo), per-pull pricing, and the fact that nothing is charged while the record still fits in the free slice. Forward-only recording and per-record SHA-256 hashes are also disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with 'Free slice, paid full record,' which is exactly the right framing. The pricing/scope material is partially duplicated between the description and the scope enum's schema text, which costs a little efficiency but doesn't obscure anything.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still enumerates the record fields (dated record, TVR Score, method version, source label, public reason, SHA-256 hash), so an agent knows what comes back and what billing behavior to expect. Nothing needed for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented; the description still adds value by clarifying that the 'source' label takes values like baseline vs auto_captured and what the hash represents. Marginal gain over the schema, but real.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — the score history of one coin, every recorded change to its 8 metric scores — and pins down the record's composition. It is clearly distinct from get_tvr_score (current score) and get_full_breakdown in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the two modes: without scope or 'free' returns the last 90 days / 3 records at no cost; 'full' returns the whole record for $0.05 per pull. It doesn't name a sibling tool as an alternative, but the free/paid branch is spelled out with the exact threshold that triggers billing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.