Skip to main content
Glama

Stockpiles

stockpiles

Retrieve the fort's hauling/logistics picture: per-stockpile details (bounds, size, categories, links), unstored item backlog, and rotten items outside stockpiles.

Instructions

The fort's hauling/logistics picture: every stockpile as a fact sheet, plus fort-wide backlog signals stockpiles alone don't surface. piles[] is one row per stockpile building: id, exact bounds (x1/y1/x2/y2/z — the bounding box; an irregularly-shaped pile's real footprint can be smaller, see size), size (the pile's real tile count — for an irregular pile this reads its room.extents occupancy map rather than the bounding box, so holes/excluded tiles are correctly excluded), categories[] (which of the 17 top-level stockpile groups this pile accepts — animals/food/furniture/corpses/refuse/stone/ammo/coins/bars_blocks/gems/finished_goods/leather/cloth/wood/weapons/armor/sheet; note Ore has no flag of its own in DF's own stockpile_group_set — it rides under stone — and Misc (organic/inorganic) is a refuse sub-filter, not a top-level category, so neither appears in this list), barrels_allowed/bins_allowed (the pile's max_barrels/max_bins > 0 — DF stores 0 there specifically to mean "no containers of this kind," not "unlimited"), max_wheelbarrows (raw count; 0 here means no wheelbarrow is assigned so DF queues one haul job per item, NOT "wheelbarrows disallowed" — this one has no allowed/disallowed reading, unlike barrels/bins), links_only (DF's own "take from links only" toggle), give_to[]/take_from[] (ids of stockpiles this pile explicitly feeds into / pulls from via the g/q-t hauling-route UI, each capped at 50 with its own _truncated flag), item_count (exact count of non-rotten/non-dump/non-forbidden/non-construction/non-trader items physically sitting on the pile's tiles right now — via each item's resolved position, so items inside a bin or barrel parked on the pile count too — regardless of whether the pile's own categories[] actually accept that item, since this is a positional fact, not a settings-compliance check), and occupied_tiles (how many of the pile's size tiles have at least one qualifying item on them right now — a directly-counted fact, bounded [0, size], NOT a percentage or a capacity estimate: an earlier draft derived a fullness_pct from a placeholder items-per-tile constant that produced numbers with no real relationship to DF's actual per-tile capacity (which varies by item size and container packing — a barrel-heavy tile can hold far more than one item) and was dropped as a fabricated fact; occupied_tiles/size is a defensible coverage ratio if you want one, but it is spatial coverage, not capacity headroom). Fort-wide: unstored_backlog[] groups loose items (on the ground, not rotten/dump/forbidden/under-construction/trader-owned, and not sitting on ANY stockpile's tiles) by their raw DF item type token, with unstored_backlog_item_count as the grand total and a 150-distinct-type cap; this is the hauling backlog the issue asks for. rotting_outside_stockpiles is the same idea for the ROTTEN subset specifically (food/organic matter that has already decayed while lying outside any stockpile, i.e. hauling arrived too late) — {count, by_type[], by_type_truncated}. dump_flagged_count is an exact, unfiltered count of every item currently designated for dumping, wherever it sits. Returns {"error":"no fort loaded"} if no fort is active.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/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 so thoroughly. It discloses nuanced behaviors: bounding-box vs. real footprint, the exact meaning of barrels_allowed/max_bins (0 means no containers, not unlimited), the distinct reading of max_wheelbarrows, category omissions, item_count being positional and including container contents, occupied_tiles being a direct count not a percentage, and the error response. It even documents a discarded draft field as fabricated, demonstrating exceptional transparency.

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 description is front-loaded with a clear summary and then systematically details each returned field in a logical order (piles[] fields, then fort-wide fields). It is long, but most sentences convey essential caveats or exact semantics. Some historical notes, like the dropped draft's placeholder constant, are slightly extraneous but still support transparency, so it earns a 4 rather than a 5.

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?

The tool has no output schema, so the description must explain the full return shape, and it does: every field is named with its type, meaning, and edge cases, plus the error condition. Fort-wide summaries, truncation flags, and exact counting rules are all covered, making the description self-sufficient for an agent to understand what the tool returns.

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?

The tool has zero parameters and the schema coverage is vacuously 100%, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4, and there is no additional parameter behavior to add.

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 clearly defines the tool as returning 'the fort's hauling/logistics picture' with per-stockpile fact sheets plus fort-wide backlog data, which are distinct from what stockpile settings alone provide. It specifies exact fields and explicitly addresses a stated need ('the hauling backlog the issue asks for'), giving it a precise scope beyond the mere title.

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 implies when to use the tool: to inspect stockpile configurations and hauling backlog, especially loose-item backlog, rotting items outside stockpiles, and dump-flagged counts. It does not explicitly name sibling alternatives like hauling_routes or stocks, but it provides clear context for its purpose and notes what it uniquely surfaces ('signals stockpiles alone don't surface').

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexanderolvera/dfhack-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server