HEY Research Lab

Research a Robinhood Chain project

research_answer

Read-only

Is this Robinhood Chain project still being built, what did it ship, what changed, is this contract its own? One cited answer. capability: research_project or builder_status (q: a name or $TICKER, or address, or project: a slug; a shared name lists candidates); 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 evidence ids; not_found is a status, not isError. Not price advice or a safety verdict.

Input Schema

Name	Required	Description
`q`	No	A name or $TICKER; a shared name lists candidates, never a guess.
`days`	No	what_changed: default 7.
`limit`	No	what_changed: events shown, default 25; the total is the whole window.
`types`	No	what_changed: change types to keep, e.g. build.release.
`detail`	No	Default summary text; full text; compact drops the capability data from the JSON.
`address`	No	A 0x contract address on Robinhood Chain.
`project`	No	A project slug.
`building`	No	what_changed: only events that count as building.
`projects`	No	compare_builders: 2 to 4 slugs.
`capability`	Yes	Which answer; each takes the arguments the tool description names.

Output Schema

Name	Required	Description	Default
`data`	No
`answer`	Yes
`claims`	Yes
`schema`	Yes
`status`	Yes
`evidence`	Yes
`capability`	Yes
`schemaVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "not_found",
-  "moved",
-  "invalid_request",
-  "unavailable"
-]New value: +[
+  "ok",
+  "ambiguous",
+  "not_found",
+  "moved",
+  "invalid_request",
+  "unavailable"
+]

Changed10 schema fields changedNov 5, 2026

addedInput schema / properties / address / description

Added value: +"A 0x contract address on Robinhood Chain."

addedInput schema / properties / building / description

Added value: +"what_changed: only events that count as building."

addedInput schema / properties / capability / description

Added value: +"Which answer; each takes the arguments the tool description names."

addedInput schema / properties / days / description
```
Added value: +"what_changed: default 7."
```

addedInput schema / properties / detail / description

Added value: +"Default summary text; full text; compact drops the capability data from the JSON."

addedInput schema / properties / limit / description

Added value: +"what_changed: events shown, default 25; the total is the whole window."

addedInput schema / properties / project / description
```
Added value: +"A project slug."
```
addedInput schema / properties / projects / description
```
Added value: +"compare_builders: 2 to 4 slugs."
```

addedInput schema / properties / q / description

Added value: +"A name or $TICKER; a shared name lists candidates, never a guess."

addedInput schema / properties / types / description

Added value: +"what_changed: change types to keep, e.g. build.release."

Changed4 schema fields changedOct 17, 2026

changedInput schema / properties / capability / enum

Previous value: -[
-  "research_project",
-  "what_changed",
-  "builder_status",
-  "verify_project",
-  "compare_builders",
-  "unknowns"
-]New value: +[
+  "research_project",
+  "what_changed",
+  "builder_status",
+  "verify_project",
+  "compare_builders",
+  "unknowns",
+  "chain_brief"
+]

changedInput schema / properties / detail / enum

Previous value: -[
-  "summary",
-  "full"
-]New value: +[
+  "summary",
+  "full",
+  "compact"
+]

changedOutput schema / properties / capability / enum

Previous value: -[
-  "research_project",
-  "what_changed",
-  "builder_status",
-  "verify_project",
-  "compare_builders",
-  "unknowns"
-]New value: +[
+  "research_project",
+  "what_changed",
+  "builder_status",
+  "verify_project",
+  "compare_builders",
+  "unknowns",
+  "chain_brief"
+]

changedOutput schema / required

Previous value: -[
-  "schema",
-  "schemaVersion",
-  "capability",
-  "status",
-  "answer",
-  "claims",
-  "evidence",
-  "data"
-]New value: +[
+  "schema",
+  "schemaVersion",
+  "capability",
+  "status",
+  "answer",
+  "claims",
+  "evidence"
+]

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / detail

Added value: +{
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / q

Added value: +{
+  "maxLength": 64,
+  "minLength": 2,
+  "type": "string"
+}

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": {
+    "answer": {
+      "additionalProperties": true,
+      "properties": {
+        "text": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "text"
+      ],
+      "type": "object"
+    },
+    "capability": {
+      "enum": [
+        "research_project",
+        "what_changed",
+        "builder_status",
+        "verify_project",
+        "compare_builders",
+        "unknowns"
+      ],
+      "type": "string"
+    },
+    "claims": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "FACT",
+              "DERIVED",
+              "UNKNOWN"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "status"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "data": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "evidence": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "id": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "schema": {
+      "const": "hey.agent-intelligence-response",
+      "type": "string"
+    },
+    "schemaVersion": {
+      "const": "1",
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "ok",
+        "not_found",
+        "moved",
+        "invalid_request",
+        "unavailable"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "schema",
+    "schemaVersion",
+    "capability",
+    "status",
+    "answer",
+    "claims",
+    "evidence",
+    "data"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 30, 2026
- addedInput schema / properties / building
```
Added value: +{
+  "const": "only",
+  "type": "string"
+}
```
AddedSep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: claims are labeled FACT/DERIVED/UNKNOWN with evidence ids, and 'not_found is a status, not isError', which tells the agent how to interpret an empty result rather than treating it as a failure. It also notes that a shared name lists candidates 'never a guess', and that `detail` controls whether capability data is dropped from the JSON.

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 questions it answers, then capability/argument pairs, then behavior and exclusions — a sensible order with no filler sentences. The telegraphic style ('q: a name or $TICKER, or address, or project: a slug') is dense to the point of being slightly cryptic on first read, but every clause carries 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?

For a 10-parameter, 7-capability tool with an output schema, the description covers the capability routing, the claim taxonomy, error semantics, and scope exclusions, which is most of what an agent needs. The remaining gap is cross-tool routing against its many overlapping siblings, which is not addressed at all.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: which capability consumes which argument, the 1–30 day window for what_changed, and the 2–4 / 'no winner' constraint on compare_builders. The capability-to-argument coupling is the key missing piece in the flat schema and the description supplies it.

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 concrete research questions ('is this project still being built, what did it ship, what changed, is this contract its own') and promises 'One cited answer', which pins down both the verb and the deliverable. It also enumerates the capability modes (research_project, what_changed, verify_project, compare_builders, unknowns) so the tool's scope is legible. What it lacks is explicit differentiation from siblings like find_projects, get_changes, and get_evidence, which cover overlapping ground.

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 maps each capability to its required arguments ('what_changed (project or chain, 1–30 days)', 'compare_builders (2–4, no winner)'), which is useful internal routing, and states exclusions ('Not price advice or a safety verdict'). However, it never says when to use this tool instead of the seven siblings, and the overlaps are severe — `what_changed` vs `get_changes`, `research_project` vs `find_projects`, cited claims vs `get_evidence`. Usage is implied rather than prescribed.

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.