Skip to main content
Glama
Sign In

LastPing

by dev.lastping
OverviewDiscussionsAdmin

Get agent model usage

get_agent_usage
Read-onlyIdempotent

Requires the read scope or higher. Model usage, one row per model per UTC day: tokens_in (cache reads included, so tokens_cache_read is not added to it), tokens_out, tokens_cache_read, tokens_cache_write, cost_usd (decimal text) and cost_source: client (the tool reported its cost), estimated (LastPing priced tokens at API list prices), mixed (a traced day holds both) or empty (unknown). origin is traces or metrics; a day and model can have one of each, never summed. With id, one agent's usage; without, the project's, traces only, plus by_agent (costliest first). Both carry by_project: per project (the folder that holds a Claude Code session's git repository, else its own folder) its runs, tokens and cost from traced runs only (project_scope traces_only). by_project sums each run's traced totals, while one agent's days prefer a Claude Code metrics export's reported cost, so the two need not match. With project, days become one row per UTC day with model and provider empty; project narrows days and by_project, not by_agent. untrusted_fields names the data fields LastPing did not write (job output, exporter data or user-supplied names).

Input Schema

NameRequiredDescriptionDefault
idNoAgent UUID or slug (from list_agents). Omitted: every agent in the project.
rangeNoTime window: 24h, 7d (the default) or 30d. It covers every UTC day that overlaps it, so 24h spans two days.
projectNoOnly usage from traced runs of this project; metrics-only usage has no project and is left out. days then hold one row per UTC day with model and provider empty (a run's totals are not split by model); by_agent is not narrowed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"Agent UUID or slug (from list_agents). Omit for every agent in the project."New value: +"Agent UUID or slug (from list_agents). Omitted: every agent in the project."
  2. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Only usage from traced runs of this project; metrics-only usage has no project and is left out. days then hold one row per UTC day with model and provider empty (a run's totals are not split by model); by_agent is not narrowed.",
+  "type": "string"
+}
  3. Added

TDQS

A3.9/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the required auth scope, the trace-vs-metrics origin split that is 'never summed', cost_source values (client/estimated/mixed/empty), and why by_project and per-agent days 'need not match'. It even flags untrusted_fields written by job output or user-supplied names — substantial behavioral context an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every clause carries real information, but the description is one undifferentiated wall of text with no line breaks or grouping, mixing scope requirements, column definitions, origin semantics and caveats in a single run-on. Front-loading is weak — the highest-value summary is buried behind the scope requirement.

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 no output schema, the description carries the full burden of explaining the return shape, and it does so thoroughly: per-day/per-model row layout, token accounting rules (cache reads included in tokens_in), cost_source semantics, by_agent ordering, and by_project behavior. Nothing essential for correct interpretation of the call is missing.

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 three parameters (id, range, project) are already documented, and the description largely restates them ('project narrows days and by_project, not by_agent' matches the schema text). The added value here is mostly about return-row shape rather than parameter meaning, so the 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 the resource (model usage rows per model per UTC day) and enumerates the returned fields, which separates it from metadata siblings like get_agent and from run-oriented tools like get_run_history. It lacks a clean opening summary sentence ('retrieve per-model token/cost usage for an agent or project'), so the purpose has to be reconstructed from dense detail rather than read off the first line.

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 gives a prerequisite ('Requires the read scope or higher') and explains the two operating modes (with id = one agent, without id = project, traces only), which implies when each call shape applies. But it never names an alternative tool or an explicit when-not-to-use condition, so routing guidance is inferred rather than stated.

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

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