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

No annotations are provided, so the description carries the full burden. It discloses the return shape, that capacity is a real constraint that silently stops further looting, that observations will start warning about it, that the tool is free and has no cooldown, and that the sessionId grants control and must be kept private. This is substantial behavioral context.

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

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

The description is well-structured and front-loaded: session requirement first, then purpose, then use cases, then returns. It is somewhat verbose and repeats the sessionId security warning already present in the schema, but each section contributes useful context and the organization is easy to follow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 appropriately compensates by explicitly describing the return contents: equipped items by slot, backpack contents stacked by kind, gold, and used versus maximum capacity. It also explains why the capacity information matters behaviorally. For a simple one-parameter tool, this is complete.

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

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

The single parameter has 100% schema description coverage, including the security warning about the sessionId. The description repeats this guidance but adds no new parameter-level meaning beyond the schema. Baseline 3 is appropriate because the schema already does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List your equipment, your backpack, your gold and your carry capacity.' It clearly distinguishes this from siblings like golemreach_attack, golemreach_move, golemreach_trade, and golemreach_use, especially by noting that the square-bracket ids returned here are what use/trade expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete trigger conditions: use it before a shopping trip, when a loot attempt reports you are full, or when you need an exact item id for golemreach_use or golemreach_trade. It also tells the agent to call golemreach_connect first when no sessionId exists, which makes the routing between siblings explicit.

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