Skip to main content
Glama

Superpowers

by tools.superpowers
OverviewDiscussionsAdmin

Get usage

get_usage
Read-onlyIdempotent

Account spend grouped by project (job), agent, key, provider, trace, tool, day or tag: (e.g. tag:slot), optionally filtered by tags, key or job. Rows for keys, jobs and tags include their monthly limit.

Input Schema

NameRequiredDescriptionDefault
jobNoOnly runs with this job (project_id)
keyNoOnly runs made with this key id
tagsNoOnly runs with all these tags, e.g. {"project": "ai-influencers"}
groupNoHow to group usage: project (job), agent, key, provider, trace, tool, day or tag:<name>, e.g. tag:slot.
sinceNoYYYY-MM-DD; default the 1st of this month (UTC)
untilNoYYYY-MM-DD, exclusive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / group / description
      Previous value: -"How to group usage: project, agent, key, provider, trace or tool."New value: +"How to group usage: project (job), agent, key, provider, trace, tool, day or tag:<name>, e.g. tag:slot."
    • addedInput schema / properties / job
      Added value: +{
+  "description": "Only runs with this job (project_id)",
+  "type": "string"
+}
    • addedInput schema / properties / key
      Added value: +{
+  "description": "Only runs made with this key id",
+  "type": "string"
+}
    • changedInput schema / properties / since / description
      Previous value: -"YYYY-MM-DD"New value: +"YYYY-MM-DD; default the 1st of this month (UTC)"
    • addedInput schema / properties / tags
      Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Only runs with all these tags, e.g. {\"project\": \"ai-influencers\"}",
+  "type": "object"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "description": "YYYY-MM-DD, exclusive",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / group / description
      Added value: +"How to group usage: project, agent, key, provider, trace or tool."
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful shape information not in the annotations: key/job/tag rows carry their monthly limit, and grouping is controlled by a tag:<name> dimension.

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?

Two dense sentences with no filler, and the primary grouping behavior is front-loaded. There is mild redundancy between the group enumeration in the first sentence and the schema's group description, but the sentence still earns its length.

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?

For a read-only aggregation over six optional filters with a fully covered schema and no output schema, the description explains both the grouping axis and the filter dimensions adequately. Missing only minor operational detail such as row limits/pagination and the default time window, which the schema partially covers.

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%, so all six parameters are already documented in the schema, including the group dimension list and the tag syntax. The description restates the same group enumeration and tag example rather than adding syntax, defaults, or constraints beyond it; 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 names a concrete resource and action ('Account spend grouped by...'), and enumerates the available grouping dimensions, so an agent knows exactly what is computed. It does not explicitly distinguish itself from nearby spend/viewer tools such as get_balance or compare_providers, so sibling differentiation is left to inference.

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?

It conveys implied usage through the filter clause ('optionally filtered by tags, key or job'), which tells the agent this is a filtered aggregation query. However, it never states when to prefer this tool over get_balance or compare_providers, and offers no exclusions or prerequisites.

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

All Superpowers 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