Skip to main content
Glama

HEY Research Lab

Find who's actually building on Robinhood Chain.

CI Licence: MIT Node TypeScript Chain Site

Site · Public API · MCP server · Sources · Changelog

HEY Research Lab

The question

Not which wallet bought and not which token is pumping, but:

Which projects are still building, what have they shipped, and which of them are not yet getting much market attention?

Price tells you what the market is doing. HEY tells you what the builder is doing.

Every answer on HEY is a fact with the source it came from. There is no score of a project's worth, no grade, no verdict, and the words rug and scam appear nowhere in the product — an end-to-end test asserts it.

A project page opens with its story: whether the builder is building (in plain words first), the latest ship and why it matters as a build event, whether the product is used, the token market as context, and what HEY does not know yet. Where HEY has nothing to read building from, the page says so once and lists what it does know, what it cannot verify yet and what it is still to read. A Research coverage block counts the dimensions HEY measured for that project — a count of states, never a score. The badge and the story read one table of research-level words, so a "Researched" page never says "Not researched yet", and a Verified Builder whose ships came from a deployment reads "Verified builder · no shipping source HEY can read yet", never "not linked". A latest change that is a market or lock event says so, and its link opens that event's own record.

Related MCP server: flowscan-mcp

What it looks like

Explore the catalogue

One project's evidence

Explore

Project page

Builder Radar

HEY Signal

Builder Radar

Signals

Pulse — the chain, day by day

Ships — what landed

Pulse

Ships

Scout — earn by finding evidence

Bounties — set in dollars, paid in HEY

Scout

Bounties

Developers

Methodology — every rule, stated

Developers

Methodology

Home, 375px

A project, 375px

Captured from production on 20 September 2026, before the Luminous Glass material system (30 September) and the homepage token check (19 October): the pages are laid out as shown, and look different today.

Since 1 October 2026 a first visit starts research-ready: Explore lists the projects HEY can answer the builder question for (a measured activity status or a source-backed ship in the last 90 days), with every indexed project one press away; the homepage shows real project cards right under the search; and a search that matches nothing says why and where to go next.

Since 19 October 2026 the homepage opens with one box, "Check a token or project". Type a token's name, ticker or contract and press Check, and the answer appears right there: a published project's Research Summary line, its latest ship with its evidence, its contract and how many other tokens use its ticker, and its official X account as its page shows it — or the projects that share the ticker, never one picked for you — or, for a contract HEY has not researched, what HEY Scan reads (the scan runs only on that press, on the scan's own budget). "Post to X" shares the answer with a link back to the page.

In this repository

This is the published half of HEY: the parts that stand on their own and are safe to read.

Path

What it is

packages/sources

Every public-data adapter HEY reads — GitHub, Blockscout, Sourcify (verification and its signature database), DEX Screener, GeckoTerminal, CoinGecko, launchpads, feeds, npm, deps.dev, OSV — each with saved fixtures and contract tests, plus the Telegram Bot API adapter HEY's alert bot sends through. The tests fail on a real network call. All of them go through one fetch guard (private-address and DNS-rebinding checks, redirect and credential rules, size, time and content-type limits) and bounded HTML and XML parsers, tested against hostile pages and feeds.

packages/scoring

Activity status, Build Momentum, Still Building and Under the Radar, deterministic and versioned. They read no price and no balance, and that is tested.

packages/sdk

@hey-research-lab/sdk, the typed client over the public API. No dependencies, ESM and CJS, Node 18 or a browser.

packages/mcp-core

The MCP tools, renderers, resources and prompts with no transport: thirteen read-only tools (fourteen where Market Integrity is published, as on heyresearch.xyz), each answer tagged FACT, DERIVED or UNKNOWN.

packages/agent-provider-core

The agent contract, AgentIntelligenceResponse v1: six bounded capabilities composed from the public API's own objects, the freshness contract, machine-safe text (contentOrigin), and thin REST, MCP and A2A adapters. The Robinhood Agent Apps adapter is an interface only, pending an official provider specification.

apps/mcp

@hey-research-lab/mcp, the stdio entry point that bundles them. Node 20. The same tools are hosted at https://heyresearch.xyz/mcp.

packages/config

Environment schema and chain constants.

packages/ui

The presentation components — cards, chips, status, formatting, and the Terminal's candle chart (15m, 1H, 4H and 1D, with a code lane of commits, merged pull requests and exact-time releases), whose builder-event callouts are laid out from each event's time alone (terminal-chart-annotations.ts): never a price, never a cause.

docs/

The public API, the MCP server, the source registry, and every data source with what it refuses and why.

The ingestion pipeline, the quality gate, the database schema, the web app and the operations tooling stay in the private repository.

Quickstart

Use the packages from npm (published 27 September 2026):

npm i @hey-research-lab/sdk                                   # the typed client
claude mcp add hey-research -- npx -y @hey-research-lab/mcp@0.3.2   # the MCP server

Or build this tree:

pnpm install
pnpm lint && pnpm typecheck && pnpm test     # no network
pnpm --filter @hey-research-lab/sdk build        # packages/sdk/dist
pnpm --filter @hey-research-lab/mcp build        # apps/mcp/dist/index.js

Which token, account and repository are a project's

An issuer's own token — a Robinhood stock token, read from the issuer factory's creation events into issuer_tokens — is never a project's token, usage, valuation or market, and Scan says whose it is. A site that only lists a contract among others does not verify it. A source copied from a launch or market listing says so; Robinhood's own accounts are never a project's. Names that borrow Robinhood's brand or a stock ticker carry a notice above every badge. Renamed GitHub repositories are followed by GitHub's numeric id, and a pool is "Uniswap" only when the chain confirms its factory.

A library or SDK repository, a test-data or fixture folder, a hand-kept deployments file deep in the tree, a file that names another repository as its source, or an asset list never proves that a token is a project's; a token a page took by a link that no longer holds gives that page no verified-contract ship. A GitHub release counts once across pages by its numeric release id, even after its repository was renamed. A description that claims a Robinhood partnership carries its own notice. A QUIET or DORMANT status that lost the builder source it rests on is rescored first, to "No builder source linked". Search lists an issuer's own token as its own row, above lookalikes.

A token a page took on a deploy record that no longer proves anything goes back to its own launch record, logged and reversible.

A repository that only names a token is never that token's project and never verifies it (2026-10-05). A tracker, radar, bot or dashboard names the tokens it watches in its code and prints them on its site; neither is the token's word. A builder's repository pairs with a launch record only when the launch record itself declared that repository or its owner, or a deploy record proves the deployment — and an address file without the creating transaction proves nothing about a contract twenty or more GitHub accounts name (a launchpad's token, a protocol's position manager, a platform token used as collateral). Links made the old way go back to their launch record with its own site, docs and X account, logged and reversible. When published projects share a name or a ticker on different contracts, the project page, the Terminal, search and the type-ahead say so in one line, with what each project's own site or deploy record names — never which one is "real". /signals lists projects with Robinhood Chain evidence first within each group.

Whose repository it is, re-checked (2026-10-07). A repository HEY's GitHub search attached to a page only because another repository by the same owner was already matched — before the ownership gate existed — is scored again by today's gate: unless its homepage is on the project's own domain or the project's own site links it, it stays on the page as context and its weeks stop counting (pnpm data:recheck-search-owners, dry run by default). When two published pages carry one repository, a page whose token the project's own site names (VERIFIED) holds it over a page whose token it does not; otherwise the page HEY saw first, as before (pnpm data:shared-repo-holders). Nothing is deleted; each change is logged.

A card's one line is a description, never a README (2026-10-03). Provider text — a listing, a launchpad form, a repository's README — passes through one deterministic rule (descriptionLine): Markdown, label headings, addresses, URLs and bot commands go; instructions, chat, relay boilerplate and how-to sections are never the line; whole sentences are kept up to 200 characters. Text with no description in it leaves the line empty rather than filling it with anything. A project with no line takes its own site's meta description through the same rule, logged. Words an owner typed are never rewritten.

Data correctness after a full audit (2026-10-03). The integrity audit no longer counts a Robinhood stock token as an orphan (it belongs to no project by rule); a failing audit makes /status critical and names the failing checks, and /api/status adds integrity.failing, catalog.hidden and catalog.hiddenAsOf without changing any existing field. A verified contract's timeline entry reads "Contract source verified", never "Contract deployed". A description line keeps a dash before a closing emphasis mark, drops a mark left without its partner, and is empty for text whose words run together. A repository that says it is a third-party profile of someone else is never promoted into a project. Cards say "No token tracked" rather than "No token". A card prints a valuation only for a verified token, or an active market whose ticker is not contested, and never the ticker or valuation of a token the project's own site disowns (2026-10-24).

Markets, the same day. A token that reads 0 decimals (an NFT collection) has no fungible market: no valuation, Discovery Gap, Under the Radar or Still Building, and NFT marketplaces such as Seaport are never read as a DEX. A market is never "Active" over a reading more than 36 hours old with no fresh trade record ("No current reading"). A market active only in another pool prints no valuation from the thin pool it follows. The Builder activity chart hatches weeks before HEY first read a project's sources as "not yet read", never zero. Holder figures say what they leave out and which supply they measure. A page under a publication hold says it is held and how the hold lifts, with no score, badge or Terminal link.

One project, one page, and bounties HEY already answered (2026-10-03). A registry listing whose site or official X account a published page already holds (tokenless, or with a verified token) joins that page instead of opening a second one; an unverified token page, a "V2"/"V3" sibling or a launchpad's shared site still gets its own. Registry pages opened before that are held by one reviewed, reversible command (pnpm data:duplicate-listings, dry run by default) and their address points to the project's page. An open research bounty whose fact HEY has since verified by other evidence is no longer listed as open and cannot be claimed; the hourly sweep closes the treasury-funded ones nobody handed in work for (logged, reversible, no money moves), and handed-in work waiting more than seven days is flagged for review.

Use the API

No key needed for the read API. 120 requests a minute anonymously, more with a key. Every answer names its version in x-hey-api-version. A platform partner can ask for a partner key with its own quota and route permissions; it reads the same public research, never anyone's account data (2026-09-30).

Filters that say no, and exports (2026-10-02). A value a parameter does not read is a 400 invalid_parameter listing the allowed values, never the unfiltered list (/api/ships?type=banana, /api/projects?sort=momentum). /api/ships reads type=releases (every release type), a comma list of types, and until (exclusive) beside since; a code-activity ship carries codeWeek, its fixed Monday–Sunday UTC week with that week's commit count and up to three commit subjects. /api/projects?sort=shipped7d|shipped30d orders by meaningful ships in the window. /api/export/projects and /api/export/ships return the same lists as CSV, at most 1,000 rows.

One address, one line — the call a trading bot makes:

curl "https://heyresearch.xyz/api/v1/scan?chain=4663&token=0xB33eb16782776b4D738c0Fd643577cb0284Db610"
{
  "found": true,
  "status": "shipping",
  "status_label": "Shipping",
  "verified_builder": true,
  "activity": { "commits_30d": 100, "releases_30d": 1, "ships_30d": 3, "last_ship": "2026-09-18" },
  "project_url": "https://heyresearch.xyz/project/hey-research-lab",
  "cta": { "label": "See the builder on HEY", "url": "…" }
}

A token HEY has no published page for answers 200 with found: false, so a bot prints nothing rather than guessing. Asking is still counted (2026-10-05): the partner card, the builder card, /api/token/…, the agent contract's verify_project and unknowns, A2A's investigate_contract and the MCP tools that read through them record the address once per caller a day (crawlers and HEY's own traffic left out), and a scheduled, budgeted job reads DEX Screener's listing for asked contracts that declare no website, so the site check and the quality gate have something to judge. Asking never publishes.

A person asks the same question at heyresearch.xyz/scan, or inside the Research Terminal at /terminal/scan, where the ⌘K palette offers it for any address HEY does not track. One scan behind both, and the same boundary: who is building this, never what the token might do next. Since 2026-10-09 (a founder decision) a scan of a token HEY does not track also reads its on-chain context — how concentrated the supply is and the day's transfers and trades, shares and counts, never an address — under its own small daily allowance, and keeps the distribution as that token's daily summary. Since 2026-10-10 that distribution is read from the Blockscout API (free tier, key required) first, with the explorer's all-time transfer count beside it, and from Bitquery only when the explorer cannot answer. It has one name (2026-10-01): the navigation says "Scan", and the page asks "Is anyone building this?". A published project answers with its Research Summary and the doors to follow it; anything unresearched says "Builder not established yet." and what HEY holds. What readers keep asking about is summed per record (research_demand) and decides only what HEY researches next — an hourly, capped sweep queues the canonical site, contract-source and quality-gate jobs for the most-asked under-researched records — never a status, score or rank. One contract is read live at most six times a UTC day, and a repeat scan within thirty minutes of a live read answers from what that read recorded, dated, with when a fresh read is available.

The Research Terminal answers questions (2026-10-01). A reader previewing it is told what Terminal access opens as questions about the project in view — full timeline, build evidence, usage history, the market around releases, holders and locks, contract intelligence, Ask HEY in depth, watchlist and alerts — filled from public identity only. Two ways in, said the same way everywhere and explained at /terminal/access (2026-10-03): hold $HEY in a wallet you sign in with, or request early access and an admin reviews it by hand. The same page's "Terminal vs free" table is built from what the code actually gates, so the Terminal never claims to lock what the public site and API already give away. The workspace Overview opens on the Research Brief, its lines led by What changed? · Build · Usage · Market · Contracts · Evidence. Ask HEY never dead-ends: each answer that cannot answer in full says why and offers next steps, including "Did you mean …" from the one search matcher.

One project is fully open in the Research Terminal for every reader (2026-10-03): every tab, the real data, no decoys — the console's choice, by default HEY's own project (since 2026-10-04, labelled as such), else the published project with the most the Terminal can draw. Every other project's research stays behind the gate. HEY's own project's row says "HEY’s own project — researched by the same rules" wherever it is listed. Each workspace opens on a coverage strip (Build, Market, Usage, Intraday — states, never a score); HEY Today folds a project's weeks of code into one line with "Show every row"; and, with the model layer on, the Overview leads with a pre-answered Ask HEY brief for the most-opened projects, written ahead of time from HEY's records, cached by their hash and held to half the day's AI budget.

The Research Terminal has a reader-facing guide at /docs/terminal (2026-10-04): what it is, what stays free, how to get in, a tour of every view, the command palette and keyboard shortcuts, how to read what it shows, and how to report a bug or ask for a feature. It is served only while the Terminal resolves, and a test holds it to the access figures, the workspace's views, the keys and the canonical sentences the code uses. Each step carries a real screenshot of the live Terminal, taken signed out on the sample project (what a signed-out reader cannot open is shown locked, as it is), drawn without layout shift and linked to the full-size picture. Since the same day's redesign it reads as a guide rather than a document: the answer and one primary action (open the sample project), three cards to start from, a table of contents, the access rules as short rows, the tour as one card per view whose screenshot and fuller explanation open in an accessible dialog, and the reading rules as definitions — about a quarter of its old length at rest, with the words still in one markdown file.

Search, What changed and Compare say one thing (2026-10-01). The header type-ahead lists projects first, labels an empty page that shares a researched project's name, and folds launch records of one name into a single row that opens the search page (emptyNamesake and moreLaunchRecords on /api/search/suggest, additive). A question typed into search is answered — a question about one project with its latest ship and Research Summary lines, anything else with where Ask HEY answers it — never "nothing matches". "What changed" is always /updates; HEY Signal is "Signals", and each page says what its count counts. "Compare with…" sits on every project page and under search results; /api/compare?a=&b= mirrors /compare?a=&b=, and each compared project carries valuation: { usd, kind, label } beside marketCapUsd, which may be an FDV. Explore names its sets in one line: published projects · research-ready · verified builders.

Round 3 (2026-10-01): "Evidence →" opens /evidence/<id>, the receipt in words — source, dates, whether it counts toward building and what it does not establish — with /api/evidence/<id> as "As data"; machine surfaces still cite the API. Section links are built from one list of the project page's anchors and only to a section the page draws. The type-ahead says "Several" where its read was cut, the project page holds one current liquidity figure (the rest, each named, are the market page's), and the market page names each date by what it dates.

HEY Signal's confidence (0–1) is a method statistic — how much evidence a rule read, which scales importance — never a probability or a trading confidence. The API keeps it; since 2026-10-01 no HEY page prints it, and /signals shows one row per kind per UTC day with its true count, opening to the projects.

Builder intelligence in your product, in one call — the Partner Card (2026-09-30):

curl -H "x-hey-integration: my-bot/1.0.0" "https://heyresearch.xyz/api/v1/builder?chain=4663&token=0x…"

Builder status in HEY's words, verified builder, the latest meaningful ship with its evidence id, meaningful ships in 30 days (null, never 0, when not measured), the latest builder-side change and signal, the token's market state as context, a badge and project_link — the page to link, labelled so HEY can count your click-through. Since 2026-10-05 the latest ship also carries evidence_link (its receipt page, labelled the same way), and partner answers are private, max-age=60: every call reaches HEY and is counted, never served from a shared cache. The fields, the rules of use and eight tested examples (Telegram, Discord, a trading terminal, a DEX, a launchpad, an explorer, a directory, an AI agent) are at heyresearch.xyz/developers/partners and in docs/PUBLIC_API.md.

The same thing, typed:

import { HeyClient, HeyApiError } from '@hey-research-lab/sdk';

const hey = new HeyClient();
const card = await hey.scanCard(4663, address);
if (!card.found) return null;

for await (const project of hey.projects.items({ tab: 'still-building' })) {
  console.log(project.slug, project.lastShippedAt ?? 'no ship recorded');
}

The developers page opens on a fifteen-minute quickstart (2026-10-05): the curl against a live contract, the typed hey.builderCard(4663, token) with new HeyClient({ integration: 'my-product/1.0.0' }), and a small React panel that prints nothing when HEY has no answer — with how evidence ids resolve (GET /api/evidence/{id}) and the rate limits the deployment enforces. HEY counts an integration as in use when an identified caller (a key, or a declared x-hey-integration name) is answered on two or more distinct days and five or more times within seven days; a name sent with no key is only observed until then, and the example names in these docs (my-product, your-product) and hey- names are never counted. That count is traffic, never an input to any project's status or rank.

A listed project with a token carries tokenMarket — the market state the card shows — and the single-project route sends everything the listing does. /api/projects/{slug}/market adds the contract's deployer, its pools and 1% depth, and a supply-concentration summary with no addresses (2026-09-25).

A Research Desk is a reader's published board of projects: GET /api/desks lists them by last change (never by popularity), and GET /api/desks/{slug} answers its projects, the curator's self-declared handle and its facts over its window — projects, shipped, development spikes, contract changes — with null and a reason for anything HEY cannot state (2026-09-30). Any signed-in account may curate and publish one; readers can report a desk, and HEY's moderators can take one down.

/api/projects/{slug}/relationships lists what a project is connected to and why HEY thinks so — every edge with its standing and evidence, never an account and never a "partnership" — and the snapshot's peerContext places some of its figures among comparable projects, one figure at a time, never as a combined score (2026-09-28).

The snapshot (/api/projects/{slug}/snapshot) opens on summary — one answer-first line per question (building, usage, market, contracts, security, the latest change, what HEY does not know), each tagged FACT, DERIVED or UNKNOWN with its evidence ids — and carries usage (calls and distinct caller addresses per day, never people, never summed into a window) and security (audits, bounties, security.txt, advisories; context, never a verdict). /api/projects/{slug}/usage adds the daily series (2026-09-28).

Paging follows the API's own cursor, a 429 arrives as HeyApiError with retryAfterSeconds and is never retried for you, and an absent field means HEY does not know — never a zero. A keyed account's monthly allowance is counted per UTC month; once it is spent every counted call answers 429 with the reset date until the first of the next month, and HEY's operators see the account as exhausted (from 80 % they see a warning) rather than learning it from the caller. A 503 service_unavailable with retry-after means HEY's database was busy for a moment; ask again (2026-09-30).

A value a listing cannot read is refused, never dropped into a wider answer: an unknown type or domain on /api/changes, an unknown Radar filter on /api/builders, like an unknown tab or sort on /api/projects, is a 400 invalid_parameter naming the values it accepts, and a change cursor past the end of the ledger is a 400 invalid_cursor. Only an unknown parameter name is ignored. The OpenAPI document states each of those vocabularies as an enum (2026-10-03).

For an assistant — thirteen read-only tools (fourteen where Market Integrity is published, as on heyresearch.xyz) over the same API, hosted or on your machine, listed in the Official MCP Registry as io.github.hey-research-lab/hey-research. The research profile at /mcp/research is builder intelligence first: no market-move, Under the Radar or valuation tool, while research_answer there still carries its agent contract's market context, labelled context only:

claude mcp add --transport http hey-research https://heyresearch.xyz/mcp

# or from npm
npx -y @hey-research-lab/mcp@0.3.2

# or from this repository
pnpm --filter @hey-research-lab/mcp build
claude mcp add hey-research -- node "$PWD/apps/mcp/dist/index.js"

Full reference: docs/PUBLIC_API.md · docs/MCP.md · docs/INTEGRATIONS.md — the line to render, the three answers to handle, and the four things not to do.

The open ecosystem

Ten more repositories sit beside the mirror, each independent, MIT and Robinhood Chain only: hey-project-manifest (the /.well-known/hey-project.json declaration — declared, never verified), hey-ship-action (ship evidence from a GitHub workflow), hey-agent-contract and hey-research-receipts (the public agent and receipt contracts, byte-faithful with parity tests), hey-cli, rhchain-registry (sourced infrastructure registry), chainprint (offline Robinhood Chain marker detector), hey-embed, hey-telegram-bot (read-only, public API only) and hey-data (snapshots of HEY's own facts, CC BY 4.0; no market or provider data), and four agent-framework plugins — plugin-hey-research (ElizaOS), hey-agentkit (Coinbase AgentKit), hey-goat-plugin (GOAT SDK) and hey-virtuals-plugin (Virtuals GAME and ACP) — each read-only over the published SDK — and hey-agent-skills, the hey-research Agent Skill and Claude Code plugin. None reads HEY's database; production does not consume any of them yet. HEY serves its own manifest at /.well-known/hey-project.json, derived from the machine identity, as the working reference; /developers?tab=sdk#open-source maps each package to its job. An outside-in check on 2026-10-02 (fresh clones and npm installs as a builder, a developer and an agent) led to 0.1.1 of nine of them.

The fixes HEY sends to other projects' repositories are listed at heyresearch.xyz/contributions ("Contributions"): the pull requests hey-research-lab opened outside its own repositories, merged, open and closed, read from GitHub once a day (adapters/github-upstream-pulls.ts). Pull requests only, never issues; the list changes nothing HEY researches.

For autonomous agents

From the domain alone, with no JavaScript and no cookies:

Entry point

What it is

https://heyresearch.xyz/llms.txt

What HEY is, what it will not do, every machine entry point (llms.txt v2)

https://heyresearch.xyz/.well-known/agent-card.json

A2A 1.0 Agent Card; JSON-RPC at /api/a2a, six read-only skills

https://heyresearch.xyz/openapi.json

OpenAPI 3.1 for the public API

https://heyresearch.xyz/mcp

Hosted MCP (Streamable HTTP); listed in the Official MCP Registry as io.github.hey-research-lab/hey-research (apps/mcp/server.json). Every tool returns typed structuredContent with an outputSchema

https://heyresearch.xyz/mcp/research

The MCP research profile: builder intelligence only — research_answer, a project lookup by identity, the ledger without market events, timeline, explain, evidence, contracts; no market-move, Under the Radar or valuation tool

https://heyresearch.xyz/api/hey/profile

$HEY as research data: each utility LIVE, PLANNED, RETIRED or UNKNOWN

https://heyresearch.xyz/developers/agents

The guide (Markdown at /developers/agents.md)

https://heyresearch.xyz/api/agent

The agent contract: research_project, what_changed, builder_status, verify_project, compare_builders, unknowns — the same answer on REST, MCP (research_answer) and A2A

https://heyresearch.xyz/developers/robinhood-agents

HEY for Robinhood Agents: the questions, the four interfaces, the evidence model and privacy. Integration readiness; HEY Research Lab is not currently an official Robinhood Agent App. A demo that answers four questions from live data is at /lab/robinhood-agent

Start in one minute — each of these was run against production before it was documented; no key, no account, no install for the hosted doors:

claude mcp add --transport http hey-research https://heyresearch.xyz/mcp        # Claude Code, hosted
# any MCP client, hosted:  { "mcpServers": { "hey-research": { "type": "http", "url": "https://heyresearch.xyz/mcp" } } }
# any MCP client, local:   { "mcpServers": { "hey-research": { "command": "npx", "args": ["-y", "@hey-research-lab/mcp@0.3.2"] } } }

# REST end to end: find a project that shipped this week, read it, open the evidence behind it
BASE=https://heyresearch.xyz
SLUG=$(curl -s "$BASE/api/projects?tab=shipping-now&limit=1" | jq -r '.items[0].slug')
ID=$(curl -s "$BASE/api/projects/$SLUG/snapshot" | jq -r '[.summary.lines[].evidence[]?.id][0]')
curl -s "$BASE/api/evidence/$ID" | jq '{id, summary, sourceUrl, verification}'

The same flow in TypeScript, with A2A and a raw MCP call, is on /developers/agents. Name your software (an MCP clientInfo name, or x-hey-integration: <name>/<version> on REST, A2A and — for a stateless MCP client that never sends initialize, since 2026-10-10 — on each MCP call) so HEY can tell an agent's use from a registry probe when it counts use — your own name, not the my-agent of the examples, which HEY files as a test client; it changes no answer. The hosted endpoint answers JSON to a client that accepts application/json alone (2026-10-05).

An agent that forms a thesis can record it as an AgentResearchReceipt — neutral, for any project, checked but never stored or endorsed by HEY. HEY gives no trade instructions and runs no agents of its own. HEY is not an official Robinhood Agent App.

The agent contract has a deterministic quality benchmark (packages/agent-provider-core/src/benchmark): 75 questions from "What has AgentOS shipped recently?" to "Which token should I buy?", each mapped to one call by a checked-in table, judged on the schema, evidence, unknowns, freshness and the absence of any trading output. Run it against a deployment, read-only and paced: pnpm --filter @hey/agent-provider-core bench -- --base-url https://heyresearch.xyz.

An adversarial review from eight perspectives (a platform PM, an integration engineer, compliance, security, an AI platform engineer, a builder on the chain, a trader and HEY's own methodology) tightened the contract, additively: what_changed leads with what counts as building and takes building=only; a comparison says when it did not happen; the 64 KB bound is held when an answer is made; invisible Unicode tag characters are stripped and instruction detection reads normalised text; a caller's text is never repeated back as HEY's words.

A design and data-wiring audit (2026-10-01) held the same rule on the answers: a null latestMeaningfulChange now carries latestMeaningfulChangeReason — not_in_recent_changes when HEY holds meaningful building that is not among the newest changes listed, so null is never read as "none" — and the explain engine calls a project Under the Radar only on a positive gap, as /radar does.

Every line of a project's Research Summary (summary.lines on the snapshot) carries a basis: a FACT either cites typed evidence ids or names a basis no evidence id can cite — a market reading, a usage reading, HEY's own registry record, a field of the canonical read, the change ledger or a coverage state. A FACT with neither is never published as a FACT.

The Uniswap v4 hooks directory (2026-11-05)

/integrations/uniswap/hooks lists the Uniswap v4 hooks HEY ties to a published project on Robinhood Chain, one row a project, with how each tie was made and its receipt, and apart from them the hooks Uniswap's hooklist lists that HEY ties to no project. Every hook on the page is also a line of the daily CC BY 4.0 snapshot, /data/latest/hooks.ndjson.gz (and hooks.csv). HEY never publishes the account that created a hook.

Agents on Raeto (2026-10-29)

A project whose AI agents run on Raeto may turn on Raeto's public activity sharing. HEY then shows, on the project's page after the builder story, how many model calls its agents made in the last 7 days, by UTC day, with when HEY read it and a link to Raeto. It is matched to a project only through the project's own website or its confirmed official X account, never a name. It is activity, never spend: HEY reads no wallet, balance or spend figure. A project that stops sharing reads "no longer shared". It is context only, like product usage, and changes no status, score or order.

Stock Tokens (2026-10-29)

heyresearch.xyz/stock-tokens lists Robinhood's Stock Tokens on Robinhood Chain alphabetically by ticker and, under each, the published projects whose own official repository names its contract in code — never a test, a fixture or a list. Each entry also shows, from Robinhood's own Stock Token feed and with when HEY read it, a corporate action Robinhood announced (the shares-per-token multiplier changing from one figure to another) and the sessions the feed lists as tradable. Since 2026-11-05 HEY also reads each token's own contract, so a corporate action scheduled on chain is shown with the time it takes effect even when the feed lists none. A project page prints one line, "Names Stock Tokens in code: …". A name in code is a reference: it shows neither a dependency nor use. It is context only: a Stock Token is never a project's token, usage, valuation or market, HEY stores no on-chain interaction between a project and a Stock Token, and nothing here changes a status, score or order.

Plainer labels, fewer dead ends (2026-10-28)

A market whose readings HEY cannot confirm now carries one label, "Readings not confirmed", on the card, in the API's display label and in the summary alike. Under the Radar and Still Building each have one definition used everywhere, and Still Building's names the valuation drawdown it measures. An official X account whose link is held no longer counts as "has X", sixteen natural URLs such as /check and /faq redirect to the page that answers them, and a project's share page fits a phone screen.

Shorter passport stamps and a faster platform (2026-10-27)

A Token Passport stamp now credits the protocol with its link and a short label ("Locked at HoodLock", the next date), and leaves the full sentence to the page, which already prints it. The RHTools chart link is no longer a stamp, since HEY reads nothing from RHTools; it stays among the page's links, so a token with no lock, launch record or hook shows the empty passport. DeFi TVL figures from DefiLlama are read again after DefiLlama began serving its registry as text/html, and several slow background reads are faster (a search-key rebuild from 13–40 s to about 1.5 s).

Faster search (2026-10-26)

Sorting a search or the Explore list by newest no longer reads the whole catalogue backwards: it went from 2.4 s to about 0.1 s. A search for a common word now shows the matching projects at once and loads the launch records that share the word just below them, instead of waiting for both. Nothing a reader sees changed except the time.

Token Passport (2026-10-26)

A token's page on HEY carries a passport of stamps from other Robinhood Chain protocols — a HoodLock lock, the launchpad that minted the token and its graduation, the project's Uniswap v4 hooks, its RHTools chart — each a fact HEY already reads, crediting the protocol by name with a link. It sits after the builder story and the timeline, changes no status, score, badge or order, and nobody pays for a stamp. An empty passport says so in one sentence about what HEY reads, never "none" about the token. heyresearch.xyz/passport explains the stamps and how a protocol on Robinhood Chain joins.

Proof of Ship (2026-10-24)

HEY can sign what it counts. GET /api/v1/proof-of-ship/attestation?slug=&builder=&since=&until=&escrow= answers how many of a published project's ships HEY counts as building in a window — by the same rule as its activity status, and only ships HEY first recorded inside the window — with each ship's evidence id and receipt page, signed as EIP-712 typed data for the open-source ShipEscrow contract, which pays a builder only when HEY attests the project shipped after the bounty opened. HEY signs only for a payout address its evidence already ties to the project: the signer of a verified wallet-signature claim made for its tracked token (never one proved only as the fee recipient a Pons launch names), or that token's recorded deployer, while the token stands as the project's own. Each kind of ship counts at most once per day HEY first recorded it, and only ships HEY first recorded before the window closed. The signature says what HEY counted, never that a project is good or worth funding; it changes nothing on HEY. Details in docs/PUBLIC_API.md.

Data repairs (2026-10-24)

A GitHub ship counts only while its repository is still the project's own source: a renamed repository HEY holds as context holds its ships, and a ship whose repository the project no longer lists is recorded as context. Official project sites keep a share of HEY's daily site reads, hosts that keep failing are backed off, and feed reads are metered.

Frontend housekeeping (2026-10-24)

The sign-in page loads wallet code only when a reader chooses the wallet door, and its link returns to the page the reader is on. Addresses, counts, percentages and dates each print through one formatter, and status values are checked once against the stored enums. Older whitepaper and deck editions redirect to the current ones.

Reliability pass (2026-10-22)

A full audit of the site, API, MCP server, Telegram bot, pipelines and deploy scripts, fixed the same day: faster deep catalogue pages and cached counts, logos and share images served from HEY's own stored copy (never an SVG decoded), unknown values sent as null instead of 0 across the API and MCP, Telegram captions and handles read correctly, and a deploy that refuses unverified commits and restores the previous release on failure. API changes are dated in the API changelog.

What counts as shipping (2026-10-02)

Outside readers found automation leading the ship feeds. Since 2026-10-02 a commit from a bot account (*-bot, bot e-mails) or from an automated stream — one templated message repeated on a clock, or carrying its own changing timestamp or figures — is kept on the record and never counted; a CI-only commit is maintenance; a week of 25 or more commits counts as building only when 3 of a 10-commit sample change code (commit-substance-v3). Date-stamped automated tags (data-2026-10-01, backend-202610010354-6802318) are rolling tags; a sitemap, an oEmbed card, a comments feed or (since 2026-10-07) any feed on HEY's own host is never a release feed, and a reader's comment or a HEY page is never a ship. A launch pool is "Launch pool only", never a measured market: no Discovery Gap, Under the Radar or Still Building. A project with no repository, changelog or feed linked reads "No builder source linked", never Dormant. Sources are read on their project's current tier, HOT first. /ships, /this-week and "Recently shipped" put releases and launches above commit summaries within a day, show a repository's releases of one day once and one GitHub release once. A repository that only lists Robinhood Chain among many chains is no longer published as a Robinhood Chain project; the pages published before the rule are held only by one reviewed command, pnpm data:publication-holds (reversible, logged).

Since scoring hbm-v23 (2026-10-03) a release burst is one ship: a repository's full GitHub releases of one UTC day count once — the newest corroborated one stands for the day — in activity status, Build Momentum and every count of building. Prereleases keep their weekly rule, two repositories on one day count as two, a release whose ship id names no repository is never collapsed, and every release stays on the timeline. Chain feeds show the burst as one line ("27 releases in owner/repo on 1 Oct") and /signals announces it once, by count.

Since scoring hbm-v24 (founder ruling, 2026-10-03) a deploy batch is one ship: a project's follow-up contract deployments recorded in the same UTC second count once — the newest corroborated one stands for the batch — in activity status, Build Momentum and every count of building. Deploys a second apart count apart, an upgrade is never part of a batch, and every contract stays on the timeline with its creating transaction. Chain feeds show the batch as one line ("4 contracts deployed by the project's deployer at 16:02:38 UTC on 30 Sep") and /signals announces it once, by count.

Since 2026-10-16 a follow-up deploy is found within about an hour: an hourly Bitquery read asks which of the watched token deployers created a contract since the last read, and those deployers are read at once through the explorer, exactly as the daily or weekly deployer watch reads them. The explorer read alone records the ship, dated to its block with its creating transaction as evidence, and every follow-up rule applies unchanged; the Bitquery answer is a trigger, never evidence, and nothing from it is stored.

Since scoring hbm-v25 (2026-10-07) Resumed building is called only on a gap HEY watched: every ship of the comeback must come from a source HEY was already reading when the gap began — the earliest attachment of the sources its evidence names, at or before the last update before the gap. A repository HEY began reading during the gap, or a ship whose source HEY cannot name, is not a return: the project reads Shipping or Active by the ordinary rule, and the score says why (resumedWithheld). The 14-day window and the 60-day gap are unchanged.

Since scoring hbm-v29 (commit-substance-v4, 2026-10-15) a dependency bump is maintenance. A manifest (package.json, composer.json, Cargo.toml, go.mod, requirements*.txt, pyproject.toml, Gemfile) counts as a lockfile when HEY has read its patch and every changed line is a dependency's version, the package's own version or the toolchain's. A commit of nothing else reads "dependency or version updates only" and does not count as building. A script, a field, a dependency added or removed, a git or URL spec, or a patch GitHub did not return keeps the manifest configuration, which counts.

A week of code activity has one title everywhere (2026-10-03): "Code changes, week of 2026-09-28 – 2026-10-04", the fixed UTC week it is keyed on, on the ledger, the API, the partner card and every page; pages that read the week add its own commit count. "Week of" always names the Monday. Every count of meaningful events — the snapshot, the agent answers, the Terminal — is the scorer's: a week HEY read as documentation only counts nowhere. Rows written before are rewritten by one logged, reversible command, pnpm data:code-week-titles.

Calmer public pages (2026-10-24)

A project page says each fact once, shows the newest 8 timeline entries before "Earlier ships", folds maintenance-only code weeks to one line, and draws a section only when it has something to say. Empty public pages (research queue, bounties, Built with HEY, desks, the vote) are noindex and out of the sitemap until they have an entry; the roadmap carries no execution or market-alert items.

Following and what changed

Follow a project and it joins your private watchlist; the project page then offers the alerts that can fire for it — a release, a contract implementation change, building resuming, an official docs or site change — as one press. In the Research Terminal, Follow carries one box, ticked by default, that turns on alerts for every project you follow: a release, a contract deploy, an implementation change, an unlock due within 7 days, a Market Integrity event or an activity status change — never a price or trading alert. An empty watchlist is offered a starter set of recently shipping projects to choose from (never read from your wallet), and a daily email of what changed on the projects you follow is one switch away (off by default, to a confirmed address only, nothing on a quiet day). /updates is the public "What changed": the change ledger grouped by meaning, and, signed in, what changed on your projects since you were last here first. Every row, alert email and Telegram alert opens the change on the project's page, with its source. The HEY Telegram bot (2026-10-05) answers a lookup the way a card does: a bold title with the status as text ("🟢 Shipping"), one canonical sentence, one short line per fact, one "context, not a verdict" note, and buttons to the project, its evidence, a share and — in your own linked chat — Watch. /start opens with a banner and a menu; groups get text and public links only. Since 2026-10-05 the bot travels between chats: type @HeyResearch_Bot $TOKEN in any chat for a selectable research card (inline mode), mention it in a chat it is not in (Telegram's Guest Mode) — or reply "research this" to a message naming a contract or ticker — and "Add HEY to a group" puts it in your own. In a group it stays quiet unless asked; its admins can have it watch projects and send the group's meaningful builder changes (at most three messages a day) or one daily digest. Never price, never a group's conversation, never anyone's private watchlist. Since 2026-10-09 an address or ticker HEY has not published answers with what HEY holds — its record, launch, the card's market reading, the links its listing declared (as unverified text) and every token sharing the symbol, with a true count — and an explicit request in a chat reads the address live through the same HEY Scan as the website, after the bot has answered and within per-reader and per-group limits (never in inline mode or Guest Mode). Its cards carry the token's on-chain context after the builder story (2026-10-09): the day's transfers and trades, the distribution in the market page's words, pools and depth, the lock and the contract — dated, two short lines in a shared card, never an address. It is a community channel and says so on /start, /help and the Mini App (2026-10-10, Robinhood Chain Terms of Service §5.6(d)(i)): "Community-run by HEY Research Lab · not an official Robinhood channel." A HEY badge is "Verified by Hey Research Lab from public evidence — not a Robinhood certification." /telegram (2026-10-06) is a small page with one way in — Try HEY in Telegram — the commands, inline mode, Guest Mode, the group watch and what HEY keeps; it exists only while the bot is switched on. The HEY Mini App (2026-10-06) is the same research inside Telegram: open it from the bot's menu button or a card's "Full research", search a project, $TICKER or contract, and read its builder status first, then its latest ship and evidence, its recent ships and the market's state as context; Share sends the bot's research card to a chat, Watch opens the bot on that project. It is read-only, takes your Telegram theme, keeps nothing about who opened it, and works as an ordinary page outside Telegram. HEY counts how the bot spreads as groups added, groups activated by someone outside HEY's staff and groups that come back on two or more days — never people, never a chat's messages — and keeps a link from one group's card to a new group (measured) apart from a mere coincidence in time (estimated); neither is called a referral. An alert email's links carry utm_medium=email&utm_campaign=alert (2026-10-05), so HEY can count that an alert brought a reader back — a count of returns, never who returned.

Without an account (2026-10-02): /feed/updates.xml and /project/<slug>/feed.xml carry the public change ledger, each item dated by the event's own date and keyed on its ledger id, and every page with a feed declares it in its head. An email address alone subscribes to the weekly digest, a daily digest or one project's changes — double opt-in, one-click unsubscribe that deletes the address, nothing else stored. Data checks (two of HEY's own readings disagreeing) fold under their own heading; "+N more" opens the kind's full list; "Today" is a UTC calendar day. Telegram alerts are not available yet.

A correction is not news (2026-10-03): every "what is new" window — Today, What changed, /updates, the email digests and alerts — dates a change by when it first reached HEY, and a later revision (a repaired title, a return after a retraction) keeps that time, so history revised later never comes back as new and never alerts twice. /api/changes and webhooks still deliver each revision in ledger order, so a mirror receives the corrected content.

For builders

/builders/guide is the one-screen checklist: get researched, get linked, read as shipping, become a Verified Builder, claim (GitHub, or a wallet: the token's launcher, owner or creator, or the fee recipient its Pons launch names), keep the page accurate, show the badge. A contract your site links on the explorer becomes a declared contract HEY watches once the chain confirms it holds code; a verified owner can add product contracts the same way. Every surface prints one status label, and a share leads with the strongest true fact.

Sharing a record

Any eligible record — a ship, a release, a deployment, a development spike, a builder resuming, a verified builder, a contract implementation or interface change, a HoodLock lock or unlock, a material change to a project's official site, a weekly report, an event window — can be shared from its page as a ready-made post for X or Telegram, a short plain text, a link or its raw facts. The words come from one deterministic template module keyed by change type: the project first, only facts HEY holds (a sentence is dropped rather than filled when a fact is unknown), with its evidence id and source, and never promotional language. GET /api/share/<subject> returns the same composition as JSON.

A project page opened from a HEY badge, widget, partner card, shared link, the Telegram bot or an agent's answer says so in one quiet line, in fixed words that never repeat what the link carried, with HEY's thesis and a way to the Research Terminal's open sample project. The campaign labels the link carried are counted once and then removed from the address bar, so a copied link does not carry them on. Counts are per day-bound tab session; nothing joins two days or a visit to an account.

A project's whole research summary can be shared too ("Share this research", subject research:<slug>): a post that carries the building lines and never a market figure, and a citation that lists every summary line with its tag (Fact, Derived, Unknown), when HEY read it, and each evidence id with its page and its receipt, ending in a link back labelled utm_source=cite. A weekly builder recap (recap:<slug>) states the canonical 7-day count of meaningful development events and the newest meaningful ship, and exists only for a measured week with at least one. Usage resuming after a silence (contract.method_resumed) is shareable as usage, never as building. /researchers walks the path: search, the summary, building beside the market, the evidence, the citation. Nobody is paid, rewarded or ranked for sharing.

Event research

/events/<slug> answers "What actually changed on Robinhood Chain during ?" from HEY's change ledger inside the event's official window. Announcements made at the event are listed apart with their official source and are never counted as shipped. The first is HOOD Summit '26 (/events/hood-summit-26).

Around a ship

A project page shows what HEY observed in the week before and the week after the project's latest ship — the token's price move, volume and liquidity, and its contracts' calls and distinct caller addresses — each with its state and source, and only where it was measured. The Terminal chart shows the same for any event a reader selects, and GET /api/projects/<slug>/around/<eventId> returns it as JSON. Observed around the same time: HEY never claims a release caused a move. Collection starts at the first price, liquidity or volume reading — not at a day that holds back-filled trade counts alone — and a ship before it says when HEY began reading (market.collectedFrom, usage.collectedFrom). For days HEY never read itself, the price and volume come from the provider's daily archive of the same pool (GeckoTerminal's OHLCV, read once and kept apart from HEY's own readings): every such row says "provider archive", with the source and when HEY read it, and the archive never supplies a liquidity or a valuation. It is display context only — no status, score, gap, badge, signal or order reads it.

HEY also runs this across its whole record, for its own use (rules before-attention-v2): every meaningful ship it knew of at the time, set against quiet builders on the same days. T0 is when HEY first held the work, never the source's date; work HEY read late or the change ledger took as backfill is excluded and counted; every exclusion, every unmeasured window and both tails of the case studies are shown. It is an analysis, never a forecast or a market signal, and nothing that decides a status, a score or an order may read it.

Uniswap on Robinhood Chain

HEY links a project's token to its page on the Uniswap web app when the chain shows it in a Uniswap pool — liquidity in Uniswap v4's published PoolManager, or a pool Uniswap's published v2/v3 factory created. A venue a data provider merely names "uniswap" is not enough, and forks are never called Uniswap. Market activity never affects HEY's builder research. See https://heyresearch.xyz/integrations/uniswap. Uniswap is a trademark of Uniswap Labs; HEY Research Lab is not affiliated with or endorsed by Uniswap Labs.

HEY also records which Uniswap v4 hook contract each v4 pool on Robinhood Chain names, from the PoolManager logs its pool scan already reads, and which hooks a launch protocol's own event names. A hook is kept as a contract — never an account, a pool count or a volume. Since 2026-10-02 HEY reads who created each hook from the explorer, compares the sender with the account that launched a tracked project's token, and keeps only the outcome. A hook the project's own token deployer created is recorded as an ordinary follow-up deployment, counting exactly like any other contract it deploys; a hook a launch protocol or a factory created is context. Each attributed hook has an evidence id, v4hook:<chainId>:<address>.

Since 2026-10-04 the hooks HEY ties to a published project are listed at https://heyresearch.xyz/integrations/uniswap/hooks and as data at GET /api/v4-hooks: each with the project's activity status, how it is tied and its receipt, when it was deployed and first used, the callbacks its address declares, and market context labelled as context — newest deployment first, never ranked. Every other hook is one aggregate count, never listed or grouped by who created it. The deployment of a project's hook is one ledger event that says it is a hook (facts.v4Hook), and a hook the project only declares gets its own canonical event; both reach What changed, alerts, RSS and webhooks like any contract deployment.

The list shows one card per published project, its hooks inside, the project with the newest hook deployment first (GET /api/v4-hooks adds the same grouping as projects[]). HEY also reads Uniswap's public hooklist (github.com/Uniswap/hooklist) once a day, conditionally, as context: for a listed hook it shows "Listed in Uniswap's hooklist as ", linked to the file at the commit it read, and both readings when the listed flags and the address disagree. It keeps the name, flags, properties, path and commit only — never the list's descriptions or deployer accounts — and a listing never ties a hook to a project. Coverage is counts: how many listed hooks HEY has seen in a pool, and why the rest are missing (HEY finds a hook when a pool is created with it).

The hooklist is also a source of leads for HEY's own attribution, never proof: a listed hook is read ahead of unlisted ones in HEY's creation-read queue, first when the listing's claimed deployer equals a published project's recorded token deployer (compared in memory; only the outcome is kept, never the account). HEY's own read of the creator still decides every attribution. Listed names that match a project's name — never on generic words such as launch, meme, token, swap or hook — are shown to HEY's own moderators as leads, never publicly.

Since 2026-10-04 the list names every project shipping a hook that HEY can tie to it, each hook labelled by what the tie rests on: "Proven on chain", "Listed by the project", "Made by the project's factory" or "Confirmed by HEY's review". A hook a factory contract created is listed under a project only when HEY ties the factory itself to it — the factory is the project's own follow-up deployment, read from the chain, or the project's official contract listing names it — and then once per project, as a count with a few examples: instances are the factory's product in use, never counted as the project's shipping. A hook can also be confirmed by HEY's review: a person checks it against the project's own material, the confirmation is audited and reversible, and it is labelled apart from chain proof; it never counts as shipping, and HEY's own reading of the chain supersedes it. Neither is a ledger event. Who created a hook or a factory is compared in memory and never stored.

Since 2026-10-04 the list is wider and fills faster. HEY reads 1,400 hook creation records a day, leaving the other explorer work what its own record says it needs, and reads last the hooks whose first pool was created through a launchpad's own factory (the chain's node says so; they are still read). A hook one of a project's qualified linked addresses created — the deployer of its token or of a contract it lists, the signer of its verified on-chain claim, a treasury it published, its launch or liquidity manager — is listed as "Created by an address linked to the project", the relationship named, never the address, and never counted as shipping. Builders' own submissions to Uniswap's hooklist that name a project's official website are shown to HEY's moderators as leads to confirm by review; HEY keeps only the hook address and the website host from them.

Terms and privacy

What HEY records about a reader, what it never stores and for how long: https://heyresearch.xyz/privacy. The terms of using the site, the API and the MCP server — research, not advice; no trade execution; keys, allowances and limits; and Uniswap Labs' own terms for quotes: https://heyresearch.xyz/terms.

Signed-in readers can download everything HEY holds about their account, or delete it, from their account page; what deletion keeps (the treasury's record of a transfer, a closed vote's tally, published research, the audit trail) stays with nothing linking it to them. Anyone signed in can report an error on a project page; a moderator checks it against the page's sources, and a report never changes a status, a score or a ranking by itself.

Who runs HEY, what it is not and how it is funded: https://heyresearch.xyz/about. What HEY's words mean, in plain language: https://heyresearch.xyz/glossary. What HEY got wrong and fixed — accepted error reports and the changes it withdrew from its own record, never naming a reader or a hidden project: https://heyresearch.xyz/corrections.

The badge

Any project HEY tracks can embed its own status. It updates itself, and it links back to the evidence behind it.

HEY Research Lab on HEY

[![My project on HEY](https://heyresearch.xyz/badge/<slug>.svg)](https://heyresearch.xyz/project/<slug>?utm_source=badge&utm_medium=readme)

The link's utm_source=badge lets HEY count a click from your README as the badge's, as a number and nothing more.

?theme=dark and ?style=pill are the other two looks. docs/BADGES.md on the site.

Share pack for builders

Every verified builder's page has a share pack at https://heyresearch.xyz/project/<slug>/share: what HEY verified (status, latest ship and its evidence, the sources HEY reads as yours), the claim link, a ready X post, a Telegram message, a plain text for a token page or social terminal, the README badge, the website embed and the canonical links. Every sentence is generated from what HEY recorded — no price, no forecast, and a figure HEY did not measure is left out, never shown as 0. HEY posts nothing for you.

The HEY GitHub App (optional)

When HEY's GitHub App is live, a builder can install it on the project's repository from the claim page or the share pack. Installing it proves the HEY page is yours (for the HEY account that started the install, when your own GitHub account installed it), and HEY re-reads the repository a minute after you publish a release or push to your default branch — the same rules decide what counts as shipping; the app never counts anything by itself. Read-only by default (Metadata and Contents read). An optional pull request adding the badge to your README is opened only when you press for it, on a new branch, and never on your default branch. It never changes a status, a score or an order.

Live widgets (Embed Kit)

A live builder widget for any site — activity status, the latest ship, meaningful ships in 30 days, verified builder, or the latest changes — from HEY's own records, with no price, score or rank. One script, one element; the configurator at heyresearch.xyz/developers/embeds also hands out a React snippet and the API call.

<script src="https://heyresearch.xyz/embed/hey-project.js" async></script>
<hey-project project="<slug>" variant="builder" theme="auto"></hey-project>

The script reads only its own attributes, sets no cookie and draws one sandboxed frame; HEY counts that a widget was shown and the host's domain, never who saw it.

Coverage of the chain

HEY reads every launchpad factory it has a verified entry for and, since 2026-09-30, the chain's own Uniswap V2 and V3 factories, so every token that was launched or given a pool becomes a token record. A token is not a project: a record becomes a public page only through the quality gate. To find the builder behind a token, HEY asks GitHub which repositories name the token's contract and links one only by a corroborating tie — the token itself declared the repository and it names the contract back, or the repository's homepage is the token's own site. It also reads the deploy records in each project's own official repository — a Foundry broadcast, a hardhat-deploy network or a deployments file for chain 4663 — and a record that names a token HEY holds ties that token to the project (a fork, a token list, a mock or a reference to someone else's asset never counts). Explore's "With a token" view says how many token contracts HEY knows, how many reached a page and how many of those carry the builder's repository, and how that repository is tied to the token; for the rest, the builder is not found yet.

Decoded trades name what the factories miss. Two lanes read every token traded on the chain over a rolling 120 days — a UTC day at a time at twenty distinct traders, and a UTC hour at a time at two for a known launchpad's venue — and keep a ledger of the days and hours read to the end, so a settled one is never asked again. A slice the provider's ten-page ceiling cuts short is halved until it finishes. Bitquery meters in points, so each request books its measured cost and the day stops at 85% of the plan's share; a backfill reads only while a third of the day's points remain.

Counts

Every public count names its set, links to the list it counts and says when it was counted. The verified builders on Robinhood Chain (the Verified builder badge plus chain evidence) and the badge on every chain are two figures with two names; the strip's "shipping now" is the Shipping tab's own count; /methodology#counts lists every figure with its scope; /api/projects returns the same figures in catalogue, scoped and dated, beside the unchanged verifiedBuilders.

Rules that do not move

  • Building is not price. Market cap, liquidity and volume are context and filters. Nothing in packages/scoring reads a price or a balance; a neutrality test fails the build if it ever does.

  • Paying changes nothing organic. Bounties, sponsorships, claims and $HEY holdings never move a rank, a status or a score.

  • No wallet analytics. No PnL, no smart-money or whale labels, no wallet profiles, no clustering presented as a claim about people, no copy-trading. The schema guard fails the build on the words. One exception, decided on 2026-09-14: a bubble map of a single token's largest balances on that token's market page. An address there is a point on a chart of one supply — never a person, never scored, never ranked across tokens, never an input to any status or score.

  • Absent means unknown. A figure HEY has not measured is omitted, never published as zero. A Discovery Gap is measured only on an active market (2026-09-30). On a thin market or a launch curve it reads "not measured — market too thin", and the API says why (discoveryGapWithheld). Still Building is measured on the same markets only: elsewhere it is "not measured", never "not met" (stillBuildingWithheld, scoring hbm-v19), and stillBuildingState (HELD, NOT_HELD, NOT_MEASURED) sits beside every stillBuilding. A market active only because another pool of the same token holds the liquidity is measured on that pool's reading, never on the thin pool, and not at all when HEY holds no reading of it; a project with no tracked token, or whose building HEY cannot read, is "not measured" too; and Under the Radar is stored only beside a positive gap (scoring hbm-v21). Since then a gap, Under the Radar and Still Building are also withheld, never 0, on a launch pool, a market under $1,000 of 24-hour volume, a reading over a day old, unreadable activity or a contested unverified ticker, and Under the Radar needs attention below the 60th percentile (scoring hbm-v32); the full list is on /methodology.

  • A valuation must be plausible from the readings HEY has. A market cap or FDV at least 10,000× the liquidity in the same reading, or above $10B on a Robinhood Chain token no listing HEY reads carries, is never printed, never FACT and never a scoring input; it reads "Not plausible" with its reason (valuationWithheld, scoring hbm-v20).

  • HEY's own token is researched by the same rules. $HEY's card says "HEY’s own token — researched by the same rules", and the API marks it heysOwnToken: true. The flag is set after a list is ordered: no bonus, no demotion.

  • A borrowed brand is not an affiliation. A project whose name or ticker uses Robinhood's name ("Robinhood", or "HOOD" as a word) is kept off the homepage, Under the Radar, the featured spots and the Builder Radar until HEY verifies a builder behind it — and a name that claims Robinhood's authority ("official", "team", "labs", "foundation", "inc" beside it) stays off even then; its page stays open and says HEY holds no evidence Robinhood is involved.

  • HEY's own project has no pinned place. It takes its position on every list by the same rules as every project.

  • A site two projects declare is neither's. Its host is read the same way everywhere (a query string or a port does not make a second site), and a platform's page — a launchpad listing every token it launched — never counts as a token's own site, even when it prints the contract.

  • A rolling tag is not a release. A GitHub release cut from latest*, nightly*, *-debug, edge, canary, dev or snapshot is kept as context, never counted as a ship.

  • A day is a UTC day. Every daily figure and window keys a UTC calendar day, whatever the clock of the machine that computed it.

  • Security is evidence, never a verdict. An audit shows an audit took place; it is not a guarantee of safety. HEY says where a report is published and where it found the link — no score, no "safe", and "no advisory found" is a reading of one index, never a clean bill.

  • A model is never the source of truth. AI-assisted interpretation is optional and off by default; when on, it reads only HEY's own evidence, cites it by id, is labelled as an interpretation, and never moves a status, a score or a rank. AI_PROVIDER accepts disabled or anthropic only.

  • Product analytics count research, not people. HEY's first-party counts (2026-10-01) record that a reader opened evidence, followed, set an alert or got an answer — a fixed word each, never a question, an address or an account; staff and crawlers are not counted. A useful session is defined in code; usage never reaches a status, a score or a ranking.

  • Every claim carries its source. And none of them is a buy signal.

The full rules, with the thresholds they use, are on the methodology page.

$HEY, briefly

$HEY (0xB33eb16782776b4D738c0Fd643577cb0284Db610 on Robinhood Chain) pays for evidence: research bounties set in dollars and paid in HEY, claim bonds, and priority on research requests. Holding changes what a reader pays, when they see new research and how much API the lab serves them; $HEY worth at least $500 at the time of HEY's daily balance check, valued at HEY's own market reading, also opens the Research Terminal beta — kept while it stays at $450 or more, with one day of grace and a warning below that. It never buys a rank, a status or a score.

The 2% creator tax paid to the treasury is spent in three equal parts: research bounties, infrastructure and data, platform operations — never a buyback. HEY's ledger records the HEY its research economy moves, with each transaction; the creator tax arrives in ETH and is not recorded there yet, so no monthly statement has been published. The advisory research-funding vote runs in rounds the founder opens by hand; none has been opened yet (2026-10-03).

How this repository is produced

A script in the private repository copies the paths listed above, generates a types-only @hey/db, refuses to publish anything that must not leave (archives are opened and scanned too), verifies the copy with the private lockfile's exact versions and no install scripts, and pushes one commit per sync. This repository's own CI installs from that same lockfile; there, only the packages named in pnpm.onlyBuiltDependencies in package.json may run a build script. The pnpm data:* commands this README and docs/ mention are HEY's reviewed operator commands in the private repository; they are not part of this one. Issues and pull requests are welcome here: a change accepted here is applied privately and comes back in the next sync.

HEY reports what teams ship and whether a tracked token still has a market. It does not predict prices, and nothing in it is investment advice.

MIT licence. See CHANGELOG.md for what has changed and when.

Available Tools

13 tools
ask_heyAsk HEYA
Read-only
Inspect

Asking something else about one project? Put it in free text, by slug, in English or Malay ("did they ship this month?"). HEY answers only from its record, every line tagged FACT, DERIVED or UNKNOWN with its source. Building only; no view on price.

NameRequiredDescriptionDefault
slugYesA project slug, e.g. "agentos".
questionYesThe question, in the reader's words.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnly and openWorld, so the description adds real substance: answers are grounded strictly in 'its record' (no outside knowledge), each line is tagged FACT/DERIVED/UNKNOWN with a source, and both English and Malay are accepted. It does not mention latency, rate limits, or how to handle an ambiguous slug, but the grounding/tagging contract is unusually informative.

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?

Three tight sentences, front-loaded with the core action and ending on the scope limit. The telegraphic fragment 'Building only; no view on price' is efficient but slightly clipped in a way that could be misread.

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

Completeness4/5

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

With an output schema present, the description needn't explain return shapes, and it still conveys the grounding policy, language options, and domain limits. The only gap is guidance on when this is preferable to research_answer or explain_fact.

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 goes beyond the schema by stating the question may be free text in English or Malay and giving a sample phrasing ('did they ship this month?'), which clarifies expected natural-language input. The slug parameter gains only the 'one project' framing, not much more.

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 makes clear this is a free-text Q&A tool scoped to a single project identified by slug, with an example question. It never distinguishes itself from the sibling research_answer, though the opening phrase 'Asking something else' hints at follow-up usage.

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?

'Asking something else about one project?' implies a follow-up/continuation context, and 'Building only; no view on price' is a genuine scope exclusion. However, no explicit routing versus research_answer, explain_fact, or get_evidence is given, so the agent must infer when this tool beats its siblings.

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

chain_overviewRobinhood Chain overviewA
Read-only
Inspect

How active is Robinhood Chain? view: days (default; trades, volume, tokens, transactions, launches, ships per day), this-week, weekly-report (an ISO week, or the latest), unlocks (scheduled HoodLock unlocks with proof), build-market (Build Momentum beside market attention). days names no one; other views name projects.

NameRequiredDescriptionDefault
daysNodays: 1–400 (default 14); unlocks: 1–365 ahead (default 30).
viewNo
weekNoweekly-report: e.g. 2026-W37.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, and an output schema exists, so the safety profile and return shape are covered. The description adds view-specific behavior: 'days' is the default view, 'weekly-report' can resolve to the latest ISO week, and 'unlocks' includes scheduled HoodLock unlocks with proof. It omits freshness/pagination, but with annotations and an output schema the bar is lower and what it adds is real.

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?

Dense but front-loaded: the scoping question comes first, followed by the per-view semantics. Almost every clause carries information (metrics list, default, latest-week option, proof detail). The terse final clause 'days names no one; other views name projects' is slightly cryptic and costs a small amount of clarity for its brevity.

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 an output schema handling return shape and annotations covering read-only/open-world behavior, the description supplies what remains: the meaning of all five view values, the default view, and the variant semantics of days/week parameters per view. An agent can select a view and call it without opening the schema, which is sufficient for a 3-parameter read 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?

Schema coverage is 67%; the schema already documents the days range/defaults and the week pattern. The description adds semantic meaning beyond that: what each view returns (per-day metric breakdown for 'days', 'an ISO week, or the latest' for weekly-report, proof-bearing unlocks, and the build-market juxtaposition), which genuinely helps an agent choose a view. It does not add format hints beyond what the schema gives.

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 states the resource (Robinhood Chain activity metrics) and enumerates the exact metrics returned per day (trades, volume, tokens, transactions, launches, ships) plus the alternate view modes. The question framing 'How active is Robinhood Chain?' is less crisp than a verb-phrase, but the view list removes ambiguity. It is clearly distinguishable from siblings like get_project_snapshot or get_token_market, which are project/token-scoped.

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?

The five view names with brief parentheticals imply which mode to choose for which data need, and 'days names no one; other views name projects' hints at chain-wide vs project-named output. However, it never states when to pick this tool over siblings such as get_project_snapshot or get_token_market, nor prerequisites. Guidance is implied rather than explicit.

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

explain_factExplain a factA
Read-only
Inspect

Why does HEY say a project is Shipping, Dormant or Still Building, or show a figure? The value, FACT, DERIVED or UNKNOWN, the rule and version, the winning source, the inputs, the lineage and the evidence ids. Omit fact to list what can be explained; source.counted takes a source id.

NameRequiredDescriptionDefault
factNo
slugYesA project slug, e.g. "agentos".
sourceNoWith fact=source.counted: the source id.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered. The description adds that omitting fact produces a list of explainable facts and that source.counted has a source-id requirement, but it does not add much beyond that about rate limits, permissions, or other runtime behavior.

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 description is short and front-loads the core purpose before listing what an explanation contains. It is efficient, though the opening rhetorical question is slightly indirect and the return-value list partly duplicates the output schema.

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

Completeness4/5

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

Given the output schema and annotations, the description provides enough to call the tool correctly: required slug, optional fact for listing, and source usage with source.counted. It does not fully explain every enum value, but that is largely carried by the schema.

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

Parameters3/5

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

Schema coverage is 67%, with slug and source already described in the schema. The description clarifies the optional list behavior when fact is omitted and reinforces the source.counted/source relationship, but it does not explain the meaning of the individual fact enum values beyond the schema's enumeration.

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 makes clear that the tool explains why a derived project fact or figure has a particular value, and it lists the returned explanation components such as rule, version, source, lineage, and evidence ids. The rhetorical question format is less direct than a verb-first statement, and it does not explicitly distinguish this from siblings like ask_hey or get_evidence.

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?

It gives useful usage detail by saying 'Omit fact to list what can be explained' and that source.counted takes a source id. However, it does not say when to use this tool versus ask_hey, get_evidence, or other explanation/research siblings, so the guidance is implied rather than explicit.

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

find_projectsFind a Robinhood Chain projectA
Read-only
Inspect

Which Robinhood Chain project is this name, $TICKER or 0x contract, and is anyone building it? A full 0x address is a contract lookup: its ships in 30 days, the last one with its source. Or browse who is shipping now, back from dormancy, accelerating or building ahead of market attention. Surfaces: building-with-token: verified shipping, active or resumed, with a token whose market is live. still-building: verified activity continuing through a market drawdown HEY tracked. under-the-radar: eligible under HEY's Under the Radar rule (status shipping, active or resumed; Build Momentum at least 30; at least 2 meaningful events in the last 30 days, one of them a ship rather than a commit summary; a fresh reading of an active market beyond a launch curve or a launch pool, for the project's own token) and a positive Discovery Gap — market-attention percentile below the build percentile; a positive gap alone is not enough, and it does not bound attention itself. shipping-now: status SHIPPING. most-active: shipping, active or resumed, by Build Momentum. new-builders: recorded in the last 7 days. back-from-dormancy: status RESUMED, narrowed to verified builders native to the chain (status=RESUMED gives every resumed project). utility, memes: by kind. shipping-in-silence: eligible under the Under the Radar rule AND below the 40th market-attention percentile. accelerating: more meaningful events in 30 days than in the 30 before. builder-radar: the Builder Radar, ranked by verified development, on-chain use and research, never price. shipping-in-silence and accelerating take no other argument (at most 100 rows); builder-radar takes query, radar, limit and offset. Not a ranking by price: a market sort is context, and rows without the figure follow in activity order.

NameRequiredDescriptionDefault
ageNoSince the first pool opened.
hasNoFacts every row must carry.
kindNo
sortNoDefault activity; shipped = newest ship first; shipped7d / shipped30d = most meaningful ships in the last 7 / 30 days.
limitNoDefault 24.
queryNoName, $TICKER or 0x contract (or its start).
radarNoWith surface=builder-radar: a Radar view.
stageNoToken launch stage.
offsetNoThe offset a previous answer gave.
statusNoActivity status.
surfaceNo
deployedNoSince the contract was deployed.
launchpadNoe.g. "pons", "virtuals".
minVolumeNo24h volume, USD.
narrativeNoNarrative slug, e.g. "ai-agents".
maxMarketCapNoUSD, on the card's valuation reading.
minLiquidityNoUSD; unknown is excluded, never zero.
minMarketCapNo

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only and open-world behavior. The description adds useful beyond-annotation context: row caps for certain surfaces, which arguments those surfaces accept, the Under the Radar eligibility rule, and the explicit note that results are not ranked by price and that rows without a market figure follow in activity order. That is meaningful 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.

Conciseness2/5

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

The purpose is front-loaded, but the rest is a dense, run-on paragraph that packs twelve surface definitions and eligibility rules into an undifferentiated block. Phrases like "HEY tracked" and "its ships in 30 days, the last one with its source" are confusing, and the scanability is poor despite the detail being largely relevant.

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

Completeness4/5

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

This is an 18-parameter discovery tool with an output schema and annotations, and the description covers its main search/browse modes, surface eligibility and ranking caveats. Combined with high schema coverage, that is enough for correct invocation, though missing default surface behavior and some parameter interactions keep it from being fully complete.

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 high at 83%, so the baseline is 3. The description earns above baseline by defining all surface enum values in prose and by noting that shipping-in-silence and accelerating take no other argument while builder-radar takes query, radar, limit and offset. It does not explain every remaining parameter, but it adds substantial semantics for the most complex parameter.

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 opens with a specific lookup question covering name, $TICKER and 0x contract, then says it supports browsing build-activity surfaces. That is a clear verb-like purpose for a search/list tool. It does not explicitly distinguish itself from siblings such as get_project_snapshot, so it stops short of a 5.

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?

The description explains the available surfaces and gives some argument restrictions for shipping-in-silence, accelerating and builder-radar, which implies when each surface is useful. However, it never names alternatives like get_project_snapshot or get_contract, nor does it state when not to use find_projects. Usage is therefore present but inferential rather than explicit.

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

get_changesWhat changed on Robinhood ChainA
Read-only
Inspect

What changed on Robinhood Chain today or this week, or for one project or contract? The change ledger: releases, ships, status moves, contract deploys and upgrades, verification, sources, unlocks — one event per change with its own time and precision, when HEY first knew, and its evidence. Newest first by first arrival; for today pass detectedSince; to sync, pass after=c1.0 and keep each cursor. A retraction means HEY no longer makes that claim. Facts, never causes.

NameRequiredDescriptionDefault
typeNo
afterNoSync forward from this cursor (c1.0 is the start).
limitNoDefault 30.
sinceNoISO date: events whose own time is at or after it (events with no source time are left out).
untilNo
beforeNoBrowse older than this cursor.
domainNo
projectNoA project slug.
contractNo<chainId>:<address>.
detectedSinceNoISO instant: start a sync at the first event HEY recorded at or after it.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnly and openWorld; the description adds real behavioral context beyond them: result ordering (newest first by first arrival), the cursor-persistence contract for sync, and the retraction semantics ('a retraction means HEY no longer makes that claim'). It does not cover rate limits, page-size defaults beyond what the schema states, or the cost of a broad unfiltered call, which keeps it below 5.

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 the purpose question, then filters, then ordering/sync mechanics — a sensible order with no filler sentences. It is dense but slightly overpacked, and the closing tagline 'Facts, never causes' is punchy but of marginal operational value.

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

Completeness4/5

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

For a 10-parameter, zero-required, open-world read tool with an output schema covering return values, the description supplies the unstated essentials: default ordering, sync protocol, and retraction handling. The main residual gap is that the 35-value type enum is neither sampled nor guided, leaving the agent to infer the taxonomy from the schema alone.

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 70%, so baseline is near 3, but the description earns credit by disambiguating the two cursor-like parameters: detectedSince for 'today' (record-time) versus after as a resumable cursor to be retained. It also hints project/contract filtering via 'or for one project or contract.' The type enum taxonomy and limit behavior are left entirely to the schema.

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?

Opens with a concrete question and names the resource precisely: 'The change ledger: releases, ships, status moves, contract deploys and upgrades, verification, sources, unlocks.' An agent knows this is a chronological event feed and can distinguish it from snapshot/timeline siblings by the explicit 'one event per change' framing. It never names a sibling it is not, so 5 is not warranted.

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?

Gives clear situational routing: 'Newest first by first arrival; for today pass detectedSince; to sync, pass after=c1.0 and keep each cursor.' That is actionable context for two distinct call patterns. However, no exclusions or alternatives are named — nothing tells the agent when to prefer get_project_timeline, get_project_snapshot, or project_diff instead.

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

get_contractWho made this contractA
Read-only
Inspect

Who made this Robinhood Chain contract, and is it a known project's? Project, creation, deployer (the only account named, with a count of other tracked projects' tokens it deployed), verified source and whose code it is (template, bytecode match or its own), Sourcify's answer, proxy and implementation history, interface changes, 7 days of calls per method (counts, names withheld; a selector's signature candidate — a guess, never a name). Address (chainId default 4663) or slug for all of a project's. An unread proxy is "not read", never "not a proxy". Not a safety verdict.

NameRequiredDescriptionDefault
slugNoA project slug, for all of its contracts.
addressNo
chainIdNoDefault 4663.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnly/openWorld, but the description adds real caveats: an unread proxy is reported as 'not read' rather than 'not a proxy', selector signature candidates are 'a guess, never a name', and 'Not a safety verdict.' These are genuine interpretation guardrails beyond structured data.

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?

The main clause is front-loaded, but the body is a dense run-on of parentheticals (counts, names withheld; template, bytecode match or its own) that is hard to parse in one pass. Every clause carries information, but the structure hurts scanability.

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

Completeness4/5

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

With an output schema present, the description need not explain return values, yet it usefully characterizes them and flags that no parameter is required (address or slug). For a 3-param open-world read tool it is largely complete, with only sibling-routing guidance 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 67% (address has only a pattern, no prose). The description compensates by clarifying the address-vs-slug duality and that a slug returns all of a project's contracts, plus the chainId default of 4663, adding meaning beyond the schema.

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 title/description clearly frames the tool as answering 'who made this contract' and enumerates the provenance payload: deployer, verified source, proxy history, call counts. A specific verb+resource is evident, though it never explicitly names a sibling to differentiate from, so it stops short of a 5.

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?

It states an address OR a slug can be supplied ('slug for all of a project's'), which implies how to invoke it, but gives no explicit when-to-use vs siblings like get_v4_hook, get_changes, or find_projects, and states no exclusions.

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

get_evidenceOpen evidenceA
Read-only
Inspect

What backs this claim? Open the record a HEY answer cited by its typed id — ship:, signal:, abi:, impl:, lock:, source:, claim:, state:, narrative:, method:, sourcechange:, security:, v4hook:, v4pool:, ponsgrad: — as a receipt: what it claims, its source URL, when it happened at what precision, when HEY knew, how it is backed. A withdrawn record says so.

NameRequiredDescriptionDefault
idYesA typed evidence id, e.g. "ship:2ac87a66-…".

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond that: what fields the returned receipt contains (claims, source URL, timing precision, when HEY knew, backing) and that withdrawn records are explicitly flagged.

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 motivating question is front-loaded and the payload description is dense but single-pass. The long inline prefix list is necessary information but makes the single sentence heavy; a small structural break would help without losing content.

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?

For a one-parameter read tool with a full output schema and readOnly/openWorld annotations, the description covers purpose, valid input types, returned fields, and the withdrawn-record edge case. An agent has everything needed to call and interpret it.

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% and the schema already shows the id pattern, so baseline is 3. The description goes further by enumerating the valid typed prefixes (ship:, signal:, abi:, claim:, etc.), which the schema's generic pattern does not convey.

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 ('Open the record') and resource (a typed evidence id cited by a HEY answer), then enumerates the exact id prefixes accepted. An agent can distinguish it from siblings like explain_fact or get_contract 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 Guidelines4/5

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

The opening question 'What backs this claim?' gives a clear trigger condition for use, and the receipt framing implies verification/provenance workflows. It does not name an alternative tool or state when not to use it, so it stops short of full routing guidance.

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

get_project_snapshotProject snapshotA
Read-only
Inspect

Where does this Robinhood Chain project stand? One read by slug — the Research Summary, identity, activity status and Build Momentum, last ships, market context with its kind or why it is withheld, on-chain use, 7-day usage (calls; caller addresses per day, not people), verification, HoodLock locks, latest changes with evidence ids, freshness and what HEY does not know. Context blocks, never building: paid promotion (presence and dates), DefiLlama protocol economics (measured, not tracked or unread), developer footprint. Not price advice.

NameRequiredDescriptionDefault
slugYesA project slug, e.g. "agentos".

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavioral context: usage figures are calls with caller addresses per day rather than people, market context may be withheld and the reason shown, some blocks are context-only and never building, and the result is explicitly not price advice. It also states what HEY does not know, giving the agent a realistic sense of data gaps.

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?

The description is front-loaded with a clear question and a single-read framing, but the second sentence is a dense, comma-heavy inventory of sections and caveats. Phrases like 'kind or why it is withheld' and 'measured, not tracked or unread' are informative but cryptic and would benefit from clearer structure.

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

Completeness4/5

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

For a complex composite snapshot tool with an output schema, the description competently enumerates the major content areas, caveats, and freshness/unknowns. It does not explain the return structure, which is acceptable because an output schema exists, but it could still clarify error behavior or slug lookup failure modes.

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

Parameters3/5

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

Schema description coverage is 100%, with the slug parameter already documented and exemplified in the schema. The description adds only the phrase 'by slug' without extra constraints, format details, or validation guidance beyond what the schema provides.

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 clearly states that this tool provides a single project snapshot by slug, covering Research Summary, identity, activity, Build Momentum, usage, verification, locks, changes, freshness, and unknowns. It distinguishes itself from a simple project lookup by describing a comprehensive multi-section read, though it does not explicitly contrast itself with siblings like get_project_timeline or project_diff.

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?

The phrase 'One read by slug' implies usage when an agent has a project slug and wants a consolidated status view. However, the description does not state when to prefer this tool over sibling tools such as find_projects, get_changes, get_project_timeline, or project_diff, nor does it give any exclusions.

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

get_project_timelineWhat a project shippedA
Read-only
Inspect

What did this project ship, and when? Builds, releases, code, contract deploys, upgrades and interface changes, token verification, locks and unlocks, each with how precisely HEY knows its time. Lenses: everything, build, code, onchain, market, locks. Paged with the before cursor.

NameRequiredDescriptionDefault
lensNo
slugYesA project slug, e.g. "agentos".
limitNoDefault 30.
beforeNoThe cursor the previous answer gave.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare the safe read-only, open-world profile, and the description adds real context beyond them: each event carries a stated time-precision/confidence signal, and results are paginated via the 'before' cursor. It stops short of noting rate limits or auth requirements, but for a read query it covers the traits an agent needs.

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 the core question, then event scope, lenses, and pagination in two dense lines with no filler. 'Each with how precisely HEY knows its time' is slightly cryptic but carries genuine meaning.

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

Completeness4/5

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

With an output schema present, return values needn't be spelled out, and the description still covers event taxonomy, lens scoping, and pagination. Slug formatting and limit defaults are left to the schema, which handles them, so nothing critical is missing.

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

Parameters3/5

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

Schema coverage is 75%, so the baseline is 3. The description reinforces the lens vocabulary and clarifies that 'before' is a pagination cursor returned by the previous answer, but it adds nothing on slug format or limit behavior beyond the schema, and the lens enum itself has no schema description to build on.

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 definition leads with a specific question ('What did this project ship, and when?') and enumerates the concrete event types returned (builds, releases, contract deploys, token verification, locks/unlocks), so the resource is unambiguous. It does not name or contrast with the nearest siblings (get_changes, project_diff, get_project_snapshot), which is the only thing keeping it from a 5.

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

Usage Guidelines2/5

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

It explains the available lenses, which steers filtering choices, but gives no when-to-use guidance and no exclusions relative to alternatives like get_changes or project_diff. An agent must infer from the sibling list when a timeline is the right view.

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

get_token_marketToken marketA
Read-only
Inspect

Does this token still trade? Context beside the building, from HEY's daily index: current reading (valuation kind, provider), price, liquidity, volume and trades by day, lifecycle (deploy, launchpad claim, stage, first trade, launch graduation, permanent lock), pools and depth, supply concentration (shares only, no addresses), contract checks. include=["moves"] adds each day-on-day valuation move with the building events published before it — a sequence, never a cause. Not price advice.

NameRequiredDescriptionDefault
daysNoDays of history; default 30.
slugYesA project slug, e.g. "agentos".
includeNo
min_change_pctNoWith moves: smallest move in percent; default 25.

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A3.8/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, the description discloses meaningful traits: concentration data is shares-only with no addresses, moves are 'a sequence, never a cause' (an explicit anti-causality caveat), and there is a 'not price advice' disclaimer. These guard against real misinterpretations. Missing freshness/lag, error behavior for unknown slugs, and response size expectations keep it from a 5.

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?

Purpose is front-loaded in the opening question and the body is information-dense with no filler sentences — every clause names a returned data family. It reads as a run-on enumeration with heavy parentheticals, which costs a little scannability but wastes no words.

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

Completeness4/5

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

An output schema exists, so the extensive return-value enumeration is somewhat redundant but harmless, and safety is covered by annotations. Combined with the moves semantics and the privacy/causality caveats, an agent has enough to call it correctly; only sibling routing, freshness, and unknown-slug error behavior are absent.

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?

With 75% schema coverage the baseline is 3, but the description meaningfully explains `include=["moves"]` — the one parameter with no schema description — including what it adds and how it pairs with published building events. `days` and `min_change_pct` are left to the schema, and min_change_pct's relationship to the moves option is only loosely implied.

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 opening question 'Does this token still trade?' plus the enumeration of returned data (price, liquidity, volume/trades by day, lifecycle, pools, concentration, contract checks) makes clear this retrieves market/trading context for a token slug. The verb is implicit ('get') and no sibling is named for contrast, but an agent can distinguish it from get_contract or get_project_snapshot from the content list.

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 only implied by the rhetorical framing — reach for this when you need to know whether/how a token trades. There is no explicit when-to-use, when-not, or named alternative among the many siblings (get_project_snapshot, get_contract, get_changes). The include=["moves"] note gestures at a mode switch but is framed as parameter behavior, not selection guidance.

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

get_v4_hookUniswap v4 hookC
Read-only
Inspect

Who built this Robinhood Chain Uniswap v4 hook? The project HEY ties it to and why (named only while listed; never a creator account), declared callbacks (not a safety verdict), source, hooklist entry, pools by week and unknowns.

NameRequiredDescriptionDefault
addressYes

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description does add genuine caveats beyond the annotations: 'named only while listed; never a creator account' and 'declared callbacks (not a safety verdict)'. These are useful scope limiters, though the phrasing is cramped and omits other operational behavior.

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

Conciseness2/5

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

The description is a single run-on fragment with nested parentheticals and no front-loaded statement of what the tool does. Several clauses are backward or ambiguous, so the content does not read cleanly despite being short.

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

Completeness3/5

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

An output schema exists, so return values need not be spelled out, yet the description spends its text enumerating returns while omitting input semantics and usage context. It is adequate for a simple single-parameter lookup but leaves the agent guessing about scope and alternatives.

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

Parameters3/5

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

Schema description coverage is 0% and the description never mentions the required address parameter or what it should point at. The single parameter is largely self-evident from the tool name and the address regex pattern, which keeps this at a minimum-viable 3 rather than lower.

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

Purpose3/5

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

The name and title identify the resource (a Uniswap v4 hook) and the description enumerates the content returned (creator/project tie, declared callbacks, source, hooklist entry, pools by week, unknowns). However, it is phrased as a question with no clear verb, and the extraneous 'Robinhood Chain' framing muddies the scope rather than clarifying it. The purpose is inferable but not stated cleanly.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, when not to, or how it relates to siblings like get_contract or get_project_timeline. The reader must guess that this is the hook-specific lookup versus the generic contract lookup.

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

project_diffProject diffA
Read-only
Inspect

What changed for this project between two dates (YYYY-MM-DD, at most 400 days apart)? Releases and meaningful ships, status, Build Momentum, valuation and liquidity then and now, and the changes recorded — each from the nearest persisted point with its date and basis. Never a cause.

NameRequiredDescriptionDefault
toYes
fromYes
slugYesA project slug, e.g. "agentos".

Output Schema

NameRequiredDescription
apiYes
dataNo
schemaYes

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses that each datum comes from "the nearest persisted point with its date and basis" — critical freshness and approximation semantics — and closes with "Never a cause," an explicit epistemic limitation on what the diff implies. These are exactly the behavioral traits an agent cannot get from structured fields.

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?

A single front-loaded sentence that answers "what does this return" before adding qualifiers, with no filler. It is dense — the enumeration of content categories plus the persistence caveat makes it long for one sentence, but each clause carries information.

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 an output schema present, the description needn't explain return structure, and it covers the remaining gaps an agent needs: input date format and span limit, what the payload contains, how the data is dated/approximated, and the interpretive boundary. Nothing required to call it correctly 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 only 33% (only slug is described in-schema), but the description compensates for both date parameters: it specifies the YYYY-MM-DD format and the 400-day maximum span, semantics the schema does not encode. Slug semantics remain schema-only, which is acceptable since the schema documents it.

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 with explicit scope: "what changed for this project between two dates", and enumerates the content categories (releases, status, Build Momentum, valuation/liquidity then and now). The "then and now" framing implicitly but clearly separates it from point-in-time siblings like get_project_snapshot and the sequence-based get_project_timeline.

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?

Gives one hard usage constraint (dates must be YYYY-MM-DD and at most 400 days apart), which is real guidance for constructing a valid call. However, it never says when to prefer this over get_project_snapshot or get_project_timeline, nor when-not to use it — the agent must infer the choice from the tool name.

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

research_answerResearch a Robinhood Chain projectA
Read-only
Inspect

Is this Robinhood Chain project still being built, what did it ship, what changed, is this contract its own? One bounded answer, cited. capability: research_project or builder_status (q: a name or $TICKER, or address, or project: a slug; a name several projects share lists them); what_changed (project or chain, 1–30 days); verify_project (address, project?); compare_builders (2–4, no winner); unknowns (every coverage state). Claims FACT/DERIVED/UNKNOWN with freshness and evidence ids. Not price advice or a safety verdict.

NameRequiredDescriptionDefault
qNo
daysNo
limitNo
typesNo
detailNo
addressNo
projectNo
buildingNo
projectsNo
capabilityYes

Output Schema

NameRequiredDescription
dataYes
answerYes
claimsYes
schemaYes
statusYes
evidenceYes
capabilityYes
schemaVersionYes

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds some useful behavior ("one bounded answer," per-mode limits like "no winner" and "1–30 days"), but "bounded" is never quantified, and the FACT/DERIVED/UNKNOWN labeling largely restates what the output schema already conveys. Moderate added value with annotations doing much of the work.

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 the user-facing questions, then a dense capability-to-parameter map with no filler sentences. The telegraphic semicolon style is compact but at the edge of readability, keeping it just under a 5.

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

Completeness3/5

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

For a 10-parameter, six-capability tool the description covers capability routing adequately and an output schema exists for return values. But four parameters are undocumented and the "one bounded answer" constraint is unquantified, so an agent lacks enough to invoke some modes confidently.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry the full burden, and it does explain q (name/$TICKER/address/slug), days, projects, address, and project, plus ties capability to params. It leaves limit, types, detail, and the odd building:"only" const entirely unexplained, so it only partially compensates for the coverage gap.

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 states a specific domain (Robinhood Chain projects), frames the questions it answers, and enumerates its six capability modes, so the agent knows it is a synthesized, cited answer tool. It does not explicitly distinguish itself from overlapping siblings like find_projects, get_changes, or get_evidence, so it stops short of a 5.

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 gives per-capability routing guidance (q for research_project/builder_status, days with a 1–30 bound for what_changed, 2–4 for compare_builders) and an explicit exclusion ("Not price advice or a safety verdict"). However, it never says when to prefer this tool over siblings that appear to cover the same ground, such as get_changes or find_projects.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 13 tool updatesv0.1.0
    • First observedask_hey
    • First observedchain_overview
    • First observedexplain_fact
    • First observedfind_projects
    • First observedget_changes
    • First observedget_contract
    • First observedget_evidence
    • First observedget_project_snapshot
    • First observedget_project_timeline
    • First observedget_token_market
    • First observedget_v4_hook
    • First observedproject_diff
    • First observedresearch_answer

TDQS

A3.5/5.0

Scored across 13 tools

Disambiguation3/5

Most tools target distinct resources or views, but ask_hey, research_answer, find_projects, and get_project_snapshot overlap in answering project questions. get_changes, get_project_timeline, and project_diff also have related temporal-change boundaries that require careful reading to separate.

Naming Consistency3/5

Many tools follow snake_case verb_noun conventions (find_projects, get_contract, explain_fact), but ask_hey, chain_overview, and research_answer are noun-phrase or conversational rather than action-oriented. The mix is readable but not predictable enough for a 4.

Tool Count5/5

Thirteen tools is well within the appropriate range for a research server covering projects, chain activity, evidence, markets, and contracts. Each tool appears to earn its place without excessive surface area.

Completeness5/5

The set covers discovery, project snapshots, timelines, changes, diffs, explanations, evidence lookup, token markets, contracts, v4 hooks, and chain-level overviews. This is a comprehensive research lifecycle with few obvious dead ends.

Maintenance

ActivityActive
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to read identification verdicts, search history, summarize entities, explain risk scores, and verify webhook signatures through read-only tools over stdio or streamable HTTP.
    6
    7 npm
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Exposes real-time Hyperliquid explorer and analytics data from flowscan.xyz as 44 read-only tools, letting AI agents answer questions about protocol revenue, perp market positioning, individual open positions, wallet activity, and staking without an API key. It runs over stdio against Hyperliquid mainnet only, using the same API routes the Flowscan frontend calls.
    44
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Exposes four stdio tools that let an agent research an application's documented interface, produce a validated single-use plan, and execute read-only operations against public HTTP JSON APIs, static HTML/JSON/text sources, and host-configured CLIs. Runs in-process with no listening port, accounts, or model dependency, returning bounded results while keeping inputs and outputs inside a host-enforced research-plan-execute lifecycle.
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Exposes five read-only tools that let clients query a public knowledge base of cognitive models — browsing taxonomy and categories, searching models, retrieving a model's details, exploring its lineage and relationships, and inspecting cited sources with verification status. It runs as a standalone Node.js service over local stdio or self-hosted Streamable HTTP, so assistants can ground answers in real, cited model data.
    1
    Creative Commons Zero v1.0 Universal