Skip to main content
Glama

Tickerz

by com.tickerz
OverviewDiscussionsAdmin

Index

get_index
Read-onlyIdempotent

Use for the history, rules, source and proof of one index named by list_indices (LAYOFFS, YESNO, TRENCHES, MINTS, GIGS, WAGE, JOBS, UNEMP, CPI, CORECPI). JOBS, UNEMP, CPI and CORECPI are monthly, from the Bureau of Labor Statistics: a day's value is the Bureau's figure now, its settlement_value is the first print Tickerz read at release, and a month loaded as history carries a note and no settlement_value. One Tickerz Index: its definition, every period in its read window with its band and signed z, the first print of the newest complete period, the open round, past rounds, and the newest proof. latest_complete is the finished period; a provisional latest is a partial UTC day (partial_day true), and its change_pct, also given as partial_change_pct, is not a full-day change. WAGE days, latest and latest_complete carry p25 and p75 where the store has them. GIGS and WAGE complete days carry thin and sampled_payers: thin is true when sampled paying wallets are under 70% of the median of the 28 complete days before that day, once 14 earlier days are on file, and the level stays. Fewer earlier days is not marked. For what is on-chain, read proof: covers_period and covers_value are the newest period of this index a proof holds and its value there, stamped_on is the UTC day that proof was stamped, with digest_sha256, bitcoin_height, proof_url (the exact text hashed, as JSON) and ots_url (the OpenTimestamps file), status (on_chain, awaiting_bitcoin, none or unavailable), and latest_complete with on_chain true or false. A live source's day is complete at 00:00 UTC and goes on-chain in the next day's proof, stamped after 12:00 UTC, so stamped_on is a day after covers_period and the newest complete day is often not on-chain yet. seal is the newest daily proof for every index: seal.day is the day it was stamped, not a period of this index. first_print is for latest_complete and stays null until a proof holds it. forecast is Forecast v1 for the next period: p10, p50 and p90 (an 80% range and its middle), the model the daily run chose, backtest (periods walked forward, coverage_80, skill_vs_last_number: the share of error removed against repeating the last number, negative when worse) and the live record; display only, never a settled number, null when none. Same data as GET /api/indices/{ticker}, plus proof. Levels a source's terms keep out of the API are null.

Input Schema

NameRequiredDescriptionDefault
tickerYesIndex ticker without the dollar sign, e.g. MINTS or YESNO

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ticker / description
      Previous value: -"Index ticker without the dollar sign, e.g. MINTS or GOON"New value: +"Index ticker without the dollar sign, e.g. MINTS or YESNO"
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, non-destructive), but the description goes far beyond them: it explains null levels under source terms, partial UTC days and partial_change_pct, live-source completion at 00:00 UTC with on-chain stamping after 12:00, the definition of thin (<70% of the 28-day median once 14 days exist), and that forecast is display-only. This is unusually rich 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.

Conciseness3/5

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

Purpose is front-loaded, but the body is a dense single-paragraph run-on with no bullets or field grouping, making it hard to scan. Much of the length is defensible given there is no output schema to explain return fields, yet the presentation is inefficient.

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 must carry the return-shape burden and does so thoroughly: it documents definition, periods with band and signed z, first_print semantics, partial days, seal, proof fields (covers_period, digest_sha256, bitcoin_height, ots_url, status), and forecast sub-fields. Nothing an agent needs to interpret the response 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?

The schema fully documents the single ticker parameter, so the baseline is 3. The description adds value by enumerating the entire valid ticker set (LAYOFFS, YESNO, TRENCHES, MINTS, GIGS, WAGE, JOBS, UNEMP, CPI, CORECPI) where the schema only gives two examples, reducing invalid inputs for a parameter with no enum.

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 opening clause states a specific verb and resource: 'Use for the history, rules, source and proof of one index named by list_indices.' It explicitly ties the tool to a sibling (list_indices) that supplies the ticker, so an agent can distinguish this single-index detail lookup from the list tool without opening a schema.

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

Usage Guidelines3/5

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

Usage is implied by the requirement that the ticker come from list_indices and by the enumerated valid tickers, giving a routing hint. However, there is no explicit when-to-use vs. when-not guidance (e.g., pointing to list_indices for enumeration or to arena/board for related views), so context must be inferred.

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

All Tickerz toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources