DeFade — Multi-Chain Memecoin Analyzer

Token price

get_token_price

Read-onlyIdempotent

Price history for one token as OHLCV candles, plus the latest price, the window's high and low with their timestamps, and the percent change across the window — prices in USD (the *Usd fields), volume as the market source quotes it. Aggregated from DEX market sources and cached for about a minute. Intervals with no trades are omitted rather than zero-filled, so consecutive candles can sit more than one step apart. The optional timeframe argument sets the candle size and with it how far back the window reaches: 15m (the default) covers about the last 2.5 days, 1H about 10 days, 4H about 40 days and 1D up to a year of daily candles, back to the token's first trade if it is younger; there is no start or end argument, the size fixes the window. Use 1D for "what did it peak at", "how far is it down from the top" or any price history question; use the default for the market context around a risk verdict. A token with no liquidity pool returns candles: [] and totalCandles: 0 rather than an error. Not for risk of any kind — market data carries no forensic signal — and not for pool depth or lock status (get_liquidity) or market cap (get_token_scan's token block). Arguments: address, chain and timeframe — a 0x address needs its chain; one API unit on any chain regardless of timeframe.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`chain`	No	Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan.	solana
`address`	Yes	The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected.
`timeframe`	No	Candle size, which also sets the window: 1m ≈ last 4 hours, 5m ≈ 20 hours, 15m ≈ 2.5 days (default), 30m ≈ 5 days, 1H ≈ 10 days, 4H ≈ 40 days, 1D ≈ up to 365 days. A token younger than the window returns candles from its first trade. Any other value is rejected before a request is spent.	15m

Output Schema

TableJSON Schema

Name	Required	Description
`high`	No	Window high as priceUsd plus ts; low is the same shape.
`token`	No	The address that was scanned (on get_token_scan, the full token metadata object instead).
`candles`	No	OHLCV candles, oldest first: ts (ms), open, high, low, close, volume and *Usd values.
`current`	No	Latest close as current.priceUsd.
`poweredBy`	No	Always "DeFade.org".
`timestamp`	No	ISO time the response was assembled.
`priceChange`	No	Percent change from the first candle to the last. Null when it cannot be computed.
`totalCandles`	No	Number of candles; a token with no chart data answers 0.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 6, 2026

addedInput schema / properties / timeframe

Added value: +{
+  "default": "15m",
+  "description": "Candle size, which also sets the window: 1m ≈ last 4 hours, 5m ≈ 20 hours, 15m ≈ 2.5 days (default), 30m ≈ 5 days, 1H ≈ 10 days, 4H ≈ 40 days, 1D ≈ up to 365 days. A token younger than the window returns candles from its first trade. Any other value is rejected before a request is spent.",
+  "enum": [
+    "1m",
+    "5m",
+    "15m",
+    "30m",
+    "1H",
+    "4H",
+    "1D"
+  ],
+  "type": "string"
+}

Changed7 schema fields changedSep 5, 2026

changedOutput schema / properties / candles / type

Previous value: -"array"New value: +[
+  "array",
+  "null"
+]

changedOutput schema / properties / current / type

Previous value: -"object"New value: +[
+  "object",
+  "null"
+]

changedOutput schema / properties / high / type

Previous value: -"object"New value: +[
+  "object",
+  "null"
+]

changedOutput schema / properties / poweredBy / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / priceChange / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

changedOutput schema / properties / timestamp / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / totalCandles / type

Previous value: -"number"New value: +[
+  "number",
+  "null"
+]

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "candles": {
+      "description": "OHLCV candles, oldest first: ts (ms), open, high, low, close, volume and *Usd values.",
+      "type": "array"
+    },
+    "current": {
+      "additionalProperties": true,
+      "description": "Latest close as current.priceUsd.",
+      "type": "object"
+    },
+    "high": {
+      "additionalProperties": true,
+      "description": "Window high as priceUsd plus ts; low is the same shape.",
+      "type": "object"
+    },
+    "poweredBy": {
+      "description": "Always \"DeFade.org\".",
+      "type": "string"
+    },
+    "priceChange": {
+      "description": "Percent change from the first candle to the last. Null when it cannot be computed.",
+      "type": "number"
+    },
+    "timestamp": {
+      "description": "ISO time the response was assembled.",
+      "type": "string"
+    },
+    "token": {
+      "description": "The address that was scanned (on get_token_scan, the full token metadata object instead)."
+    },
+    "totalCandles": {
+      "description": "Number of candles; a token with no chart data answers 0.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedSep 3, 2026

changedInput schema / properties / address / description

Previous value: -"Token contract address. A base58 mint for Solana, or 0x-prefixed for EVM chains. Set `chain` to match — a 0x address alone cannot say which EVM chain it lives on."New value: +"The token's own contract address, exactly as an explorer shows it. Solana: the base58 mint, 32-44 characters (e.g. 6p6xgHyF7AeE6TZkSmFsko444wqoP15icUSqi2jfGiPN). EVM: 0x followed by 40 hex characters, case-insensitive (e.g. 0x6982508145454ce325ddbe47a25d4ec3d2311933). Never a pool, pair, wallet or deployer address — those come back as not found. Set `chain` to match the address: a 0x address alone cannot say which EVM chain it lives on, and a Solana mint sent with an EVM chain is rejected."

changedInput schema / properties / chain / description

Previous value: -"Which chain the address lives on. Defaults to solana."New value: +"Chain the token is deployed on: solana (default), ethereum, base, robinhood. Required for any 0x address, because the same contract address can exist on several EVM chains. Omit it for Solana. An unsupported value is rejected before any request is spent; EVM chains need a key on an All-Chains plan."

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and non-destructive behavior, and the description adds substantial behavioral context: results are aggregated from DEX sources and cached for about a minute, intervals without trades are omitted, and a token with no liquidity pool returns empty candles rather than an error. This goes well beyond the structured annotations.

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?

The description is dense but well organized: core result first, then caching and candle behavior, then timeframe semantics, then usage examples, then exclusions, then argument notes. Every sentence adds information an agent needs to select and call the tool correctly, with no filler.

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?

The description covers return content, window determination, missing-data behavior, explicit usage alternatives, and argument caveats. With an output schema present and annotations covering the read-only safety profile, nothing an agent needs to correctly decide when and how to call this tool 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 description coverage is 100%, but the description still adds meaningful parameter semantics by explaining that the timeframe argument fixes the window, that there is no start/end argument, and that a 0x address needs its chain. It also clarifies API unit cost and edge behavior for the address parameter.

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 states a specific verb and resource: 'Price history for one token as OHLCV candles, plus the latest price, the window's high and low with their timestamps, and the percent change across the window.' It also clearly distinguishes itself from siblings by naming what it is not for, such as liquidity, market cap, and risk assessment.

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?

Explicit usage guidance is present: 'Use 1D for "what did it peak at", "how far is it down from the top" or any price history question; use the default for the market context around a risk verdict.' It also names exclusions and alternative tools: 'not for pool depth or lock status (get_liquidity) or market cap (get_token_scan's token block).'

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

All DeFade — Multi-Chain Memecoin Analyzer 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?