Skip to main content
Glama

tilt_report

Detect if a player performs worse after losses or later in a session by grouping games into sessions and reporting only differences larger than sampling noise.

Instructions

Does the player play worse after losses, or later in a session? Games are grouped into sessions (a pause longer than the gap starts a new one). Differences are reported only when they are larger than sampling noise.

Input Schema

NameRequiredDescriptionDefault
usernameYes
time_classNo
session_gap_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations at all, the description carries the full disclosure burden, and it does add real behavioral content: games are bucketed into sessions at pause boundaries, and differences are suppressed unless they exceed sampling noise (a significance filter). It says nothing, however, about required data availability, cost/runtime, what metrics are compared, or whether any state is mutated.

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?

Three short sentences, front-loaded with the analytical question, followed by the session definition and the significance caveat. No filler, though the opening interrogative form is slightly less actionable than an imperative verb phrase would be.

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 multi-parameter analytics report with no annotations, no output schema, and zero schema descriptions, the description covers the conceptual model well but leaves the agent guessing about return shape, metric definitions, and parameter value formats. Adequate to understand intent, insufficient to call confidently without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all three parameters. It only implicitly explains session_gap_minutes ('a pause longer than the gap starts a new one') and says nothing about username or time_class (e.g., allowed time-class values or default behavior), leaving most parameters undocumented in both schema and prose.

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 poses the exact analytical question the tool answers ('Does the player play worse after losses, or later in a session?'), which effectively communicates that this is a tilt/session-performance report. It is distinguishable from most siblings in spirit, though it never names or contrasts itself with adjacent tools like resilience_report or worst_moments, so the differentiation is implicit rather than stated.

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?

Usage is implied by the framing question — an agent can infer this is the tool for loss-streak/session-position effects — but there is no explicit when-to-use statement, no exclusions, and no routing to alternatives such as resilience_report. The session-grouping sentence provides context for how the analysis is scoped, which is partial guidance rather than a usage policy.

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