pob_trade_catalog

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description's two behavioral claims (no trade API access, no build mutation) largely restate those. It does add the useful context that the data comes from the source PoB rather than a live service, but says nothing about entry volume, freshness, or the shape of results.

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?

Two compact sentences with zero filler, and the localization/read-only framing is front-loaded. It is efficient, though the extreme brevity is part of why the required parameter goes unexplained.

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?

With one required parameter and no output schema, the description needs to explain both what to pass and what comes back; it explains neither. For a catalog lookup whose whole value is the returned mod/base/currency set, an agent cannot predict the response shape or valid inputs from this text alone.

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?

Schema description coverage is 0% for the single required parameter 'slot', so the description must carry the load — and it says nothing about it. There is no indication of valid slot values (e.g. Helmet, Ring, Weapon), expected casing, or whether the string is a slot name versus an item base, which is the single most likely cause of a failed call.

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 names a specific resource — a local catalog of mods, compatible bases, and currencies sourced from the local PoB data — and implicitly distinguishes it from the sibling pob_trade_search by stating it does not hit the trade API. It falls short of a 5 because it never frames the tool as a lookup action over 'slot', leaving the returned object slightly underspecified.

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?

Usage is only implied: the note that it does not contact the trade API and does not modify the build hints that this is the offline/local option, which is useful routing signal. But there is no explicit 'use this when...' statement, no mention of pob_trade_search as the alternative for live prices, and no prerequisite or ordering guidance.

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