Skip to main content
Glama

Strange moods

moods

Monitor active strange moods in Dwarf Fortress, tracking each moody dwarf's mood type, workshop status, countdown, and demanded materials against fort stock to warn early when supplies fall short.

Instructions

Any active strange mood (fey/secretive/possessed/macabre/fell) and its material countdown. For each moody dwarf: the mood type, the driving skill, the workshop claimed (or that none is yet, via workshop_status: unclaimed/gathering/working), the raw mood countdown, and every demanded material cross-referenced against fort stock — needed, gathered so far, and how many the fort actually has (have). The early warning is "demands bones, fort has zero": it reports the demand vs. the stock, not what to go collect. Returns {"active":[]} when no strange mood is in progress (the common case), and {"error":"no fort loaded"} if no fort is active.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

No annotations are present, so the description carries full burden. It discloses return value structure, edge cases (empty active, error), and clarifies the distinction between demand and stock ('it reports the demand vs. the stock, not what to go collect'). This adds meaningful behavioral context beyond a simple listing tool.

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 moderately long but each sentence adds value: the first gives the core purpose, the second details output fields, the third explains a use case, and the fourth covers edge cases. It's structured clearly with a colon, but could be slightly tighter.

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?

With no output schema, the description fully specifies return values including structure, statuses, and error cases. It addresses the common case and error condition, making it complete for a read-only status 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?

There are zero parameters, and the schema coverage is 100%, so a baseline of 4 is appropriate. The description does not need to explain parameter semantics because there are none.

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 identifies the tool's scope ('Any active strange mood ... and its material countdown') and enumerates all mood types. It also differentiates from sibling tools by focusing exclusively on strange moods, a unique concern not addressed by nearby tools like fort_health or jobs_and_labor.

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 implies monitoring use through the 'early warning' phrase but never explicitly states when to use this over alternatives. It doesn't mention exclusions or alternative tools, though the uniqueness of the subject matter reduces the need.

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