Skip to main content
Glama
itential

Itential MCP Server

Official
by itential

Get Agent Token Usage

get_agent_token_usage
Read-onlyIdempotent

Summarize token usage per agent from completed sessions, with optional filters for name and time range, and include failed sessions to capture all consumption.

Instructions

Aggregate agent session token usage grouped by agent name.

Fetches agent sessions and groups them by agent name, computing token consumption statistics (sum, average, min, max) for both input and output tokens per agent. Sessions with missing or null token values are still counted toward session_count but contribute 0 to sum, average, and min/max calculations. Sessions with no agent name are grouped under a None-keyed entry rather than dropped. Only COMPLETE sessions are included by default — see include_failed to also include FAILED sessions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_nameNoFilter to agent names containing this substring (case-insensitive)
started_afterNoISO 8601 timestamp — only include sessions started at or after this time
include_failedNoBy default only COMPLETE sessions count toward usage (finished, billable work). Set true to also include FAILED sessions, which can still have consumed real tokens. Non-terminal statuses (PENDING, RUNNING, PAUSED, ...) are always excluded either way, since their totals aren't final.
started_beforeNoISO 8601 timestamp — only include sessions started at or before this time

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesResponse model for the agent token usage aggregation endpoint. Wraps a list of AgentTokenUsageStats objects, one per distinct agent name (including a None-keyed entry for sessions with no agent name), sorted by total_tokens descending. Attributes: root: List of AgentTokenUsageStats objects with aggregated token usage metrics per agent.
Behavior5/5

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

The annotations already declare readOnlyHint and idempotentHint, but the description goes beyond by detailing how null token values are treated (counted in session_count but contribute 0 to statistics), that sessions without an agent name appear under a None key, and that only COMPLETE sessions are included by default. These edge cases are critical for an agent to correctly interpret results.

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

Conciseness5/5

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

Four tight sentences, each adding value: a crisp summary, the grouping/statistics logic, the null/None handling, and the status filter. There is no fluff or repetition of schema details.

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 an output schema, the description covers all essential behavioral aspects: aggregation variance, null handling, ungrouped sessions, and status filtering. This is complete for a moderate-complexity reporting tool; nothing needed 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?

All four parameters have full schema descriptions (100% coverage), which earns a baseline of 3. The description adds meaningful context beyond the schema by explaining that include_failed allows FAILED sessions 'which can still have consumed real tokens' and that non-terminal statuses are always excluded, giving the agent deeper understanding of parameter effects.

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?

The description opens with a decisive summary: 'Aggregate agent session token usage grouped by agent name.' This specifies the verb (aggregate), resource (agent session token usage), and grouping dimension, clearly distinguishing it from per-session tools like describe_session_token_usage or get_agent_session_token_usage.

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?

The description provides clear context on default behavior ('Only COMPLETE sessions are included by default') and points to include_failed for FAILED sessions. However, it never explicitly differentiates this tool from sibling tools with similar names, leaving when-to-use guidance implicit rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/itential/itential-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server