Game Stats AI

attribute_histogram

Read-only

Show the distribution of one numeric attribute as equal-width buckets between its live minimum and maximum, each with how many records fall in it (a value equal to a bucket's upper bound counts in the next bucket, except the last). Use it for "how are ... distributed" or spread questions that a single average hides. source is Match, MatchPlayer, MatchEvent, Player, or Event; attribute_name must be a numeric attribute (data_type integer or float) at that level from list_attribute_types (for Event, also pass event_name_id). Optional filters: version_id, occurred_after, occurred_before (ISO 8601), except on Player.

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": {
      "source": "<source>",
      "attribute_name": "<attribute_name>"
    },
    "name": "attribute_histogram"
  }
}

Input Schema

Name	Required	Description
`source`	Yes	What the numeric attribute lives on.
`version_id`	No	Only include data from this game version.
`bucket_count`	No	How many buckets (default 10, max 20).
`event_name_id`	No	Required when source is Event: the event name from list_event_names.
`attribute_name`	Yes	The numeric attribute to bucket (from list_attribute_types at this level).
`occurred_after`	No	Only include data at or after this time (ISO 8601 date or date-time).
`occurred_before`	No	Only include data at or before this time (ISO 8601 date or date-time).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, non-destructive, open-world behavior, so the bar is lower, and the description still adds real computation semantics: buckets span the live min/max, boundary values fall into the next bucket except the last, and default bucket count is 10. It does not discuss response shape or ordering, but it discloses the non-obvious bucketing rule that would otherwise cause misreads.

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?

It is front-loaded with the core operation and its boundary rule, then moves to source/attribute constraints and optional filters; nearly every clause carries information. The single dense paragraph with nested parentheses makes the filter-exception clause easy to skim past, so it is not maximally clean.

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?

For a 7-parameter read tool with no output schema, the description covers the operation, the bucket semantics, the result content (counts per bucket), the source enum, the numeric-attribute precondition, and all optional filters including where they are invalid. An agent can call this correctly and interpret the result without further discovery.

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?

Schema coverage is 100%, so 3 is the baseline, and the description earns a step up by adding cross-parameter meaning: attribute_name must be numeric at that source level and drawn from list_attribute_types, event_name_id is conditional on source=Event, and the time/version filters are unavailable on Player. Those conditional relationships are not inferable from the flat property list alone.

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 states a precise verb and artifact: it shows the distribution of one numeric attribute as equal-width buckets between the live min and max, with per-bucket counts. That bucket-level framing plus the 'spread questions that a single average hides' phrasing separates it clearly from average/group-by siblings without needing to name them.

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?

It gives an explicit trigger ("how are ... distributed" or spread questions) and hard prerequisites: attribute_name must come from list_attribute_types and be integer/float, and Event requires event_name_id. It also carves out a usage exclusion (version/time filters do not apply to Player). What it lacks is an explicit named alternative such as aggregate_attribute for single-value summaries.

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?