Game Stats AI

get_session_report

Read-only

Show a session report

Sessions come from the report's events, as set by session_tracking. With duration, each event_name event is one session and duration_attribute_name holds its length in seconds. With start_and_end, an end_event_name event closes a session when the same player's previous start or end event was an event_name event; a start without an end is not counted. A session counts on the UTC day it starts, and sessions longer than 24 hours or without a positive length are left out. daily has one entry for each finished UTC day from the first activity in the range, with sessions, the average session length in minutes, and sessions and playtime in minutes per active player. activity sets what makes a player active on a day: kinds lists which of matches, progression_events, and events count, and event_names limits events to those event names (empty means every event counts). A player is also active on any day they start a session. length_ranges counts the sessions in those days by length, starting at from_minutes. averages has the average daily sessions, and the session length, sessions per player, and playtime per player over all those days, weighted by sessions and active player-days. Without date filters, the report covers the last 90 days.

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": {
      "id": "<id>"
    },
    "name": "get_session_report"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The report ID.
`occurred_after`	No	Only include the last N days. Allowed values: 1, 7, 30. Takes precedence over the start of `occurred_between`.
`occurred_between`	No	Two ISO dates (from, to) that limit the days to that range. Leave either blank for an open range.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare readOnly/non-destructive, so the bar is lower, and the description still adds real behavioral context: the 90-day default window, UTC-day bucketing, exclusion of sessions over 24 hours or with non-positive length, and uncounted start-without-end sessions. What it omits is anything about cost, size, or return shape, which keeps it from a 5.

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?

The content is dense and mostly earns its place, and the default-range caveat is sensibly placed at the end. However it is delivered as one unbroken ~200-word paragraph with no breaks or bullets, making the several distinct report sections hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only report tool with a fully documented 3-parameter schema and no output schema, the description covers the report's semantics well. It stops short of explaining how to discover a valid `id` or what structure the returned sections take, which an agent still needs.

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 both `occurred_after` and `occurred_between` are already documented in the schema, and the description never refers to either by name. It instead explains report-configuration concepts (`session_tracking`, `activity`, `length_ranges`) that are not input parameters at all, which adds context but not parameter meaning.

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 opening sentence ('Show a session report') names a specific verb and resource and the body makes clear it returns a session-analytics report for a given report id. It is distinguishable from get_event_report or get_player_report by its session-focused framing, though it never explicitly contrasts itself with those siblings or with list_session_reports.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus the many sibling report tools, nor any note that the `id` must first be obtained from list_session_reports. The body explains what the report contains but never states the conditions that select this tool over get_event_report or get_retention_report.

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

All Game Stats AI 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.

Resources

Need Help?