Skip to main content
Glama
Sign In

Nopaque TotalPath

by uk.co.nopaque
OverviewDiscussionsAdmin

Get Usage This Billing Period

getWorkspaceUsageThisPeriod
Read-onlyIdempotent

Usage in the current billing period, per bucket: seconds of standard testing, load testing, mapping, AI voice experience, mission testing and compliance testing; AI tokens (all, and the Quinn, digital testing and voice analysis parts); survey SMS segments; calls. periodStart and periodEnd are the billing period, which is not the calendar month. Figures are usage, never money. Use when: someone asks how much they have used this period. Owner or billing admin only; other roles get 403. Only a person signed in to the nopaque web app can call this (the in-app assistant); 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": "getWorkspaceUsageThisPeriod"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceIdYesWorkspace identifier. Must be the caller's current workspace.

Output Schema

NameRequiredDescriptionDefault
bucketsYes
periodEndYesEnd of the billing period (when it renews).
periodStartYesStart of the billing period.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses concrete behavioral facts an agent cannot get from structured fields: other roles receive 403, API keys are refused, only the in-app assistant path works, and figures are usage amounts never money. It also warns that periodStart/periodEnd are the billing period, not the calendar month, which prevents a common misinterpretation.

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 definition is front-loaded with the scope, then the metric inventory, then constraints, so an agent can stop reading early. The first sentence is a long semicolon chain of bucket names, which is dense but every item is a real return field rather than filler.

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?

An output schema exists, so return structure need not be explained, and the remaining risk areas are covered: who may call it, how authentication must occur, what the period boundaries mean, and that values are usage not currency. Nothing material for correct invocation is missing for a single-parameter read tool.

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 the single workspaceId parameter is already documented as the caller's current workspace, which the description largely repeats. The one added clarification concerns the period boundaries, which are output fields rather than input parameters, so no real parameter meaning is added beyond the schema.

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 specific verb and resource ('Usage in the current billing period, per bucket') and enumerates the exact metrics returned (seconds of testing by type, AI tokens and their parts, SMS segments, calls), which is far more than the title conveys. It does not explicitly distinguish itself from sibling tools like getWorkspaceUsage or getUsageBySource, so an agent must infer the boundary from the 'current billing period' scoping.

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?

Explicit trigger is given: 'Use when: someone asks how much they have used this period.' Role and channel preconditions are also spelled out (owner or billing admin; web-app session only). It stops short of naming alternatives for adjacent questions such as usage by source or by calendar month.

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

All Nopaque TotalPath 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