Nopaque TotalPath

Get What Used the Allowance

getUsageBySource

Read-onlyIdempotent

What used a calendar month's allowance (period=YYYY-MM, default this month; not the billing period): billed seconds and tokens per standard test, mission test, mapping job, load test and Quinn, largest first, at most 20, each with its id and name where they can be found (null otherwise). otherSources counts the sources left out. Mission testing is not itemised per test today and shows as one mission_test row with no id. Use when: someone asks which tests or maps used their minutes. Owner or billing admin only; other roles get 403. Only a person signed in to the nopaque web app can call this; an API key is refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceId": "<workspaceId>"
    },
    "name": "getUsageBySource"
  }
}

Input Schema

Name	Required	Description	Default
`period`	No	The month, YYYY-MM (UTC). Default is the current month.
`workspaceId`	Yes	Workspace identifier. Must be the caller's current workspace.

Output Schema

Name	Required	Description	Default
`sources`	Yes
`otherSources`	Yes
`billingPeriod`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the read-only, idempotent, non-destructive annotations, the description discloses role-based access (owner or billing admin only, others get 403), web-app session requirements, API-key refusal, ordering and limit behavior, null id/name handling, and otherSources counting. It also explains that mission testing is aggregated into one mission_test row without an id, which is meaningful behavioral context.

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 description is front-loaded with what is returned and then supplies usage and access constraints. It is dense and somewhat repetitive with the schema's period default, but nearly every detail earns its place.

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?

Given the presence of an output schema, the description does not need to explain return values in full, yet it still covers ordering, limit, null handling, aggregated mission testing, access control, and authentication restrictions. It is complete enough for an agent to call the tool correctly.

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 both period and workspaceId are already documented in the schema. The description adds useful nuance that period is a calendar month and not the billing period, but it says little about workspaceId beyond what the schema already provides, so baseline 3 is appropriate.

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 verb and resource: what used a calendar month's allowance, broken down by test, mapping job, load test, and Quinn. It distinguishes the calendar-month allowance from the billing period, but it does not explicitly name sibling tools such as getWorkspaceUsageThisPeriod, so it falls short of full sibling differentiation.

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

Usage Guidelines4/5

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

It gives a clear when-to-use cue: 'Use when: someone asks which tests or maps used their minutes.' It also states exclusions around billing period, caller role, and authentication method, but it does not name alternative tools for related usage questions.

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

All Nopaque TotalPath tools Inspect

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.