Unlock Pulse

Locked-token wallets on-chain

get_onchain_check

Read-only

What is actually happening on-chain with a token's locked allocations: the vesting contracts and wallets holding team, investor and treasury tokens, how much they hold now, outflows (tokens leaving locked wallets), mints, burns and contract upgrades, the next unlock by the project's own documents, and our short finding (for example: unlocked but never withdrawn, tranches sent to an exchange, vesting contract has not paid out). Use for 'are team tokens moving', 'did the unlock really happen', 'who is selling'. Without a token: recent movements across all covered tokens. token accepts a ticker (preferred), a name or a slug; covered_tokens in the result lists what we track (a few dozen tokens, not the whole calendar). Movements look back at most 30 days; wallet roles marked 'our attribution' are our analysis, not the project's statement. For the unlock calendar use get_token_unlocks.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_onchain_check"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Look-back window for the list of recent movements (no token).
`lang`	No	Language of the page links.	en
`token`	No	Ticker, name or slug. Leave empty for recent movements across all covered tokens.

Output Schema

Name	Required	Description	Default
`name`	No
`note`	No
`found`	No
`token`	No
`events`	No
`method`	No
`source`	Yes
`symbol`	No
`finding`	No
`license`	No
`message`	No
`reading`	No
`movements`	No
`window_days`	No
`covered_tokens`	No
`movements_found`	No
`tracked_wallets`	No
`attribution_note`	No
`data_updated_utc`	No
`tokens_with_findings`	No
`upcoming_unlocks_in_calendar`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution_note": {
+      "type": "string"
+    },
+    "covered_tokens": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "data_updated_utc": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "events": {
+      "type": "array"
+    },
+    "finding": {},
+    "found": {
+      "type": "boolean"
+    },
+    "license": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "type": "string"
+    },
+    "method": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "movements": {
+      "type": "array"
+    },
+    "movements_found": {
+      "type": "number"
+    },
+    "name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": "string"
+    },
+    "reading": {
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    },
+    "symbol": {
+      "type": "string"
+    },
+    "token": {
+      "type": "string"
+    },
+    "tokens_with_findings": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "tracked_wallets": {
+      "type": "array"
+    },
+    "upcoming_unlocks_in_calendar": {
+      "type": "array"
+    },
+    "window_days": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "source"
+  ],
+  "type": "object"
+}

AddedOct 28, 2026

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 the description's real contribution is data-provenance caveats: movements are capped at a 30-day lookback, coverage is only a few dozen tokens rather than the whole calendar, and wallet roles marked 'our attribution' are the provider's analysis rather than the project's statement. That is meaningful context an agent could not infer from annotations; only rate/cost limits are absent.

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?

Content is front-loaded and mostly earns its place, but the entire body is one long run-on sentence dense with clauses (holdings, outflows, mints, burns, upgrades, unlock, finding, examples, caveats). Splitting into short paragraphs for what-you-get, inputs, and caveats would make it far more scannable without losing 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?

An output schema exists so return values need not be explained, and the description still tells the agent that covered_tokens appears in the result and what the finding field means. Coverage scope and the attribution disclaimer make it largely sufficient for a read-only, open-world lookup 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: token accepts a ticker (preferred), a name, or a slug, and leaving it empty switches the tool to a cross-token movements mode. The 30-day cap on days is also restated as a behavioral limit rather than just a JSON maximum.

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 resource and scope: on-chain locked allocations, vesting contracts, wallet holdings for team/investor/treasury, outflows, mints, burns, contract upgrades, next documented unlock, and a short finding. This is clearly differentiated from the sibling get_token_unlocks, which is explicitly named as the calendar tool.

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?

Gives explicit example questions that select this tool ('are team tokens moving', 'did the unlock really happen', 'who is selling'), states the no-token behavior (recent movements across all covered tokens), and routes the unlock-calendar use case to get_token_unlocks. Both when-to-use and the alternative are covered.

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

All Unlock Pulse 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.