Game Stats AI

create_report

Create a new live report in the account. Confirm the configuration with the user before calling this: the report is visible to everyone on the account as soon as it is created. Most report types build their data asynchronously, so run_report may need a couple of minutes before it returns rows.

Per report type: attribute needs attribute_name + attribute_level; character_attribute needs character_attribute_names; event needs event_name_id + group_by_attribute; progression needs progression_type_id + from/to milestone type ids only. Metrics and filters reference attributes by name and level (use list_attribute_types); on event reports they always use the event's own attributes, so omit attribute_level there. Attributes that do not exist yet are created with the report and start with no data.

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": {
      "report_type": "<report_type>"
    },
    "name": "create_report"
  }
}

Input Schema

Name	Required	Description
`label`	No	Report name shown in the UI. Defaults to a generic name.
`filters`	No	Attribute filters the report offers. Not allowed on progression reports.
`metrics`	No	Columns to compute. Not allowed on progression reports (their metrics are fixed).
`threshold`	No	Optional minimum/maximum sample-size filter to hide low-sample rows.
`description`	No
`report_type`	Yes	The kind of report to create.
`event_name_id`	No	Event reports only: id from list_event_names.
`player_fields`	No	Player reports only: player attribute columns to display next to the player, in order.
`attribute_name`	No	Attribute reports only: the attribute to group by.
`attribute_level`	No	Attribute reports only: the level of attribute_name.
`character_fields`	No	Character reports only: extra character attribute columns to display.
`character_filters`	No	Character reports only: character attributes to filter rows by.
`group_by_attribute`	No	Event reports only: the event attribute each row groups by.
`default_recent_days`	No	Event reports only: default time window in days.
`progression_type_id`	No	Progression reports only: id from list_progression_types.
`character_attribute_names`	No	Character attribute reports only: names from list_character_attribute_names to group characters by.
`to_progression_milestone_type_id`	No	Progression reports only: the ending milestone type id.
`from_progression_milestone_type_id`	No	Progression reports only: the starting milestone type id.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing that the report is immediately visible to everyone on the account, that data builds asynchronously so run_report may be empty for minutes, and that missing attributes are silently created with the report and start empty. These are non-obvious side effects and timing characteristics an agent could not infer from readOnlyHint=false and destructiveHint=false.

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?

Front-loaded with the action and the confirmation warning, and every sentence carries information. The per-type block is a densely compressed run-on ('progression needs progression_type_id + from/to milestone type ids only') that takes effort to parse but wastes no words.

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

Completeness4/5

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

For an 18-parameter, nested mutation tool with no output schema, the definition covers workflow, per-type requirements, and side effects. The main gap is that it never says what comes back (presumably the new report id needed for run_report), which an agent must know since no output schema exists to tell it.

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?

With 94% schema coverage the baseline is 3, and the description adds genuine cross-parameter logic the schema cannot express: which fields each report_type requires, and that metrics/filters on event reports always use the event's own attributes so attribute_level must be omitted. It leaves less-structured parameters (label, description, threshold, player_fields) entirely to the schema.

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 opening sentence states a specific verb and resource with its scope: 'Create a new live report in the account.' The per-report-type requirements and the dependency on run_report make the tool's role in the workflow unambiguous against read-side siblings like get_event_report and list_reports.

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 pre-call condition ('Confirm the configuration with the user... visible to everyone') and names the discovery siblings to use for ids (list_attribute_types, list_event_names, list_progression_types, list_character_attribute_names). It stops short of saying when to create a report versus e.g. add_dashboard_card or when to prefer an existing report from list_reports.

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?