Skip to main content
Glama

ResumeQuick

by app.resumequick
OverviewDiscussionsAdmin

Read my usage and limits

get_usage
Read-only

Get the user's own use of their plan: for each limited action, how many uses the current period counted, the allowance, and how many are available now; when a calendar period (day, month) resets, and for rolling windows (week, 30 days) when the oldest use drops out; bonus and pack credits, which buy uses beyond an allowance; and when a paid plan or trial ends. A resume generated in the background from text or answers (create_profile, the web onboarding) counts against resume_generation. Radar scans are not bought with bonus or pack credits. The actions listed are the same ones get_pricing gives limits for. Plan prices and the limits of other plans are in get_pricing.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
planYesThe user's current tier: 'free' | 'sprint' | 'career'.
itemsYesOne row per action the plan limits.
creditsYesBonus and pack credits, which buy uses beyond an action's allowance on any plan; null when there are none.
plan_ends_atYesISO 8601 UTC moment the paid plan or trial ends and the account returns to free; null on free. Whether a plan renews is the auto_renews of its SKU in get_pricing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • removedOutput schema / $defs / UsageCredits / properties / remaining
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "Credits left in this month's pool; null on plans without a pool.",
-  "title": "Remaining"
-}
    • removedOutput schema / $defs / UsageCredits / properties / resets_at
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 8601 UTC moment the pool refills to total; null on plans without a pool.",
-  "title": "Resets At"
-}
    • removedOutput schema / $defs / UsageCredits / properties / total
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "The pool's monthly size on the current plan; null on plans without a pool.",
-  "title": "Total"
-}
    • changedOutput schema / $defs / UsageCredits / required
      Previous value: -[
-  "remaining",
-  "total",
-  "resets_at",
-  "bonus",
-  "pack_credits"
-]New value: +[
+  "bonus",
+  "pack_credits"
+]
    • changedOutput schema / $defs / UsageItem / properties / credit_cost / description
      Previous value: -"Credits one use of this action is worth. chat_message, interview_session and radar_scan never draw on the monthly credit pool, and radar_scan is not bought with bonus or pack credits either."New value: +"Bonus or pack credits one use of this action costs once its allowance is spent. radar_scan is not bought with credits."
    • changedOutput schema / $defs / UsageItem / properties / remaining / description
      Previous value: -"Uses available right now: what the allowance has left, plus what the bonus and pack credits in `credits` can buy of this action beyond it, capped by the monthly credit pool on plans that have one. So remaining can be larger than limit. Null means unlimited."New value: +"Uses available right now: what the allowance has left, plus what the bonus and pack credits in `credits` can buy of this action beyond it. So remaining can be larger than limit. Null means unlimited."
    • changedOutput schema / properties / credits / description
      Previous value: -"The monthly credit pool on plans that meter one (free, sprint), and bonus and pack credits on any plan; null when there is neither."New value: +"Bonus and pack credits, which buy uses beyond an action's allowance on any plan; null when there are none."
  2. Changed1 schema field changed
    • changedOutput schema / $defs / UsageItem / properties / action / description
      Previous value: -"Action type, e.g. 'vacancy_analysis' | 'resume_generation' | 'chat_message'. 'pdf_download' counts new PDF files; downloading the file already made for an unchanged resume is not counted."New value: +"Action type, e.g. 'vacancy_analysis' | 'resume_generation' | 'chat_message'."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered, and the description still contributes substantive behavior: reset semantics for calendar vs rolling windows (oldest use drops out), that bonus/pack credits buy uses beyond an allowance, that background-generated resumes count against resume_generation, and that Radar scans are excluded from credit spending.

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?

The payload is front-loaded in the first clause (own use of the plan, per limited action) and each following clause carries distinct semantic content about resets, credits, and plan expiry. It is dense and somewhat long, but nearly every clause earns its place; the return-value detail overlaps with the output schema.

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?

With an output schema present, the description need not restate return shape, yet it still supplies the domain semantics an agent needs: what a limited action is, how periods and rolling windows reset, which activities consume allowances, and where to go for pricing. Nothing required to call or interpret the tool is missing.

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?

Zero parameters, so there is no schema surface for the description to compensate for; baseline 4 applies. The description also scopes the result set implicitly by talking only about the caller's own plan rather than arbitrary users.

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 (the user's own usage of their plan) and enumerates exactly what is returned: per-action counts, allowances, availability, reset timing, bonus/pack credits, and plan/trial end dates. It is clearly differentiated from the sibling get_pricing, which covers prices and other plans' limits.

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?

Names the alternative explicitly: prices and other plans' limits live in get_pricing, while this tool covers the caller's own usage and the same limited actions get_pricing enumerates. The condition that selects one tool over the other is stated, not inferred.

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

All ResumeQuick toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources