Skip to main content
Glama

Golemreach

by io.github.aniripsaretro-max
OverviewDiscussionsAdmin

Use, equip or pick up an item

golemreach_use

Pass the sessionId returned by golemreach_connect with EVERY tool call, including after reconnecting. Keep it private: it grants control of your character. If you have no sessionId yet, call golemreach_connect once.

Everything you do with objects. The mode decides what happens:

  • "loot" (the default when you give no item) — pick up everything on your tile and the eight around it. THIS IS HOW YOU COLLECT LOOT. A corpse lies on the tile where the monster died, which is usually NOT the tile you are standing on, and this mode handles that for you.

  • "use" (the default when you do give an item) — drink a potion, eat food, or apply an item to a target. Drinking a health potion is how a knight heals, since knights cannot cast healing magic. EATING IS NOT OPTIONAL: food restores no health at all, but nothing regenerates while you are hungry — not health, not mana, not soul. Eat, or you never heal. One loaf of bread buys about four minutes of fed time and the stomach holds twenty minutes at most, so carry several and eat again when the status line says HUNGRY.

  • "equip" — put a weapon, shield or piece of armour on. The slot is inferred from the item.

  • "unequip" — take whatever is in a slot off; pass the slot name as item.

  • "drop" — put an item on the ground, to free capacity.

Item ids are readable slugs like "health_potion", "bread" or "short_sword"; get them from golemreach_inventory or the resource golemreach://items.

RETURNS: what happened and the world afterwards.

COMMON FAILURES: "no_such_item" means you are not carrying it — check golemreach_inventory for the exact id. "not_found" from a loot means the corpse is more than one tile away, so move onto it first. "not_enough_capacity" means you are carrying too much weight; sell or drop something.

A NOTE ON CORPSES: you loot what is INSIDE a corpse; you can never carry the corpse itself, and the same goes for crates and boulders. A look marks those "[cannot be picked up]". Corpses also rot — "[fresh]" is a kill somebody may still be coming back for, "[rotting]" is a picked-over husk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNoItem id such as "health_potion", or an equipment slot name when unequipping. Omit to loot everything nearby.
modeNoWhat to do. Defaults to "loot" when no item is given, "use" otherwise.
countNoHow many, for dropping part of a stack.
minValueNoWhen looting, skip items worth less than this many gold, so you stop hauling worthless trophies.
targetIdNoCreature to use the item on, for items that are applied to something.
sessionIdNoPass the sessionId returned by golemreach_connect with EVERY tool call, including after reconnecting. Keep it private: it grants control of your character. If you have no sessionId yet, call golemreach_connect once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / sessionId
      Added value: +{
+  "description": "Pass the sessionId returned by golemreach_connect with EVERY tool call, including after reconnecting. Keep it private: it grants control of your character. If you have no sessionId yet, call golemreach_connect once.",
+  "pattern": "^gs_[A-Za-z0-9_-]{43}$",
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
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 that sessionId grants character control, that loot mode scans a 3x3 area, that corpses rot and cannot be carried, and it enumerates common failure modes with their remediation. It also clarifies that eating restores no health but prevents all regeneration.

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 long but well-structured with mode definitions, return info, common failures, and corpse notes. It is front-loaded with the critical sessionId security warning. A small deduction for repeating the sessionId instruction verbatim in the input schema and for some slightly verbose explanatory passages, though most sentences convey unique operational knowledge.

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?

A six-parameter tool with no output schema is fully covered: it explains return values, failure strings, parameter defaults, edge cases around corpses and capacity, and provides examples of item ids. The agent has enough information to invoke this tool correctly in combat, looting, eating, and inventory management contexts.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial semantic value: item id examples, the default behavior of each mode, how equipment slots are inferred, the intent of minValue, and the interplay between item and mode. This goes meaningfully beyond the bare schema descriptions.

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 states a specific verb-resource scope: 'Everything you do with objects,' and enumerates five concrete modes (loot, use, equip, unequip, drop). It clearly distinguishes itself from siblings like golemreach_attack, golemreach_cast, and golemreach_move by defining object interaction as its domain.

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?

Provides explicit when-to-use guidance for every mode, including default mode selection based on whether an item is supplied, and calls out the prerequisite of golemreach_connect. It also gives contextual decision rules such as how knights heal, that eating is mandatory for regeneration, and that loot is collected with the "loot" mode because corpses are often not on the current tile.

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

All Golemreach toolsInspect
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