Skip to main content
Glama

Let time pass

golemreach_wait

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.

Stand still for a while and then report what changed. Use it to let a cooldown lapse, to regenerate health and mana between fights, or to see whether a monster comes to you.

This is the correct response to a "cooldown" rejection. Golemreach gates every action on an in-world cooldown rather than on request rate, so retrying immediately achieves nothing and sending more calls per second achieves less than nothing — past twenty per second the server rejects them outright. Waiting is not a wasted turn; it is the move.

TWO THINGS STOP REGENERATION DEAD, and waiting through either is pure wasted time:

  1. Being hungry. Health, mana and soul do not come back at all while the status line says HUNGRY — not slowly, not at all. Eat first (golemreach_use with item "bread"). Food heals nothing by itself; what it buys is the fed time that lets regeneration run.

  2. Standing on a P tile. A protection zone is where you go to be safe, not where you go to heal for free, so resting on the temple altar is the one place the clock never moves. Step outside first.

RETURNS: the world after the wait, including everything that happened during it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
secondsNoHow long to wait, in real seconds. Default 3, maximum 60.
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.
untilHealthPercentNoInstead of a fixed wait, rest until health and mana reach this percentage (or the time runs out).

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.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that waiting is useless while hungry or on a protection tile, explains the server's cooldown model, warns that over-20 calls-per-second get rejected, and states that the return value is the world after the wait including everything that happened.

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 sentence earns its place: it front-loads the critical sessionId requirement, then moves from general purpose to specific mechanics to return behavior. Bold warnings and bulleted blockers make the density scannable without losing precision.

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?

For a tool with optional parameters, no annotations, and no output schema, the description is fully self-sufficient. It covers authentication, when to wait versus act, conditions that invalidate waiting, server behavior, and the shape of the return value.

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 coverage is 100%, so the baseline is 3, but the description adds practical meaning beyond the schema. It clarifies that untilHealthPercent-style regeneration depends on being fed and not standing on a P tile, and it distinguishes between waiting for a cooldown versus waiting for regeneration, which helps the agent choose between seconds and untilHealthPercent.

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 is explicit about the action: "Stand still for a while and then report what changed," and names concrete purposes: letting a cooldown lapse, regenerating health/mana, observing monster movement. It distinguishes the tool from siblings by naming golemreach_connect and golemreach_use as the correct alternatives for missing sessionId and eating, respectively.

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 explicitly states when to use wait: "Use it to let a cooldown lapse, to regenerate health and mana between fights, or to see whether a monster comes to you." It also says it is "the correct response to a 'cooldown' rejection," advises "Eat first (golemreach_use with item 'bread')," and tells the agent to call golemreach_connect if no sessionId exists.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.