Skip to main content
Glama
Sign In

Moby

by win.moby
OverviewDiscussionsAdmin

My rate limits and usage

get_my_limits
Read-only

Moby's rate limits for this API key: per-minute and daily limits, today's usage, the fee tier and what raises it. Costs nothing (never rate-limited). Use for "what are my API limits", "why was I rate limited". - limits: per-minute (*_per_minute) and daily QUOTAS (daily_*); 0 = that limit is off.

  • usage: calls USED today (*_today) and *_remaining_this_minute; null = unreadable.

  • tier and fees_window_usd (trading fees paid over window_days); next_tier / fees_to_next_tier_usd = the fees that raise the limits. They rise on their own. Read it before a large pass instead of learning the limits from a refusal.

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_my_limits"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (readOnly, non-destructive, closed-world), it adds a genuine behavioral trait: "Costs nothing (never rate-limited)", which tells the agent this call is safe to make speculatively. It also decodes the response fields (0 = limit off, null = unreadable), though that overlaps with the existing output schema, which keeps it from a 5.

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

Conciseness4/5

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

Front-loaded with the purpose and the cost-free property, then a compact field glossary. The field breakdown is somewhat dense and partly duplicates the output schema, but every line conveys usable meaning rather than 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 tool with full annotation coverage and an output schema, nothing is missing: the agent knows what it returns, that it is free to call, and when to call it. The extra field semantics are surplus but harmless.

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 takes zero parameters, so there is no parameter meaning to convey; the baseline for a no-param tool applies. Nothing in the description misleads about inputs.

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 names a specific resource (rate limits and usage for this API key) and enumerates its scope: per-minute and daily limits, today's usage, fee tier, and what raises it. This is clearly distinguishable from sibling tools like get_my_activity or get_my_balances, which cover usage history and holdings rather than quota state.

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 phrasings ("what are my API limits", "why was I rate limited") and a proactive directive: "Read it before a large pass instead of learning the limits from a refusal." That is a concrete when-to-use rule, not an implied one, and no competing tool covers this need.

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

All Moby toolsInspect
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