Skip to main content
Glama

Golemreach

by io.github.aniripsaretro-max

Talk to an NPC

golemreach_talk

Say something to a non-player character. NPCs take free-form English — they are the one part of this world built for language rather than around it — so "hello", "what do you sell?", "where can I hunt?" and "do you have anything for a level 3 knight" all work.

THIS IS NOT FLAVOUR. Talking is how you find out where anything is and how you get work, and there is no other way to do either. The two topics that matter:

  • ASK "where can I hunt?" (or say "hunt", "monsters", "danger") and ANY npc names somewhere suited to your level and puts it in your knowledge as a lead. A lead is a name and a direction, never coordinates — go and find the place, and arriving turns it into a real destination. Ask again after you have found it and they will point you somewhere new.

  • ASK about "task" (or "quest", "job", "work") and they offer you one. ASKING IS ACCEPTING — there is no separate yes. Kills count on their own from that moment; fetch objectives just check your backpack. Come back to THE SAME npc and ask about "task" again to hand it in; they will tell you what is still outstanding and its exact counter if you are early. Check progress any time with golemreach_where.

Ask about "trade" to make a merchant list its stock with prices; then buy with golemreach_trade. NPCs never dead-end: if one cannot understand you it tells you what it does know about.

Get npcId from the CREATURES list in a look (ids like "n3"), or use the content id from golemreach_where (ids like "general_store"). Both are accepted.

RETURNS: what the NPC said, plus their stock list when the topic was trade.

COMMON FAILURE: "out_of_range" — you must be within 3 tiles to be heard. Walk closer with golemreach_move first; the npc's exact tile is in the CREATURES list of a look.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesWhat you say. Plain English.
npcIdYesThe NPC, either a live creature id like "n3" or a content id like "general_store".

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it fully delivers. It discloses the accept-on-ask behavior, kill/fetch objective handling, progress counter details, three-tile out_of_range failure, accepted NPC id formats, and the return content (NPC speech plus stock when trading). This is far beyond a generic 'talk to NPC' description.

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 text is long but well-structured with bolded lead-ins, bullet lists, and dedicated RETURNS/COMMON FAILURE sections, so important information is findable. A few flavor phrases ('built for language rather than around it') and repeated examples add a bit of length, but the content is dense and mostly non-redundant.

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?

Given there is no output schema and no annotations, the description covers the full call cycle: how to get the target ID, what to say for each major intent, what happens in the game world, what the tool returns, and how to recover from the main error. An agent has enough context to invoke it successfully in the surrounding toolset.

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 schema already documents both parameters; the description adds practical value on top by giving example utterances, acceptable topic keywords, and two sources for npcId ('n3' or 'general_store'). It thereby explains how to obtain valid values, not just their types.

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 a specific verb and resource: 'Say something to a non-player character.' It makes the tool's unique role explicit by stating talking is the only way to find locations and get work, and it distinguishes adjacent actions such as golemreach_trade and golemreach_where. This leaves no ambiguity about what the tool is for.

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 and names alternative tools: ask 'trade' to list stock then buy with golemreach_trade, ask 'task' to accept/complete quests, use golemreach_where to check progress, and use golemreach_move when 'out_of_range'. It also explains consequences like asking being acceptance and returning to the same NPC to hand in, so an agent can choose correctly and act on the result.

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