Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

forecast_material_consumption

Read-only

Estimate when a material will run out from current stock and historical consumption, showing remaining days and urgency level (ok/low/critical) to plan restocking.

Instructions

Forecast when a material type will run out.

        Combines current stock with historical consumption rate to
        estimate remaining days and urgency level (ok/low/critical).

        Args:
            material_type: Material type to forecast (e.g. ``"PLA"``).
            days_ahead: Days of history for rate estimation (default 30).

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": {
      "material_type": "<material_type>"
    },
    "name": "forecast_material_consumption"
  }
}

Input Schema

NameRequiredDescriptionDefault
days_aheadNoDays of history for rate estimation (default 30). Default: 30.
material_typeYesMaterial type to forecast (e.g. ``"PLA"``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / days_ahead / description
      Previous value: -"Default: 30."New value: +"Days of history for rate estimation (default 30). Default: 30."
    • addedInput schema / properties / material_type / description
      Added value: +"Material type to forecast (e.g. ``\"PLA\"``)."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / days_ahead / default
      Removed value: -30
    • addedInput schema / properties / days_ahead / description
      Added value: +"Default: 30."
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningfully beyond them by disclosing the return semantics — estimated remaining days plus an urgency classification (ok/low/critical) — which is valuable since no output schema exists. It does not mention failure behavior for materials with no consumption history, which is the main remaining gap.

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?

The purpose and behavior are front-loaded in two tight sentences, which is good structure. The trailing Args block duplicates the schema and adds length without adding information, though it is short enough not to obscure the main point.

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 a simple two-parameter read-only forecasting tool with full annotation coverage and no output schema, the definition supplies enough to call it correctly and to interpret the result (days remaining plus urgency tier). The missing piece is whether the forecast degrades gracefully when there is insufficient history to compute a rate.

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 coverage is 100%, so both parameters are already documented, and the Args block largely restates the schema text verbatim. The one useful clarification is that days_ahead is a look-back window for rate estimation rather than a look-ahead horizon, which disambiguates an otherwise misleading name. That is a marginal gain over the schema, so the baseline 3 is right.

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 opening line names a specific verb and resource ('Forecast when a material type will run out') and the second sentence explains the mechanism (stock + historical rate). It is clear on its own, but it never distinguishes itself from adjacent siblings such as check_material_sufficiency, get_material_consumption_history, or get_restock_suggestions.

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 only implied: an agent can infer you call this when you want a depletion horizon for a material. There is no explicit 'use this instead of X when Y' routing, which matters here because the sibling list contains several overlapping material-sufficiency and consumption-history tools.

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

Deploy Server

Other Tools