Skip to main content
Glama

Golemreach

by io.github.aniripsaretro-max

Enter Golemreach

golemreach_connect

Join the game. This is always your first call. It registers an account, creates a character and walks it into the world in one step, then returns your first look at the world.

Call it again later only if you were disconnected; it remembers your token and character between runs, so a second call resumes the same character rather than making a new one (pass fresh:true if you really want a new account).

RETURNS: your character name, level and vocation, plus the standard world view — status line, ASCII map, creatures in sight, and any hints the server has for you.

COMMON FAILURE: "Could not reach the Golemreach server" means the game server is not running. Start it with node packages/server/dist/main.js --port 7171, or pass serverUrl if it listens elsewhere. The other one is a character name collision — names are unique across the whole server, so pass a different characterName.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
freshNoIgnore any remembered account and register a brand new one.
tokenNoAn existing account token, if you already have one.
vocationNoClass for a NEW character; ignored when resuming. knight = most health and melee damage, no real magic, the easy start. paladin = ranged, self-sufficient. sorcerer = huge damage, dies instantly. druid = healing and ice. Default knight, which is the forgiving choice for a first character.
agentNameNoLabel for your account and for spectators watching the world.
serverUrlNoBase URL of the game server, e.g. "http://localhost:7171". Defaults to GOLEMREACH_URL or http://localhost:7171.
characterIdNoAn existing character id on that account, e.g. "ch4".
characterNameNoName for a new character. Must be unique server-wide. Omit to get a generated one, or to resume an existing character.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and meets it: it covers account registration, character creation, world entry, idempotent resumption, token/character memory between runs, fresh:true override, return payload, and two common failure modes. There is no annotation contradiction.

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 front-loaded with the key directive, then uses labeled RETURNS and COMMON FAILURE sections so an agent can scan efficiently. Every section earns its place by addressing selection, resumption, expected output, or troubleshooting.

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 7-parameter setup tool with no output schema, the description is complete: it explains what the response contains, when a second call is appropriate, how to force a new account, and how to react to the most likely failures. The absence of an output schema is compensated by the explicit return description.

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. The description adds meaningful behavior beyond the schema: fresh:true means force a new account, characterName collisions are server-wide and require a different name, and serverUrl matters when the game server listens elsewhere. This lifts it above baseline, though the schema already handles individual parameter semantics well.

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?

Description opens with 'Join the game' and states it 'registers an account, creates a character and walks it into the world in one step, then returns your first look at the world.' This is a specific verb+resource that clearly distinguishes the connect/setup tool from the action-oriented siblings like golemreach_attack and golemreach_move.

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?

It explicitly says 'This is always your first call,' which tells the agent this must precede all siblings. It also gives the exact condition for calling again ('only if you were disconnected') and explains the resume/fresh:true choice. Common failure guidance further clarifies when to adjust serverUrl or characterName.

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