Skip to main content
Glama

Hauling routes

hauling_routes

Inspect the fort's minecart hauling network: minecart routes, each stop's stockpile links, departure conditions, and assigned vehicles.

Instructions

The fort's minecart hauling infrastructure: routes, each route's stops, and the vehicle (minecart) objects fort-wide. routes[] is {id, name?, stops[], vehicles[]}. Each stop is {id, name?, pos:{x,y,z}, stockpiles[], conditions[], parked_vehicle_id?} — stockpiles[] is {building_id, take, give} for every stockpile linked to that stop (take = the cart picks items up from that stockpile, give = the cart drops items into it; a link can be both). conditions[] is that stop's departure conditions — {direction, mode, timeout, load_percent, at_most, desired} — mode is how a dwarf moves the cart onward (Push/Ride/Guide), direction is the initial departure heading, and at_most/desired describe the load_percent threshold that must be met before the cart leaves. parked_vehicle_id is the vehicle currently sitting at that exact stop right now, absent if none is. A route's own vehicles[] ({vehicle_id, current_stop_id?}) is the set of vehicles assigned to run that route — DF assigns vehicles at the route level, not per stop; current_stop_id is which of that route's own stops the vehicle currently occupies, absent if in transit or unknown. The top-level vehicles[] is every hauling vehicle fort-wide (minecarts and other cart- type haulers; battering rams excluded) as {vehicle_id, item_id, backing_item_exists, route_id?, on_track} — backing_item_exists is whether the vehicle's backing item still exists (a vehicle can persist as a stale reference after its physical cart is destroyed or stolen, regardless of whether it is assigned to a route); route_id is absent for a vehicle not currently assigned to any route. Both routes[] (capped 100, see routes_total/routes_truncated) and the top-level vehicles[] (capped 200, see vehicles_total/vehicles_truncated) are sorted by id. 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 fully discloses behavioral traits: returns an error if no fort is loaded, caps on routes and vehicles with truncation flags, sorting by id, and details about stale vehicle references. It covers edge cases and data semantics comprehensively.

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 lengthy but densely informative. Every sentence contributes to explaining the complex data structure. It is front-loaded with the core concept and then details nested objects. While a bit wordy, the detail is necessary for such a complex topic.

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?

Given the tool has no input schema, no output schema, and no annotations, the description provides a complete picture: the overall structure of routes, stops, vehicles, nested properties, thresholds, and error conditions. It is fully self-contained for an agent to invoke and interpret results.

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, so the baseline per rubric is 4. The description provides no parameter-level details because there are none to describe, but it thoroughly explains the return value structure.

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 states the tool's purpose: to retrieve the fort's minecart hauling infrastructure, including routes, stops, and vehicles. It distinguishes itself from sibling tools by focusing specifically on hauling routes and vehicle objects, not general stockpiles or stocks.

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?

The description explains what data is returned and when an error occurs, but it does not explicitly compare itself to alternatives or state when to use this tool versus siblings like 'stockpiles' or 'work_order_list'. Usage is implied rather than explicit.

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