DeFade — Multi-Chain Memecoin Analyzer

API usage

get_usage

Read-onlyIdempotent

Report the calling API key's plan, rate limits and how much of its monthly allowance is left. Takes no arguments. Use it when a call fails on quota, or when the user asks what their DeFade plan includes. Not for anything about a token — every other tool takes an address; this one reports on the key itself.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`tier`	No	The tier this key is on. web_mcp is the connector key included with a DeFade Pro web subscription; its allowance is the plan's monthly scans, reported in plan/limits.perMonth.
`units`	No	How metering works: one request is one unit except the heaviest EVM modules, listed in heavyOnEvm with heavyCost.
`usage`	No	today, total, thisPeriod, remainingThisPeriod, periodResetsAt.
`limits`	No	perMinute, perDay, perMonth; perMonth is null on grandfathered keys.
`credits`	No	Overage: balance, overageEnabled, costPerRequest.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 5, 2026

changedOutput schema / properties / tier / description

Previous value: -"The tier this key is on."New value: +"The tier this key is on. web_mcp is the connector key included with a DeFade Pro web subscription; its allowance is the plan's monthly scans, reported in plan/limits.perMonth."

Changed5 schema fields changedSep 5, 2026

changedOutput schema / properties / credits / type

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

changedOutput schema / properties / limits / type

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

changedOutput schema / properties / tier / type

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

changedOutput schema / properties / units / type

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

changedOutput schema / properties / usage / type

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

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "credits": {
+      "additionalProperties": true,
+      "description": "Overage: balance, overageEnabled, costPerRequest.",
+      "type": "object"
+    },
+    "limits": {
+      "additionalProperties": true,
+      "description": "perMinute, perDay, perMonth; perMonth is null on grandfathered keys.",
+      "type": "object"
+    },
+    "tier": {
+      "description": "The tier this key is on.",
+      "type": "string"
+    },
+    "units": {
+      "additionalProperties": true,
+      "description": "How metering works: one request is one unit except the heaviest EVM modules, listed in heavyOnEvm with heavyCost.",
+      "type": "object"
+    },
+    "usage": {
+      "additionalProperties": true,
+      "description": "today, total, thisPeriod, remainingThisPeriod, periodResetsAt.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

AddedSep 3, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds useful context beyond annotations: the operation is scoped to the caller's key, takes no arguments, and reports quota/allowance state. It does not enumerate possible response fields, but the presence of an output schema lowers that burden.

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?

Three short sentences, each earning its place: the first states the core purpose, the second gives practical triggers, the third excludes token-related uses. It is front-loaded with the most important information and contains 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?

For a zero-argument, read-only reporting tool with a rich output schema and annotations, the description covers purpose, usage triggers, scope, and exclusions. There are no meaningful gaps that would prevent an agent from selecting and invoking it correctly.

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?

With zero parameters and 100% schema description coverage, the schema leaves nothing undocumented. The description reinforces 'Takes no arguments,' which is redundant but clear. Baseline for zero-parameter tools is 4, and nothing here reduces that.

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 opens with a specific verb and resource: 'Report the calling API key's plan, rate limits and how much of its monthly allowance is left.' It clearly distinguishes itself from the sibling tools by explicitly stating it reports on the API key itself, not on a token or address. This makes its role unambiguous.

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?

It gives explicit trigger conditions: 'Use it when a call fails on quota, or when the user asks what their DeFade plan includes.' It also provides a clear when-not: 'Not for anything about a token — every other tool takes an address; this one reports on the key itself.' This is strong routing guidance relative to the sibling list.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Every tool targets a distinct forensic question — creator behavior, launch coordination, lone snipers, proven wallet links, behavioral similarity, config matching — and each description explicitly names which sibling tools it is NOT for. Even the near-inverse pair get_rug_score (danger probability) and get_token_scan (safety score) is handled with explicit call-routing rules. No two tools have unclear boundaries.

Naming Consistency5/5

All 15 tools follow the identical get_<noun> pattern with snake_case throughout: get_holders, get_whales, get_token_scan, get_usage. The verb is uniform and the noun precisely names the resource or analysis domain, making the surface trivially predictable.

Tool Count5/5

15 tools sits at the upper edge of the well-scoped range, and each tool earns its place as a distinct analysis module for the broad multi-chain memecoin forensics domain. Nothing feels redundant — the count reflects the genuine breadth of the domain: launch, holders, liquidity, forensics, market data, and quota.

Completeness4/5

The token risk-assessment lifecycle is thoroughly covered: scan → rug score → holders → whales → dev tracker → launch → liquidity → forensics → price → usage form a complete investigation pathway with no dead ends. Minor gaps exist: no long historical price data (get_token_price only returns recent candles) and no token discovery/search — the server assumes you already have an address. These are work-aroundable but arguably core for a full analyzer.

Resources

Need Help?