Tickerz
REMOTE · TICKERZ.COM
Daily indexes of what people do, from public data. On-chain in Bitcoin, so nobody can edit them.
Available components
Last scanned (8 hours ago)
Scores higher than 89% of remote servers
Reachable. Last reached 25 Oct 2026.
Category Finance and Payments
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security80
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability75
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4955 tokens (~291/item across 17 items; 16 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management70
- Stability observed for 21 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 16 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
- Supports UI / widget rendering.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 24 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 27. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 10 Oct 26 +1
- Tool “get_listing_kit” rewrote its description, which is the text the model reads security
- Tool “list_indices” rewrote its description, which is the text the model reads security
- Tool “submit_forecast” rewrote its description, which is the text the model reads security
- Schema quality: 4397 → 4955 ▼ functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Oct 2026 · Probed https://tickerz.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=tickerz.com | CN=YR1,O=Let's Encrypt,C=US | 13 Oct 2026 | 11 Jan 2027 | RSA 2048 | SHA256-RSA | 5d3290db6e50f9cf728e58e76e3bf2b3be5 |
| SANs: tickerz.com | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of tickerz.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| tickerz.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| content-security-policy | default-src 'self'; script-src 'self' 'unsafe-inline' https://bzrcdn.openai.com https://va.vercel-scripts.com https://us-assets.i.posthog.com https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https://api.qrserver.com https://www.googletagmanager.com https://www.google-analytics.com https://*.google-analytics.com; font-src 'self' data:; connect-src 'self' https://tickerz.com https://bzrcdn.openai.com https://bzr.openai.com https://vitals.vercel-insights.com https://us.i.posthog.com https://us-assets.i.posthog.com https://www.google-analytics.com https://*.google-analytics.com https://*.analytics.google.com https://www.googletagmanager.com; media-src 'self'; frame-src 'self'; worker-src 'self' blob:; manifest-src 'self'; frame-ancestors 'self' https://chatgpt.com https://claude.ai; form-action 'self'; base-uri 'self'; object-src 'none' |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | camera=(), microphone=(), geolocation=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://tickerz.com/mcp | Verified | 200 | |
| http (plaintext) | http://tickerz.com/mcp | HTTPS enforced | 308 | https://tickerz.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
arena Arena ~228
The Arena: predict the number an index lands on. Each index that takes calls has one open question on its next period ("$MINTS for Sep 24. Forecast the number."), with the level it is called against, the forecast count and when forecasts close (when the period called begins). recent: closed questions with the Arena number (the points-weighted mean of the top 10 ranked handles that answered, frozen at close; labeled Arena, never official) and the final number once it lands. standings: handle, graded, mean_points, best_streak; ranked from 3 graded. Points per forecast: 100 times max(0, 1 minus absolute percent error / 25%), rounded. With id, one question: forecasts are listed only after it closes, with the proof of the forecasts that stood. Same data as GET /api/arena and GET /api/arena/question/{id}. Points only: no money, no prizes. Not advice.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | – | Optional question id, e.g. mints-2026-09-24 |
No output schema declared.
No examples provided.
asset Asset ~243
Use when someone asks about one coin or stock: why $X is moving, whether its volume is unusual, how its past spikes turned out, or where it trades. One asset in depth: latest snapshot, scores_30d (30 days of readings, every fourth stored tick, hourly), the open event and the 10 most recent past events with score_at_open, peak_score and receipts, and venues: where it trades (spot, perpetuals, futures, prediction markets), plain unpaid links checked nightly against each venue's product list. latest.score is the newest Activity score, the same number as the last point of scores_30d. When no event is open, driver is null and reason is no open event: a driver is read from the open event. Same data as GET /api/asset/{symbol}, plus score on latest and that reason. heat_7d (the same readings, each ts and heat) and peak_heat are deprecated aliases of scores_30d and peak_score, same values, kept until at least 2026-12-31.
| Name | Type | Req | Description |
|---|---|---|---|
| symbol | string | yes | Ticker symbol, e.g. BTC or GME |
No output schema declared.
No examples provided.
base_rate Base rate ~226
Use when someone asks what usually happens after a spike like the one an asset shows today, or whether moves like it tend to fade. What historically happened after a move like this asset's current one. Uses 3,213 crypto attention spikes on 175 coins since 2022, found with the live score's formula, matched on direction, size of move and how many other coins are unusual right now: the median, spread and share of cases that beat Bitcoin over 1, 7 and 30 days, next to what an ordinary day did. A base rate, not a forecast or advice. On days with a score of 70 or more. Stocks read a separate study measured against SPY and get a rate only where one of its groups holds; today none does, so stocks return null with the study's reason. Returns base_rate null with a reason for quieter days, and groups that are too small, dominated by one date, or not distinguishable from an ordinary day.
| Name | Type | Req | Description |
|---|---|---|---|
| symbol | string | yes | Ticker symbol, e.g. SOL or PEPE |
No output schema declared.
No examples provided.
board Terminal ~315
Use when someone asks what is unusual in crypto or US stocks right now, which coins trade far above their normal volume today, or how many are moving at once. Current Tickerz Terminal: all tracked assets with the 24h move, the activity score as score (0-100; score_1h is one hour earlier) and vol_mult (24h volume over the asset's 30-day baseline mean, measured), plus updated_at and breadth. assets mixes crypto and US stocks in one list sorted by score, so the first rows may be stocks: send class crypto or equity to get one kind, or filter on each asset's class. breadth counts crypto only, whatever class is sent: unusual is how many scored crypto assets are at 70 or more right now, scored counts the crypto assets with a score (an asset still building its 14 day baseline has score null and is not counted), and band is the study's band for the share: lone under 3% (so 0 unusual also reads lone), mid between, crowd at 30% or more. Same data as GET /api/board. heat and heat_1h are deprecated aliases of score and score_1h, same values, kept until at least 2026-12-31. No prices: they come from licensed vendors whose terms do not allow passing them on; tickerz.com shows them.
| Name | Type | Req | Description |
|---|---|---|---|
| class | string | – | Optional: crypto or equity (US stocks and listed funds). Leave out for every asset |
No output schema declared.
No examples provided.
get_index Index ~603
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…
| Name | Type | Req | Description |
|---|---|---|---|
| ticker | string | yes | Index ticker without the dollar sign, e.g. MINTS or YESNO |
No output schema declared.
No examples provided.
get_listing_kit Listing kit ~370
Use when someone wants to list, write or settle a prediction market on a Tickerz index. A market on the index's next print, ready to paste, for LAYOFFS, MINTS, GIGS, WAGE: question (one sentence, with {strike} left to fill from strikes), period (the next UTC day, or the week ending the Saturday named, that has not begun), strikes (the 10th, 30th, 50th, 70th and 90th percentiles of the last 30 published numbers, two significant digits, equal ones listed once, null under 14 prints), settle_time_utc (when that period's number is expected to be published; null for the weekly index, where settle_rule gives the window), settle_rule (the number as first published, in column settlement_value of the settlement file; a later revision never changes it), tie_rule (a print equal to the strike resolves No), fallback, precision, grade and rulebook from the index's rulebook, source_url, settlement_file (CSV), mirror_file (the same file on a public mirror), proof (the daily OpenTimestamps proof), recount (the commands that recount a print from the chain; null where none exists), next_print_at, license, and paste: the whole market as plain text under 600 characters. Any other index returns no_kit with the reason. Same data as GET /api/indices/{ticker}/listing.json. Showing a number is free; settling real money on it is licensed: https://tickerz.com/pricing. Not advice.
| Name | Type | Req | Description |
|---|---|---|---|
| ticker | string | yes | Index ticker, with or without the dollar sign: LAYOFFS, MINTS, GIGS, WAGE |
No output schema declared.
No examples provided.
get_question Question ~134
One question by id, open or resolved: the statement, the nulls, Tickerz's answer, the crowd split once answers have closed, the outcome (the first stored Activity score at or after the resolve time; void when none lands within 3 hours) and who was right. proofs[] holds each OpenTimestamps proof: the question's canonical_json at once, each hourly answer batch's once answers close; sha256(canonical_json) equals digest_sha256. Same data as GET /api/questions/{id}.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Question id (uuid), from open_questions or GET /api/questions |
No output schema declared.
No examples provided.
get_report Signed report ~193
Use when a contract, a venue or a person needs the signed Tickerz print for an index: the report (ticker, period, value as a scaled integer with decimals, status provisional, final or corrected, rule version and hash, the provider reads with their snapshot hashes, settleable), its hash, the publisher's Ed25519 signature, the independent recount's co-signatures, and the Solana feed account that holds it. Optional period (YYYY-MM-DD; a month as YYYY-MM-01). How to verify: https://tickerz.com/.well-known/tickerz-signer.json. Same data as GET /api/indices/{ticker}/report. Every signed print with its recount status: https://tickerz.com/signed.
| Name | Type | Req | Description |
|---|---|---|---|
| period | string | – | The period, YYYY-MM-DD; newest when left out |
| ticker | string | yes | Index ticker, with or without the dollar sign |
No output schema declared.
No examples provided.
get_rule Index rule ~133
Use when someone needs to know exactly how a Tickerz index is counted before relying on it: the machine-readable rule (source, query, transform, aggregation, cadence, unit, decimals, precision, revision policy, grade, and settlement rights with the terms page and the quoted clause), its version, and its hash (sha256 of the canonical JSON). settleable says whether a market may settle on it: the source's terms allow it and the grade is not display. Same data as GET /api/indices/{ticker}/rule.
| Name | Type | Req | Description |
|---|---|---|---|
| ticker | string | yes | Index ticker, with or without the dollar sign |
No output schema declared.
No examples provided.
list_feeds Oracle feeds ~133
Use when a contract, a venue or a person wants every Tickerz oracle feed at once, as on https://oracle.tickerz.com: per index the newest signed value and its period, status (signed, recounted, final, corrected or disputed), how often it is signed, whether a market may settle on it and why, how many reads must agree, the rule version and hash, and its feed account on Solana. live says whether the Solana program is written to yet; before it is, read the signed reports (get_report). Read from a stored copy; read_at says when.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_indices Indexes ~430
Use when someone asks how many memecoins launched on pump.fun, what memecoin launchpads earned in fees, how much traded on Kalshi and Polymarket, how many Americans filed first jobless claims, how many paid calls wallets made over x402 on Base and what each cost, or what the US jobs number, unemployment rate, CPI or core CPI was when first published, before the Bureau of Labor Statistics revised it. Tickerz reads each as an index against its own normal (daily, weekly for LAYOFFS, monthly for JOBS, UNEMP, CPI and CORECPI), each reading timestamped in Bitcoin so it cannot be changed afterward. Every Tickerz Index: what it counts, its source, the newest day, the Activity score and signed z of the newest complete day, and the last 30 complete days as period, value and band. GIGS counts paid x402 calls settled on Base; WAGE is dollars per call, the payer-balanced median. WAGE days carry p25 and p75, the 25th and 75th percentiles in dollars per call, 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 a finished period read latest_complete. latest is the newest period on file; when it has provisional true it is a partial UTC day still counting, marked partial_day true, and its change_pct (also given as partial_change_pct) compares that partial day with a full one, so it is not a full-day change. Some sources land late (jobless claims about ten days after the week ends, Chicago crime over about a week), so latest_complete can be days behind today. Same data as GET /api/indices. A source whose terms keep its levels out of the API is served with its score and bands only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
methodology Methodology ~66
Public Sigma-1 methodology as text (same disclosure as https://tickerz.com/methodology). No proprietary parameters. The text content is Markdown; structuredContent carries the same text as JSON (model, url, markdown, and its sections as heading and text) for clients that parse JSON.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
name_a_number Name a number ~280
Use when someone wants a number counted that Tickerz does not publish yet, or a market needs a number nobody sells. Send counts (what should be counted, one line, 3 to 160 characters), optionally source_url (where it can be read) and ticker (2 to 12 letters or digits). Tickerz reads the source's terms, then within 48 hours either builds it as a ticker (rule, source, a script that recounts it, the first reading on record) or posts the plain reason it cannot be built, at https://tickerz.com/x. What you send is never shown publicly; the answer is in Tickerz's own words. Returns the count of numbers named so far. At most 3 a day from one address. Same as POST /api/indices/requests. Free. For an on-chain count that can go live in minutes instead, a person can type it at https://tickerz.com/launch.
| Name | Type | Req | Description |
|---|---|---|---|
| counts | string | yes | What should be counted, in one line, e.g. "new Farcaster accounts per day" |
| source_url | string | – | Optional: where the number can be read, http(s) |
| ticker | string | – | Optional: a ticker for it, 2 to 12 letters or digits, with or without the dollar sign |
No output schema declared.
No examples provided.
open_questions Open questions ~208
The referee's questions still waiting on their answer: one on-chain attention question per crypto event, "$SYM reads 40 or more at <event open + 24h> UTC", answered at_or_above (40 or more) or below (Under 40). Each carries the score and volume multiple at open, the three nulls frozen at creation (base rate: the share of past crypto events that read 40 or more 24 hours after open; persistence: the latest reading carried forward; always below) and Tickerz's own answer, which is the base-rate null. accepting_answers is true until 4 hours after the question opened; the crowd split stays null until then. calibration: hit rates of the crowd majority and each null over every resolved question, each with its n. Optional symbol filter. Same data as GET /api/questions?state=open. About attention, not price. Not advice.
| Name | Type | Req | Description |
|---|---|---|---|
| symbol | string | – | Optional ticker, e.g. HBAR |
No output schema declared.
No examples provided.
receipts Receipts ~468
Use when someone asks how past attention spikes turned out, or wants a track record they can check, losses included. Closed events, newest first, each with its 24h, 7d and 30d receipts (forward return, or null until due; benchmark is BTC for crypto and SPY for stocks, with benchmark_ret_pct over the same window), score_at_open, peak_score and the driver with its source. Each event carries symbol (the same ticker as assets.symbol). Each proofs row carries proof_url, the proof as JSON, an absolute link in the same form as an index first_print.proof_url. A receipt is due 24 hours, 7 days and 30 days after the event opened, so the newest page has null 30d receipts until they are due: page back to events old enough for them with before and before_id: each page carries next_before (its last event's opened_at, exactly as stored) and next_before_id (that event's id), null when there is nothing older. Send both back and the next page starts right after that event, including events opened at the same time. before alone (any ISO time) reads events opened strictly before that time, so on its own it can skip events opened at exactly that time. Optional symbol filter, applied in the query, so limit counts only that ticker's events and an empty page means none older on record. Same store as GET /api/receipts. peak_heat is the deprecated alias of peak_score, same value, kept until at least 2026-12-31.
| Name | Type | Req | Description |
|---|---|---|---|
| before | string | – | Optional cursor: only events opened before this time (ISO 8601, e.g. 2026-09-01T00:00:00Z). Send next_before from a page, with before_id, for the page before it; without before_id, events opened at e… |
| before_id | string | – | Optional, with before: next_before_id from a page. The next page starts right after that event, so events opened at the same time are not skipped |
| limit | integer | – | 1 to 100, default 30 |
| symbol | string | – | Optional ticker to filter, e.g. BTC |
No output schema declared.
No examples provided.
submit_forecast Submit a forecast ~698
Two kinds of forecast. 1) Arena (numeric): send question_id as an Arena id from the arena tool (e.g. mints-2026-09-24) or ticker (e.g. MINTS), plus handle (3 to 20 letters, digits or underscores) and value (a number in the index's unit). A handle is claimed by the address that first uses it; the first forecast that stands under a handle returns handle_key, a secret shown once: send it with every later forecast under that handle and it is accepted from any address, so an agent whose address changes keeps its handle. Without it, only the first address may use the handle. One forecast per handle per question; the latest sent before close stands; forecasts close when the period called begins and stay hidden until then. Graded on the number as first published: 100 times max(0, 1 minus absolute percent error / 25%), rounded. Public standings by mean points, ranked from 3 graded. 2) Referee (attention question): send question_id as a uuid from open_questions and answer: at_or_above (it reads 40 or more at the stated time) or below, with an optional probability, 0 to 1, your chance it reads 40 or more, which must agree with the answer. An agent answering for someone sends agent, its name (e.g. Muse): the answer is stored as an agent's, never counts in the crowd split, and is shown by name beside the crowd once answers close. One answer per caller per question and at most 3 per address (the first one stands; a repeat is acknowledged with already_answered true and is not echoed back); answers close 4 hours after the question opens and are recorded with OpenTimestamps in hourly batches; everyone is graded at 24 hours against the nulls, Tickerz included, with no ranking of callers. Both: no login, no prizes, no money. Not advice.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | – | Referee only, optional: the agent's name when an agent answers for someone, e.g. Muse. 1 to 32 letters, digits, spaces, dots, hyphens or underscores. Never counted in the crowd split; shown by name a… |
| answer | string | – | Referee only. at_or_above: it reads 40 or more. below: under 40 |
| handle | string | – | Arena only: your public handle, 3 to 20 letters, digits or underscores |
| handle_key | string | – | Arena only: the secret key returned with the first forecast under this handle (hk_ and 32 characters). Send it with every later forecast so the handle is accepted from any address. Never share it |
| probability | number | – | Referee only, optional: your probability that it reads 40 or more, 0 to 1 |
| question_id | string | – | Referee question id (uuid) from open_questions, or an Arena id (e.g. mints-2026-09-24) from the arena tool |
| ticker | string | – | Arena only, instead of question_id: the index ticker, e.g. MINTS; forecasts its open question |
| value | number | – | Arena only: your number for the period, in the index's unit |
No output schema declared.
No examples provided.
How do I install the Tickerz MCP server?
Tickerz is a hosted endpoint at https://tickerz.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · tickerz.com
claude mcp add --transport http com-tickerz-tickerz 'https://tickerz.com/mcp'
What is the Tickerz MCP server?
Tickerz is an MCP server listed in the public MCP registry as com.tickerz/tickerz. Daily indexes of what people do, from public data. On-chain in Bitcoin, so nobody can edit them. This page covers its hosted endpoint (https://tickerz.com/mcp).
Is the Tickerz MCP server safe to use?
Tickerz scores 83 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Tickerz MCP server expose?
Tickerz exposes 16 tools: board, asset, base_rate, receipts, open_questions, and 11 more. Their descriptions and schemas cost roughly 4,728 tokens of context every time the server is loaded.
Does the Tickerz MCP server require authentication?
No. We connected to Tickerz without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Tickerz MCP server still maintained?
Tickerz is still listed as active in the MCP registry. We last reached this channel on 25 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.