rust.wiki

When a base decays once the Tool Cupboard runs out, piece or layer by layer

calculate_decay

Read-onlyIdempotent

When a base decays once the Tool Cupboard runs out, piece or layer by layer. The decay page's maths (https://rust.wiki/calculators/decay): with no upkeep, an outside piece goes from full health to nothing in 1 h (twig), 3 h (wood), 5 h (stone), 8 h (sheet metal) or 12 h (armoured); inside pieces decay at a tenth of that. destroyed_in_hours counts from now (upkeep first). For layers, each layer behind the outer one decays at 10% until the one in front is gone, then at full speed. Vanilla server defaults.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calculate_decay"
  }
}

Input Schema

Name	Required	Description	Default
`grade`	No	Building grade: twig, wood, stone, metal, hqm.	stone
`inside`	No	True = the piece is inside the base (decays at 10% speed).
`layers`	No	Optional honeycomb: comma-separated grades from the outside in (max 6).
`health_pct`	No	The piece's health left, %.
`upkeep_hours`	No	Hours of upkeep left in the Tool Cupboard.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent safety profile, and the description goes further by disclosing the underlying decay model: full-health-to-zero times per grade, 10% inside speed, and layer-by-layer 10% until the front layer falls. The only unaddressed behavior is the shape of the response beyond destroyed_in_hours.

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?

Purpose and mode are front-loaded, then the maths and field semantics follow in a tight block. The wiki URL and 'Vanilla server defaults' are mildly expendable, but no sentence is filler.

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

Completeness3/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 carries the burden of explaining returns but only defines destroyed_in_hours; whether per-layer or per-piece results come back is unstated. For a 5-parameter calculator with layered logic, that leaves a meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description still adds real meaning: it explains how upkeep_hours interacts with destroyed_in_hours (countdown starts from now, upkeep consumed first) and how layers are ordered and decay sequentially, which the schema's 'comma-separated grades from the outside in' alone does not convey.

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 names a specific computation (decay timing after Tool Cupboard upkeep runs out) and its two modes (single piece vs. layered honeycomb), with concrete per-grade figures. It is clearly distinguishable from siblings like calculate_upkeep or calculate_base_cost.

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?

It establishes context (vanilla server defaults, decay counted from now with upkeep first) but never says when to pick this over calculate_upkeep or calculate_base_cost, and gives no exclusions or preconditions. Usage is implied by the scenario rather than stated.

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

All rust.wiki 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?