Skip to main content
Glama

Fort health

fort_health

Detects causes of FPS death in Dwarf Fortress by reporting simulation FPS, item counts, and unit population, so you can address clutter early.

Instructions

The fort's computational health as facts — FPS death is the true endgame boss, and nothing else reports it. fps/gfps are the engine's own currently calculated simulation/graphics frame rates (df.global.enabler.calculated_fps/calculated_gfps — the same numbers DF's own FPS counter shows), not an average or a history. items.total is the fort-wide item-object count (df.global.world.items.all, unfiltered by forbidden/dump/rotten/construction state — every item DF is tracking counts toward this, since object count, not usable stock, is what costs simulation time); items.stone/corpses/clothes break out the three clutter candidates the issue names (stone: BOULDER; corpses: CORPSE + CORPSEPIECE + REMAINS; clothes: the wearable slots ARMOR/SHOES/HELM/GLOVES/PANTS) — these are raw totals and will run higher than stocks' counts, which filter to usable/in-play items only; the two answer different questions (clutter vs usable stock) and are not duplicates. units.active/units.dead_on_map split df.global.world.units.active by isDead — active is every currently-simulated living unit (citizens, tame animals, wildlife, hostiles, visitors), dead_on_map is a dead unit whose body hasn't yet been cleaned up into a corpse item; both are fog-of-war filtered (mcp_unitVisibility), like every other unit-enumerating tool in this server, so an undiscovered cavern's unrevealed population is never counted here even though it still costs real simulation time — this tool intentionally undercounts true computational load rather than leak an unexplored area's population as an aggregate number. Stray/unassigned animal count is intentionally NOT duplicated here: call livestock_and_pastures and read its unassigned_count. 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 carries behavioral disclosure. It explains that fps/gfps are current calculated values (not averages), item counts include all object states, unit counts are fog-of-war filtered and intentionally undercount, dead_on_map is specific, and the tool returns an error if no fort is active. This is exceptionally transparent.

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 dense but every sentence provides necessary detail, and it front-loads the core purpose. It is a single long paragraph, which could be better structured, but it is not bloated or redundant.

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 no output schema, the description thoroughly explains all return fields (fps, gfps, items breakdowns, units splits) and even clarifies their meaning relative to other tools. It also covers edge cases (error, fog-of-war) and cross-references alternatives, making it fully complete for a zero-parameter tool.

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 an empty input schema, so parameter semantics are not applicable; baseline 4 applies. The description instead focuses on output field semantics, which adds value beyond the schema.

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 explicitly states the tool reports 'the fort's computational health as facts,' covering FPS, item counts, and unit counts. It differentiates itself from siblings by noting it's the only source for 'FPS death' and clarifying differences from stocks and livestock_and_pastures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it explains when to use this tool (for computational load, using raw item/unit counts) versus alternatives like stocks (for usable stock) and livestock_and_pastures (for unassigned_count). It also warns about fog-of-war undercounting and the error condition when no fort is loaded.

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