Skip to main content
Glama

coinverdict

by io.github.OCArk

get_kol_leaderboard

Get the KOL settlement leaderboard: crypto influencers ranked by their SETTLED hit rate (from VeraMind's ledger of public calls graded after the fact — misses count). CoinVerdict-exclusive data. Returns {ranked:[{author,hit_rate_pct,n_verified,coins,n_total, n_prospective,hits_prospective,prospective_rate_pct, n_retrospective,hits_retrospective,retrospective_rate_pct}], building:[...], as_of, rule}. Rates are graded under rule kol_directional_v1: did the direction hold over a 7-day window, with a ±3% band, altcoins scored against BTC and BTC against USD — identical parameters to the settle_v1 rule CoinVerdict scores its own verdicts with. Always report the rule field alongside any number you quote; if it reads price_target_v1, the board fell back to price-target records and the numbers mean "did the stated price target print?" instead. Prospective (called before the fact) and backtested (graded from history) records are scored as separate lines and MUST NOT be averaged together; hit_rate_pct/n_verified are the prospective line, n_total is the combined sample size used for ranking eligibility. A null rate means no samples of that kind — report it as n=0, never as 0%. Free, read-only, not advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

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 excels by detailing the grading rule (kol_directional_v1), the fallback to price_target_v1, the distinction between prospective and backtested records, the prohibition on averaging them, null handling, and the read-only nature. This is exemplary transparency.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, return shape, grading rule, fallback, data separation, null handling, and usage caveats. It is well-structured and front-loaded with the core purpose, making it efficient despite its length.

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?

Given there is no output schema, the description fully covers the return structure (with example fields), explains the meaning of key fields (hit_rate_pct, n_total, etc.), handles the rule fallback nuance, and warns about null rates. It is complete for a complex data tool.

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?

The tool has zero parameters, so the baseline is 4. The description's extensive detail about return fields and data semantics is outside the scope of parameter semantics, but since there are no parameters to explain, the score reflects the baseline.

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?

The description opens with a specific verb and resource: 'Get the KOL settlement leaderboard: crypto influencers ranked by their SETTLED hit rate.' It clearly distinguishes this from sibling tools like get_track_record (individual track record) or get_verdict (specific verdicts), making the purpose unmistakable.

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?

The description provides strong context about when to use this tool (accessing KOL leaderboard data, CoinVerdict-exclusive), but it does not explicitly state when not to use it or mention alternative tools. No exclusions or alternatives are named, so it falls short of a perfect score yet is still clearly useful.

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

All coinverdict toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool serves a distinct purpose: per-coin vs whole-market verdicts, per-coin vs overall track records, a leaderboard, and a symbol discovery tool. No two tools overlap in their primary function, and descriptions reinforce the differences.

Naming Consistency4/5

Five of six tools follow the 'get_' + noun pattern (get_kol_leaderboard, get_market_overview, get_receipts, get_track_record, get_verdict), but list_coins deviates by using 'list_' instead of 'get_'. The pattern is otherwise very consistent.

Tool Count5/5

Six tools is right-sized for a read-only research API. Each tool addresses a clear aspect of the domain (discovery, current verdicts, historical performance, market-wide summary, and influencer data) without unnecessary bloat or missing essentials.

Completeness5/5

The tool set covers the full lifecycle of a verdict-based research service: discovery (list_coins), current verdicts for one coin (get_verdict) and all coins (get_market_overview), settled performance for one coin (get_track_record) and overall (get_receipts), plus a unique KOL leaderboard. No obvious gaps for the stated purpose.

Resources