Skip to main content
Glama

Golemreach

by io.github.aniripsaretro-max

Walk somewhere

golemreach_move

Move your character. Two ways to use it:

  1. TRAVEL — pass x, y and z. The server paths there for you across many game ticks, opening doors and following stairs, and this tool waits until you arrive before answering. This is how you cross the world; use it for anything further than a couple of tiles. Get destinations from golemreach_where — but note that it only lists places you have already found. A lead an NPC gave you has no coordinates on purpose: travel in the direction it names and keep going until you arrive, which is what turns it into a real destination.

  2. STEP — pass direction ("n", "ne", "e", "se", "s", "sw", "w", "nw") to take exactly one step. Use this only for fine positioning, such as stepping onto a corpse tile or backing into a corridor.

RETURNS: where you ended up, plus the fresh world view there.

COMMON FAILURES. "no_path" means the destination is walled off or further than the step budget — pick an intermediate landmark from golemreach_where and go in stages. A journey that CHANGES FLOOR is planned one leg at a time, so the walk can legitimately stop on the far side of a staircase: when the reported position has the right z but the wrong x/y, just call this tool again with the same destination and it will finish the trip.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoDestination x. Give x, y and z together to travel.
yNoDestination y.
zNoDestination floor. 0 is ground level, -1 is the first cellar. Defaults to your current floor.
directionNoTake a single step this way instead of travelling. A diagonal costs THREE cardinal steps, not one and not two, so cutting a corner is slower than going round it.
stopDistanceNoStop this many tiles short of the destination. Use 1 to stand next to something rather than on it. Default 0.
avoidCreaturesNoRefuse to path through tiles a monster stands on. Default true; set false when monsters are blocking the only corridor.

TDQS

A5/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 behavioral burden and does so thoroughly. It discloses that the tool waits until arrival, auto-paths across ticks and through doors/stairs, returns the final position and fresh world view, may stop on the far side of stairs when changing floors, and even explains the diagonal stepping cost. This goes far beyond what the schema alone conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: two clearly labeled usage modes, a brief returns note, and a common-failures section. The structure front-loads the core decision (TRAVEL vs STEP) and then layers details, making it easy for an agent to scan and act.

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?

There is no output schema, so the description correctly explains what the tool returns: where the character ended up plus the fresh world view. It also covers edge cases like no_path, incremental multi-floor journeys, and repeated calls to finish a trip, making the tool fully self-contained for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning beyond the raw parameter docs: x/y/z must be given together to travel, direction chooses a single step, and stopDistance semantics are clarified. It also adds practical behavioral context such as avoidCreatures refusing monster-occupied tiles and the diagonal cardinal-step cost, which the schema descriptions do not fully express.

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 opens with the specific action 'Move your character' and immediately defines the two operating modes: TRAVEL (x/y/z coordinates) and STEP (direction). This makes the tool's purpose unambiguous and distinguishes it clearly from the movement-adjacent siblings like golemreach_wait and golemreach_where.

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 explicit when-to-use guidance: use TRAVEL for anything further than a couple of tiles, use STEP only for fine positioning, and consult golemreach_where for known destinations. It also covers the lead-following case, multi-floor pathing, and common failure recovery, so an agent knows exactly when and how to invoke this tool relative to alternatives.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool maps to a clearly distinct interaction: connect, observe, move, fight, cast, use, inventory, talk, trade, knowledge/quests, wait, and admin handoff. The only possible overlap is attack versus cast, but their descriptions separate a full automated fight from casting a single spell, so an agent can reliably choose between them.

Naming Consistency5/5

All 12 tools share the golemreach_ prefix and use lowercase snake_case names in a predictable command-like style. Most are verbs (attack, move, talk, trade, use, wait), and the few non-verbs (inventory, where) still follow the same pattern, so there is no naming convention clash.

Tool Count5/5

With 12 tools, the set is well within the ideal 3-15 range for a game-agent server. Each tool earns its place by covering a distinct part of the gameplay loop—connection, exploration, combat, magic, object use, economy, NPC interaction, and progression knowledge—with no obvious redundancy.

Completeness5/5

The set covers the full lifecycle of the intended game experience: joining the world, looking and inspecting, traveling, hunting, casting spells, using items, looting, trading, talking to NPCs, tracking quests/knowledge, waiting for regeneration/cooldowns, and transferring administrative control. There are no obvious dead ends; every action a player would need flows naturally into the next tool.

Resources