itemsFetch Guild Wars 2 item details by comma-separated IDs or by page; returns item name, type, rarity, level, vendor value, icon, and game flags.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| lang | No | ||
| page | No | ||
| page_size | No |
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items returned. | |
| items | No | List of Guild Wars 2 items |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, so the agent knows it's a safe read operation. The description adds context by listing returned fields (name, type, rarity, etc.), which is useful but does not disclose additional behaviors like rate limits or pagination defaults.
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 a single, well-structured sentence with a clear verb and resource. It is front-loaded and avoids unnecessary words, though it could be slightly improved by separating the two modes for readability.
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?
The description lists returned fields, which is helpful given the output schema exists. However, it omits details like default page size, language usage, or error handling. For a tool with 4 optional parameters and no parameter descriptions, more context is needed.
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?
With 0% schema description coverage, the description must compensate. It mentions comma-separated IDs and page modes, but does not explicitly map to the 'ids', 'page', 'page_size', or 'lang' parameters. It does not clarify the format or constraints for these parameters, leaving significant gaps.
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 clearly states the verb 'Fetch', the resource 'Guild Wars 2 item details', and specifies two distinct modes (by comma-separated IDs or by page). It also lists the returned fields, making it easy to differentiate from sibling tools like 'achievements' or 'currencies'.
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 implies two usage patterns (by IDs or by page) but does not provide explicit guidance on when to choose one over the other, nor does it mention when not to use this tool. No alternatives are cited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The set mixes two unrelated domains (Guild Wars 2 endpoints and a broad Pipeworx data-research suite), and within each there are near-duplicates: ask_pipeworx vs ask_pipeworx_beta are functionally identical, commerce_prices vs guild_wars_2_item_price vs commerce_listings overlap on Trading Post data, and ask_pipeworx/ask_pipeworx_grounded/deep_research all route questions to the same source catalog. An agent could easily select the wrong tool.
Names are all snake_case and readable, but there is no consistent pattern: some are bare nouns (achievements, currencies, quaggans, worlds, build), some are verb_noun (resolve_entity, validate_claim, generate_llms_txt), some are ask_* (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded), and some are compound names (polymarket_kalshi_spread, guild_wars_2_item_price). Minor deviations would be fine, but this is a genuine mix of conventions.
42 tools is far beyond the well-scoped range, and the majority are unrelated to the 'Guild Wars 2' server name (only ~11 tools are GW2 API endpoints; the rest are Pipeworx data-research/meta tools). This feels like two or three servers merged into one.
For a Guild Wars 2 server, the coverage is thin: it has items, prices, achievements, worlds, and WvW, but no recipes, guilds, characters, skills, maps, or PvE content. For the broader data-research domain implied by most tools, the surface is sprawling but still lacks depth in several areas. The result is a set that is neither complete for GW2 nor coherently scoped for anything else.