Skip to main content
Glama

List quotas

exoscale_list_quotas
Read-only

Resource quotas of the organization: for each resource its current usage and limit (instances, volumes, elastic IPs, and so on). GET /quota.

Input Schema

NameRequiredDescriptionDefault
limitNoItems per window, 1-500 (default 100). The API itself returns whole lists.
offsetNoItems to skip (default 0). Pass the previous reply's next_offset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: the scope is the whole organization and each entry carries both usage and limit, plus the HTTP endpoint (GET /quota). It does not discuss pagination behavior beyond what the schema already documents.

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?

One compact sentence plus the endpoint, with the resource scope front-loaded. Nothing is wasted, though the trailing 'GET /quota' is redundant detail rather than actionable guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description appropriately characterizes the return value (per-resource usage and limit, with examples), which is what the agent needs to interpret results. Only the distinction from exoscale_get_quota is left unaddressed.

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 description coverage is 100% and both parameters (limit, offset) are fully documented in the schema, including defaults and the next_offset pattern. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource — the organization's resource quotas — and clarifies the return content: current usage and limit per resource, with examples. It is clear what the tool does, but it does not distinguish itself from the sibling 'exoscale_get_quota', which an agent could easily confuse it with.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus the closely related exoscale_get_quota or exoscale_get_organization. The agent must infer that 'list' means all resources rather than one, which the description never states.

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.