Skip to main content
Glama
DeFadeLtd

DeFade

Official
by DeFadeLtd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

API usage

get_usage
Read-onlyIdempotent

Check your API key's plan, rate limits, and remaining monthly quota. Use this when a request fails on limits or to see what your DeFade subscription includes.

Instructions

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
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoThe 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.
unitsNoHow metering works: one request is one unit except the heaviest EVM modules, listed in heavyOnEvm with heavyCost.
usageNotoday, total, thisPeriod, remainingThisPeriod, periodResetsAt.
limitsNoperMinute, perDay, perMonth; perMonth is null on grandfathered keys.
creditsNoOverage: balance, overageEnabled, costPerRequest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.3
    • 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 / 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."
    • 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"
+]
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context: the operation targets the calling key's own usage, requires no arguments, and is the right call for quota failures. No side effects are concealed, and nothing contradicts the 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?

Three sentences, each earning its place: what it reports, when to use it, and what it is not for. The information is front-loaded and there is 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-parameter read-only tool with an output schema, the description fully covers purpose, invocation context, scope, and exclusions. The output schema handles return-value details, leaving no meaningful gap for an agent to call 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?

The tool has zero parameters, so baseline is 4. The description reinforces this by explicitly saying 'Takes no arguments,' which prevents an agent from trying to pass a token address despite the sibling tools all taking an address.

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?

Description uses a specific verb ('Report') and resource ('the calling API key's plan, rate limits and monthly allowance left'). It clearly distinguishes from sibling token-focused tools by stating this tool reports on the key itself, not a token or address.

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?

Explicitly states when to use: on quota failure or when the user asks about their DeFade plan. It also provides an exclusion: not for anything about a token, and notes every other tool takes an address while this one takes none. This gives clear routing versus siblings.

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

Deploy Server

Other Tools