Skip to main content
Glama

Coinbase Premium (US demand gauge) + carry yield

get_coinbase_premium
Read-only

Retrieve Coinbase Premium data to gauge US Bitcoin and Ethereum buying or selling pressure, including averages, streaks, history, and carry yields.

Instructions

Call this when the user asks whether US investors are buying or selling Bitcoin or Ethereum, about the Coinbase Premium, or what the cash-and-carry basis trade pays. Returns the latest daily premium in percent, 7-day average, same-sign streak, the last 30 days, and annualized quarterly carry yields. History since 2017; positive premium = US buying pressure. The kimchi and Turkey premium daily rows cover the last 7 days; pass days (up to 90) for more.

Input Schema

NameRequiredDescriptionDefault
daysNoOptional. Days of kimchi and Turkey premium daily rows, newest first (default 7, up to 90).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv0.36.0
    • addedInput schema / properties / days
      Added value: +{
      +  "description": "Optional. Days of kimchi and Turkey premium daily rows, newest first (default 7, up to 90).",
      +  "maximum": 90,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  3. First observedv0.5.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover safe-read (readOnlyHint=true, openWorldHint=true), so the description's job is to add output shape and quirks, which it does: history since 2017, positive premium = US buying pressure, and the non-obvious fact that the days parameter only extends the kimchi/Turkey rows. It does not state freshness/lag cadence of the 'latest daily' value, which is the main remaining unknown.

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?

The trigger clause is front-loaded before the return-value inventory, and every sentence carries information (triggers, outputs, sign convention, history depth, parameter scoping). It is dense but slightly overpacked, mixing trigger guidance and output enumeration in a single flow.

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?

With no output schema, the description carries return-value burden and does so: it enumerates every field an agent would need, gives the sign interpretation, states history depth since 2017, and clarifies the one optional parameter's limited effect. Nothing required to call or interpret this tool 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 baseline is 3; the description earns an extra point by flagging that days only widens the kimchi and Turkey daily rows (up to 90) and does not extend the fixed 30-day headline premium series — a scoping nuance an agent could easily misread from the parameter name alone.

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

Purpose4/5

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

The description names the resource (Coinbase premium / US demand gauge) and states exactly what it returns: latest daily premium in percent, 7-day average, streak, 30 days of history, and annualized carry yields. It is specific and distinguishable from most siblings. The one gap is that 'what the cash-and-carry basis trade pays' overlaps conceptually with get_funding_arbitrage, and no boundary is drawn there.

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?

It opens with an explicit trigger: 'Call this when the user asks whether US investors are buying or selling Bitcoin or Ethereum, about the Coinbase Premium, or what the cash-and-carry basis trade pays.' That gives concrete user-intent contexts rather than a vague topic. It stops short of any exclusion or named alternative (e.g. get_turkey_premium for Turkey-only questions), so it is clear context without routing.

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