aeX402 — Cross-Chain DeFi MCP: LINQ, AMM, Bridge, AI

discovery_health

Report the freshness and health of the cross-chain program/token discovery pipeline: when the hourly cron last ran, how many programs/tokens each chain scan produced, and which scans failed. Use this to check whether discover_programs / search_tokens data is current before relying on it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	plain-language reading of status
`counts`	No	per-chain program counts from the last scan
`status`	Yes	healthy \| stale \| degraded
`history`	No	per-chain counts over the last <=24 cron runs, oldest first
`emptyScans`	No	chains whose last scan returned zero (omitted when none)
`failedScans`	No	chains whose last scan errored (omitted when none)
`lastRunUnix`	No
`sourceErrors`	No	per-chain list of what each live source ACTUALLY answered when it failed, e.g. "robinhood/ERC-20: blockscout /api/v2/tokens → 403". Says WHY a census is thin where seedsOnlyScans only says THAT it is. Capped at 4 entries per chain; when more were recorded the list carries a final "… +N more (T total)" string, so the count survives the truncation rather than the list silently reading as complete. Omitted when every source succeeded
`lastRunAgeMin`	No
`seedsOnlyScans`	No	chains whose last scan returned ONLY hardcoded canonical seeds — every live source returned nothing while the fallback held, so the count is non-zero and emptyScans does NOT list them. Sets status=degraded. Omitted when none
`censusLiveRecords`	No	per-census count of records the LIVE source returned, before any merge, cap or spam filter — the evidence behind seedsOnlyScans. 0 means the live source supplied nothing (the census is its fallback); -1 means this census was last written by a build that did not record the field, which is NOT the same as zero. Published even when healthy, so a reader can distinguish "source is fine" from "nothing was measured" without inferring it from a verdict. Never omitted: built over the census keys in counts, so every census always carries a value and -1 covers the pre-field case — the earlier exemption for records predating the field was retired when the conditional spread was removed
`censusRecordsBeforeCap`	No	per-census record count BEFORE the fungible (170) and NFT (50) caps. A count sitting exactly on its cap cannot say whether it is a finding or a ceiling — hyperevm_census reads 170 because 170 IS the cap. Compare against counts: a value here greater than the published count means that census was TRUNCATED, equal means it was not. -1 means the build that last wrote this census did not record the field. Never omitted, same construction as censusLiveRecords

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 16, 2026

changedOutput schema / properties / censusLiveRecords / description

Previous value: -"per-census count of records the LIVE source returned, before any merge, cap or spam filter — the evidence behind seedsOnlyScans. 0 means the live source supplied nothing (the census is its fallback); -1 means this census was last written by a build that did not record the field, which is NOT the same as zero. Published even when healthy, so a reader can distinguish \"source is fine\" from \"nothing was measured\" without inferring it from a verdict"New value: +"per-census count of records the LIVE source returned, before any merge, cap or spam filter — the evidence behind seedsOnlyScans. 0 means the live source supplied nothing (the census is its fallback); -1 means this census was last written by a build that did not record the field, which is NOT the same as zero. Published even when healthy, so a reader can distinguish \"source is fine\" from \"nothing was measured\" without inferring it from a verdict. Never omitted: built over the census keys in counts, so every census always carries a value and -1 covers the pre-field case — the earlier exemption for records predating the field was retired when the conditional spread was removed"

addedOutput schema / properties / censusRecordsBeforeCap

Added value: +{
+  "description": "per-census record count BEFORE the fungible (170) and NFT (50) caps. A count sitting exactly on its cap cannot say whether it is a finding or a ceiling — hyperevm_census reads 170 because 170 IS the cap. Compare against counts: a value here greater than the published count means that census was TRUNCATED, equal means it was not. -1 means the build that last wrote this census did not record the field. Never omitted, same construction as censusLiveRecords",
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026

addedOutput schema / properties / censusLiveRecords

Added value: +{
+  "description": "per-census count of records the LIVE source returned, before any merge, cap or spam filter — the evidence behind seedsOnlyScans. 0 means the live source supplied nothing (the census is its fallback); -1 means this census was last written by a build that did not record the field, which is NOT the same as zero. Published even when healthy, so a reader can distinguish \"source is fine\" from \"nothing was measured\" without inferring it from a verdict",
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026

addedOutput schema / properties / sourceErrors

Added value: +{
+  "description": "per-chain list of what each live source ACTUALLY answered when it failed, e.g. \"robinhood/ERC-20: blockscout /api/v2/tokens → 403\". Says WHY a census is thin where seedsOnlyScans only says THAT it is. Capped at 4 entries per chain; when more were recorded the list carries a final \"… +N more (T total)\" string, so the count survives the truncation rather than the list silently reading as complete. Omitted when every source succeeded",
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026

addedOutput schema / properties / seedsOnlyScans

Added value: +{
+  "description": "chains whose last scan returned ONLY hardcoded canonical seeds — every live source returned nothing while the fallback held, so the count is non-zero and emptyScans does NOT list them. Sets status=degraded. Omitted when none",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed7 schema fields changedAug 8, 2026

removedOutput schema / properties / chains

Removed value: -{
-  "description": "per-chain scan counts/failures",
-  "type": "object"
-}

addedOutput schema / properties / counts

Added value: +{
+  "description": "per-chain program counts from the last scan",
+  "type": "object"
+}

addedOutput schema / properties / emptyScans

Added value: +{
+  "description": "chains whose last scan returned zero (omitted when none)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / failedScans

Added value: +{
+  "description": "chains whose last scan errored (omitted when none)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / history

Added value: +{
+  "description": "per-chain counts over the last <=24 cron runs, oldest first",
+  "items": {
+    "properties": {
+      "counts": {
+        "description": "per-chain program count at that run",
+        "type": "object"
+      },
+      "ts": {
+        "description": "unix seconds",
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "plain-language reading of status",
+  "type": "string"
+}

changedOutput schema / properties / status / description

Previous value: -"healthy | stale | failing"New value: +"healthy | stale | degraded"

First observedJul 17, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden, and it largely meets it by stating what the tool reports and why. It does not explicitly say the operation is read-only or non-mutating, but the health-report framing makes that clear. It also exposes potential failure information (which scans failed), which is useful behavioral context.

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

Conciseness5/5

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

Two sentences, no filler, with the main purpose front-loaded. The second sentence provides actionable guidance without repeating the first.

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 zero-parameter health-check tool with an output schema, the description covers the relevant scope: freshness, counts, failures, and when to use it. Nothing needed for correct invocation is missing.

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

Parameters4/5

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

The tool has zero parameters, so there is no schema to supplement. The description still adds meaningful context about what the report covers, satisfying the baseline for parameterless tools.

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

Purpose5/5

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

The description uses a specific verb ('Report') and names a precise resource: freshness and health of the cross-chain discovery pipeline. It enumerates concrete outputs (last cron run, per-chain counts, failed scans) and distinguishes itself from the data-producing siblings discover_programs and search_tokens.

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

Usage Guidelines5/5

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

The description gives an explicit usage condition: use this before relying on discover_programs/search_tokens data to verify it is current. This directly tells an agent when to call this tool versus the alternative data-fetching tools.

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

All aeX402 — Cross-Chain DeFi MCP: LINQ, AMM, Bridge, AI 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.

Resources

Need Help?