Skip to main content
Glama

API Rate Limit Utilization Calculator

rate-limit-utilization-calculator
Read-onlyIdempotent

Calculate API rate limit utilization given current request count and limit. Returns utilization percentage, buffer, safety status, and risk level (OK at <80%, WARNING at 80-95%, CRITICAL at >95%).

Input Schema

NameRequiredDescriptionDefault
limitYesRate limit ceiling
window_secondsNoRate limit window in seconds (e.g. 60 for per-minute)
current_requestsYesCurrent request count in the window

Output Schema

NameRequiredDescriptionDefault
safeYes
bufferYes
statusYes
next_stepYes
next_step_urlYes
why_follow_upYes
interpretationYes
window_secondsYes
utilization_pctYes
affiliate_contextNo
computation_basisYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / current_requests / examples
      Added value: +[
      +  1
      +]
    • addedInput schema / properties / limit / examples
      Added value: +[
      +  1
      +]
    • addedInput schema / properties / window_seconds / examples
      Added value: +[
      +  1
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "affiliate_context": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "affiliate": {
      +          "type": "string"
      +        },
      +        "cta_label": {
      +          "type": "string"
      +        },
      +        "disclosure": {
      +          "type": "string"
      +        },
      +        "framing": {
      +          "type": "string"
      +        },
      +        "posture": {
      +          "enum": [
      +            "secondary"
      +          ],
      +          "type": "string"
      +        },
      +        "slot_id": {
      +          "type": "string"
      +        },
      +        "url": {
      +          "type": "string"
      +        },
      +        "variant": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "affiliate",
      +        "cta_label",
      +        "disclosure",
      +        "framing",
      +        "posture",
      +        "slot_id",
      +        "url",
      +        "variant"
      +      ],
      +      "type": "object"
      +    },
      +    "buffer": {
      +      "type": "number"
      +    },
      +    "computation_basis": {
      +      "type": "string"
      +    },
      +    "interpretation": {
      +      "type": "string"
      +    },
      +    "next_step": {
      +      "type": "string"
      +    },
      +    "next_step_url": {
      +      "type": "string"
      +    },
      +    "safe": {
      +      "type": "boolean"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "utilization_pct": {
      +      "type": "number"
      +    },
      +    "why_follow_up": {
      +      "type": "string"
      +    },
      +    "window_seconds": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "buffer",
      +    "computation_basis",
      +    "interpretation",
      +    "next_step",
      +    "next_step_url",
      +    "safe",
      +    "status",
      +    "utilization_pct",
      +    "why_follow_up",
      +    "window_seconds"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare this is a safe, read-only, idempotent computation. The description adds genuinely useful behavior beyond that: the risk-band thresholds (OK <80%, WARNING 80-95%, CRITICAL >95%) and the shape of the result (percentage, buffer, safety status, risk level).

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?

Two tightly written sentences: the computation first, then the output and thresholds. No filler, no repetition of the title.

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?

A simple, fully documented calculator with 100% schema coverage and an output schema, so return values need not be explained. Everything an agent needs to invoke it is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents current_requests, limit, and window_seconds. The description restates two of the three parameters but adds no format or semantics beyond the schema, so the baseline 3 applies.

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 verb and resource ('Calculate API rate limit utilization') and names the inputs it operates on. Among a large family of calculator siblings, this one's domain is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies when it is useful (checking headroom against a limit), but there is no explicit guidance on when to reach for this versus related calculators like slo-burn-rate-calculator or error-budget-calculator, and no stated exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources