HEY Research Lab

What changed on Robinhood Chain

get_changes

Read-only

What changed on Robinhood Chain today or this week, or for one project or contract? The change ledger without market readings: 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.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	No
`after`	No	Sync forward from this cursor (c1.0 is the start).
`limit`	No	Default 30.
`since`	No	ISO date: events whose own time is at or after it (events with no source time are left out).
`until`	No
`before`	No	Browse older than this cursor.
`domain`	No
`project`	No	A project slug.
`contract`	No	<chainId>:<address>.
`detectedSince`	No	ISO instant: start a sync at the first event HEY recorded at or after it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`api`	Yes
`data`	No
`schema`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / type / items / enum

Previous value: -[
-  "build.release",
-  "build.code_activity",
-  "build.ship",
-  "build.status_changed",
-  "build.dormant",
-  "build.resumed",
-  "build.accelerating",
-  "build.slowing",
-  "contract.deployed",
-  "contract.followup_deployed",
-  "contract.implementation_changed",
-  "contract.source_verified",
-  "contract.source_unverified",
-  "contract.interface_changed",
-  "contract.usage_changed",
-  "contract.method_first_observed",
-  "contract.method_resumed",
-  "token.launch_stage_changed",
-  "token.verification_changed",
-  "research.published",
-  "research.builder_verified",
-  "research.owner_verified",
-  "research.source_added",
-  "research.source_unavailable",
-  "research.source_restored",
-  "research.source_changed",
-  "research.narrative_assigned",
-  "lock.unlock_due",
-  "lock.observed",
-  "lock.withdrawn"
-]New value: +[
+  "build.release",
+  "build.code_activity",
+  "build.ship",
+  "build.status_changed",
+  "build.dormant",
+  "build.resumed",
+  "build.accelerating",
+  "build.slowing",
+  "contract.deployed",
+  "contract.followup_deployed",
+  "contract.implementation_changed",
+  "contract.source_verified",
+  "contract.source_unverified",
+  "contract.interface_changed",
+  "contract.usage_changed",
+  "contract.method_first_observed",
+  "contract.method_resumed",
+  "contract.v4_pool_initialized",
+  "token.launch_stage_changed",
+  "token.verification_changed",
+  "research.published",
+  "research.builder_verified",
+  "research.owner_verified",
+  "research.source_added",
+  "research.source_unavailable",
+  "research.source_restored",
+  "research.source_changed",
+  "research.narrative_assigned",
+  "lock.unlock_due",
+  "lock.observed",
+  "lock.withdrawn"
+]

Changed2 schema fields changedOct 5, 2026

changedInput schema / properties / domain / items / enum

Previous value: -[
-  "build",
-  "contract",
-  "market",
-  "token",
-  "research",
-  "lock",
-  "market_integrity"
-]New value: +[
+  "build",
+  "contract",
+  "token",
+  "research",
+  "lock"
+]

changedInput schema / properties / type / items / enum

Previous value: -[
-  "build.release",
-  "build.code_activity",
-  "build.ship",
-  "build.status_changed",
-  "build.dormant",
-  "build.resumed",
-  "build.accelerating",
-  "build.slowing",
-  "contract.deployed",
-  "contract.followup_deployed",
-  "contract.implementation_changed",
-  "contract.source_verified",
-  "contract.source_unverified",
-  "contract.interface_changed",
-  "contract.usage_changed",
-  "contract.method_first_observed",
-  "contract.method_resumed",
-  "market.status_changed",
-  "market.liquidity_moved",
-  "market.volume_spike",
-  "market.distribution_changed",
-  "token.launch_stage_changed",
-  "token.verification_changed",
-  "research.published",
-  "research.builder_verified",
-  "research.owner_verified",
-  "research.source_added",
-  "research.source_unavailable",
-  "research.source_restored",
-  "research.source_changed",
-  "research.narrative_assigned",
-  "lock.unlock_due",
-  "lock.observed",
-  "lock.withdrawn",
-  "market_integrity.event"
-]New value: +[
+  "build.release",
+  "build.code_activity",
+  "build.ship",
+  "build.status_changed",
+  "build.dormant",
+  "build.resumed",
+  "build.accelerating",
+  "build.slowing",
+  "contract.deployed",
+  "contract.followup_deployed",
+  "contract.implementation_changed",
+  "contract.source_verified",
+  "contract.source_unverified",
+  "contract.interface_changed",
+  "contract.usage_changed",
+  "contract.method_first_observed",
+  "contract.method_resumed",
+  "token.launch_stage_changed",
+  "token.verification_changed",
+  "research.published",
+  "research.builder_verified",
+  "research.owner_verified",
+  "research.source_added",
+  "research.source_unavailable",
+  "research.source_restored",
+  "research.source_changed",
+  "research.narrative_assigned",
+  "lock.unlock_due",
+  "lock.observed",
+  "lock.withdrawn"
+]

Changed2 schema fields changedSep 30, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "api": {
+      "type": "string"
+    },
+    "data": {},
+    "schema": {
+      "const": "hey.mcp-api-answer",
+      "type": "string"
+    }
+  },
+  "required": [
+    "schema",
+    "api"
+  ],
+  "type": "object"
+}

First observedSep 28, 2026

TDQS

A4/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 operational context beyond that — newest-first by first arrival, one event per change with its own time and precision plus when HEY first knew and its evidence, and the retraction semantics ('HEY no longer makes that claim'). It does not discuss rate limits or result-volume behavior, so it falls short of 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?

It is dense but front-loaded: the rhetorical question establishes scope first, then the event inventory, then the pagination/sync mechanics. A few phrasing choices ('when HEY first knew') cost tokens, but every sentence carries routing or behavioral information.

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?

Output schema exists, so return values need no explanation, and the description covers ordering, evidence, retractions, and cursor semantics for a 10-parameter tool. Minor gaps remain: `until` is undocumented in both schema and description, and there is no note on default page size behavior beyond the schema's 'Default 30.'

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 the schema documents many parameters already (after, before, since, limit, project, contract, detectedSince). The description still adds value by explaining the sync workflow — after=c1.0 as the start cursor, keep each cursor, detectedSince for today — which the bare schema descriptions do not spell out as a procedure.

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?

It names a concrete resource (the change ledger) and enumerates the event families it covers — releases, ships, status moves, contract deploys/upgrades, verification, sources, unlocks — so the agent knows exactly what comes back. The contrast clause 'without market readings' and 'Facts, never causes' carve out scope against neighboring tools, though no sibling is named by name the way a 5 would require.

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 real selection guidance: use it for today / this week / one project / one contract, pass detectedSince for today, and for incremental sync pass after=c1.0 keeping each cursor. It stops short of naming an alternative (e.g. when to prefer get_project_timeline or explain_fact), so it is clear context rather than full when-not routing.

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

All HEY Research Lab tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.