get_usageGets the credits an app used this month, how many its plan has per month, and the credits used each day and by commands, event listeners and messages. Credits reset at the start of each month in UTC, and an app that uses all of them stops running flows until then. get_blocks says what each block costs, and list_plans what other plans include.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The ID of the app, from list_apps. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: credits reset at the start of each month in UTC and the app stops running flows when credits are exhausted, which an agent wouldn't know from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the returned data followed by reset mechanics and cross-references. Every clause earns its place, though the parenthetical breakdown is slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by enumerating the returned data (monthly usage, plan allowance, daily and per-category breakdown). Combined with 100% param coverage and read-only annotations, an agent has nearly everything needed, with only exact response shape left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and app_id is documented in the schema as coming from list_apps. The description refers to 'an app' but adds no format or source detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Gets) and resource (credits an app used this month) plus the returned fields: plan allowance, daily usage, and breakdown by commands, event listeners, and messages. Clearly distinguishable from siblings like list_plans and get_blocks, which are explicitly named for different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the usage context (checking credit consumption and plan limits) but never explicitly states when to call this versus alternatives. The referenced siblings get_blocks and list_plans are for cost-per-block and plan contents, not alternative ways to get usage, so no true routing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.