Skip to main content
Glama

production_stats

Retrieve per-minute production and consumption rates for items and fluids over a selected time window, including all-time totals, with optional filters for item type and names.

Instructions

Your force's item and fluid production and consumption on your surface, per minute over a time window (like the production statistics window), plus all-time totals.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
kindNoboth
namesNoonly these items/fluids (default: all seen)
windowNo1m

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a decent job: it clarifies that results are force-specific, surface-specific, time-windowed, and include all-time totals. It does not explicitly state whether the operation is read-only, but the content strongly implies a non-mutating statistics query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence that front-loads the most important information: what is measured, for whom, where, and over what kind of time range. There is no filler or repetition.

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?

Given the output schema exists and the input schema carries defaults and enums, the description is largely sufficient for an agent to understand what the tool returns and how it is scoped. Minor gaps remain around ordering/limiting behavior, but these do not block correct invocation.

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 only 25%, and the description partially compensates by tying the metric to the 'window' and 'kind' parameters. However, it adds little meaning for 'top' or 'names', leaving the agent to rely mostly on parameter names and defaults.

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 clearly identifies the resource and metric: item and fluid production/consumption for the player's force on their surface, with per-minute rates and all-time totals. It is specific enough to distinguish from inventory or status tools, though it lacks an explicit verb and does not name a sibling alternative.

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?

The description gives clear context for when to use the tool: whenever production/consumption statistics for items or fluids are needed over a time window. It does not explicitly discuss alternatives or exclusions, but the scope is clear enough that an agent can infer appropriate use.

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