Skip to main content
Glama
Sign In

StoreFast

by io.github.LegendarySpy
OverviewDiscussionsAdmin

List crashes and hangs

list_crashes
Read-only

The top crashes and hangs Windows reported for one version of an app (the version live in the Store unless you pass one), over a range (7d, 30d, 90d or all), next to the version before it. Each failure has a failureHash for get_crash, its name (problem class, exception code, module and function), type (crash, hang, memory or jse), events, devices (unique devices per day, added up), first and last day seen, its events in the previous version, and isNew when no older version reported it. Also per-day event counts for both versions. Counts come from the nightly sync and lag a day or two.

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": {
      "appId": "<appId>"
    },
    "name": "list_crashes"
  }
}

Input Schema

NameRequiredDescriptionDefault
appIdYesThe app id from list_apps.
rangeNo7d, 30d, 90d or all. Defaults to 30d.30d
versionNoA package version like 1.4.0.0. Defaults to the version live in the Store.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive, and the description adds genuinely useful behavior: counts come from a nightly sync and lag a day or two, devices are summed unique-per-day, and isNew means no older version reported it. This is real context beyond the annotations, though return shape details are only partially covered.

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 core purpose and scope, then enumerates returned fields. It is dense and long but nearly every clause carries information; minor tightening possible in the field enumeration.

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?

With no output schema, the description fully enumerates the returned fields (failureHash, name, type, events, devices, first/last day, previous-version events, isNew, per-day counts) and notes data freshness, so an agent knows exactly what it gets.

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 the baseline is 3, but the description adds meaning: version defaults to the Store-live version and range accepts 7d/30d/90d/all. It reinforces rather than merely repeats 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?

States a specific verb and resource (list crashes and hangs) plus precise scope: one app version, a date range, compared against the prior version. It clearly distinguishes itself from get_crash by noting each failure carries a failureHash for that sibling.

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?

Explains the default version (the one live in the Store) and the range options, and implicitly routes per-failure detail to get_crash via failureHash. It does not explicitly state when not to use this tool, but the context is clear.

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

All StoreFast toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources