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

The annotations already flag destructiveHint=true and readOnlyHint=false; the description adds important context by delimiting the destructive scope to the server's local selection and explicitly stating that PoB files and remote profiles are not modified. This helps an agent understand exactly what state changes.

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?

Single sentence with no filler. The key scoping detail is front-loaded after the verb and directly addresses the operation's effect.

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?

For a zero-parameter tool with no output schema, this description covers the action, target, and non-effects. It is complete enough for an agent to invoke correctly without further context.

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 tool takes zero parameters, and the input schema is empty, so there are no parameter semantics for the description to clarify. Baseline 4 is appropriate.

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?

States a specific verb ('Remove') and a specific resource ('server's local active-build selection'), and contrasts itself with sibling mutation tools by clarifying that remote profiles and PoB files are untouched. This is sufficient for an agent to distinguish it from set_active_character and refresh_active_build.

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?

There is no explicit when-to-use guidance or mention of alternatives such as set_active_character or refresh_active_build. The intended use is implied by the action ('clear the active build'), but an explicit statement of when to prefer this over related mutation tools would be stronger.

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

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

Annotations already mark the tool as read-only and open-world safe. The description adds behavioral context beyond that: it parses the item text, infers the matching slot, and pulls equipped data from GGG API or an active PoB / poe.ninja build. It does not describe failure modes or output shape, but the core behavior is transparent.

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?

A single well-structured sentence that front-loads the action and input format, then adds source context in parentheticals. Every part earns its place with no redundant restatement of the title.

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 inputs and data sources are well covered, but there is no output schema and the description never states what the diff result looks like (stat comparison, text diff, upgrade recommendation). For an agent invoking this tool, the return contract is the main missing piece; the rest is adequately specified.

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 coverage is 100%, so the baseline is 3. The description adds useful semantics beyond the schema by specifying exactly what 'itemText' means (Ctrl+C from game or trade site) and what 'equipped' is resolved against (GGG API, PoB, or poe.ninja build). This clarifies the most ambiguous parameter despite the schema already being documented.

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 verb-resource pair: parse an item's full text and diff it against currently equipped gear. It also clarifies the matching-slot mechanism and distinct data sources, which sets it apart from siblings like find_trade_upgrades and get_inventory.

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 clear context for when to call the tool: when the user has item text pasted from the game or a trade site and wants a comparison against equipped gear. It does not explicitly name alternatives or when-not conditions, though no exclusion is strictly needed given how specific the scenario is.

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

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

The annotations only say the call is neither read-only nor destructive; the description adds the important behavioral context that the tool is a safe side channel that never touches the game state or automates gameplay. This goes well beyond the structured data and clarifies the exact side-effect profile.

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 front-loaded with the purpose and keeps its extra safety warnings in a compact second/third sentence. It is slightly emphatic with the repeated 'no...' list, but the content is relevant enough to earn its place.

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?

For a tool with no output schema and sparse annotations, the description covers core purpose, safety, and urgency usage, but it does not explain the delivery channel values or ttlMs, which are part of the input schema. Since schema coverage is low, this is a noticeable gap, though the required parameters are largely clear.

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 40% schema description coverage and five parameters, the description needed to compensate, but it only adds guidance for one value ('critical' urgency). It leaves ttlMs, the type channel semantics, and the reason field unexplained, so the agent cannot fully infer how to populate optional parameters.

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 opens with a concrete action and target ('Surface information or a suggestion to the player'), and immediately distinguishes the tool as a safe side channel from the read/inspection-oriented sibling tools. The title reinforces the same resource, so an agent can identify what this tool is for without opening the schema.

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?

It explicitly says this is the only channel through which the server acts on the agent's responses, telling when to choose it, and it states the exclusions: no simulated input, no memory writes, no gameplay automation. It also gives a clear condition for the critical urgency value, which is the main usage decision an agent would face.

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

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

Annotations already signal read-only/open-world behavior, and the description adds significant non-obvious context: it calls GGG's unofficial trade-site endpoint, may require POE2_TRADE_POESESSID, enforces constraints/ranking, and returns the official trade URL. This goes well beyond the structured annotations and is not contradicted by them.

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 dense sentences with no wasted words: the core search-and-return behavior is front-loaded, followed by the essential endpoint/authentication caveat. Every clause earns its place.

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?

For a 9-parameter tool with no output schema, the description covers the main contract, the external endpoint risk, auth dependency, and the return artifact. It could be more explicit about the exact response shape (ranked candidates vs URL only) and behavior when auth or matches are absent, but the operational essentials are present.

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 56%, and the prose adds meaning by clarifying that priorities are per-stat improvement requirements and that budget/required-level limits constrain the search. But it does not meaningfully clarify slot, resultLimit, or characterName beyond their schema defaults/enums, so the parameter contract remains partially delegated to the schema.

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 states a specific action ('Search live Path of Exile 2 listings'), a clear resource (PoE2 trade items), and the precise success criteria (improves every requested stat over the equipped slot, budget/level limits, ranked candidates, trade URL). This strongly differentiates it from sibling tools such as compare_item or get_defenses.

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 natural use case is implied: find a purchasable upgrade for an equipped slot with budget and level constraints. However, there is no explicit 'use this instead of X' guidance or exclusion of cases where siblings like compare_item would be more appropriate, so the agent must infer the routing boundary.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description correctly avoids repeating those. It adds a valuable behavioral detail that local paths are reduced to a filename, which is not apparent from the name or annotations. This gives the agent useful information about how the source field will be presented, though it does not describe the full return structure.

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 sentences with zero filler. The first sentence front-loads the core purpose and the list of returned fields; the second adds a single important caveat about local paths. Every word earns its place, and the structure is immediately scannable.

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?

For a no-parameter, read-only getter with open-world annotation, the description is nearly complete. It lists all the information the tool exposes and highlights a formatting detail. It does not mention what happens when no active build exists, but that can be inferred from the getter semantics and is not critical given the simple scope. No output schema exists, so the return format is not fully defined, but the summary description suffices.

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 zero parameters, the schema trivially covers all (100%), and the baseline for no parameters is 4. The description appropriately says nothing about parameters since there are none to clarify. It focuses on what the tool returns, which is the meaningful semantics here.

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 ('Show') and names the exact resource ('active build') plus a detailed list of what it reveals: source, pinned/automatic selection, character/league identity, refresh age, and a compact build summary. This clearly distinguishes it from sibling getters like get_current_character or get_character_state, which target different resources, and from mutators like set_active_character.

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 it is a read-only status query (with readOnlyHint annotation), and the name itself suggests it is the go-to tool for inspecting the active build. However, it provides no explicit guidance on when to choose this over, say, get_character_state or get_session_summary, nor does it mention any alternatives or exclusions. The usage context is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context by disclosing the external API source and the poe.ninja fallback path, which is beyond what annotations provide. It does not detail failure modes or auth prerequisites, but the core behavior is transparent.

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 one sentence that packs the resource, fields, source, and fallback rule without filler. Important details are front-loaded, and every clause earns its place.

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?

For a one-parameter, read-only lookup, the description covers what is fetched, from where, and when the fallback applies. The absence of an output schema is partially mitigated by naming the returned fields. Exact response shape and error behavior are not disclosed, but the tool is simple enough that this is a minor gap.

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 characterName is fully described in the schema as exact and case-sensitive. The description's phrase 'exact named character' reinforces that but does not add new semantic detail beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

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 ('Fetch a snapshot') and names the exact resource fields (level, class, experience, league). It also identifies the data source (GGG API with poe.ninja fallback), which clearly distinguishes it from siblings like list_characters or get_current_character.

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 this tool is for retrieving a specific named character from an external source, but it never explicitly states when to use this over get_current_character or list_characters. The fallback condition ('when an account is configured') provides some context, but no explicit when-to-use or when-not-to-use guidance is given.

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

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

Annotations only declare readOnlyHint=true, and the description adds meaningful context beyond that: it returns the last *entered* area rather than an absolute current area, and it relies on the local game log, which may lag or differ from server state. It does not mention behavior when no area is logged, but for a simple read-only tool this is sufficient.

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?

One sentence delivers the operation, the resource, and the data source with no filler. The most important information is front-loaded.

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?

For a zero-parameter, read-only tool, the description covers what is returned and where the data comes from. A minor gap is that it does not explicitly tie the area to the currently active character, but this can be reasonably inferred from the sibling set and context.

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 tool has zero parameters, so parameter semantics are vacuous. The rubric baseline of 4 applies because there are no parameter details the description needs to clarify.

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 ('Return') and names a precise resource ('the last area the character entered') plus the data source ('the local game log'). It clearly distinguishes this tool from siblings like get_current_character and get_recent_events.

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 intended use case is implied: an agent should call this when it needs the character's most recently entered area from local data. However, the description does not explicitly state when not to use it or name alternatives, so sibling selection still requires inference.

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

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

The description discloses that the result may be inferred from death/level_up log lines and includes a warning to check the 'source' field ('explicit' vs 'inferred_from_log' vs 'none'). This adds significant behavioral detail beyond the readOnlyHint annotation, which only indicates it's a read operation.

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, information-dense sentence that front-loads the core purpose, then explains the inference mechanism and the caution about the source field. No redundancy or fluff.

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?

For a zero-parameter read-only tool, the description covers the key behavior and the important source field. It doesn't detail the full return structure, but given no output schema and the simple nature of the tool, it's sufficient.

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?

There are no parameters, so the baseline is 4 per rubric. The description adds context about the return value's source field, which is useful, but there is nothing to add about parameters themselves.

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 precisely states the tool's function: returning the default character used by other tools when characterName is omitted, and explicitly names four sibling tools (get_passive_tree, get_defenses, get_offense_stats, compare_item). This clearly differentiates it from siblings like set_active_character.

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?

It explains the tool's role in the context of other tools and advises checking the 'source' field before trusting the result. It doesn't explicitly state when not to use it or name alternatives, but the context makes its purpose evident.

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

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

Annotations already establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral context by specifying that it aggregates gear-derived defenses rather than raw character values, and by naming the possible data sources. It does not contradict annotations, though it could mention source precedence or failure behavior.

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 sentence that front-loads the action and the stat list, then appends the data source qualifier. Every part is informative with no redundant or filler wording.

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?

For a simple read-only tool with one optional parameter and no output schema, the description conveys what is computed, from which gear, and via which sources. It is reasonably complete, though a brief note about behavior when no character or build is active would make it fully robust.

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 coverage is 100%, and the schema already describes characterName as defaulting to the current active character. The description does not add any parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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 ('Aggregate') and clearly identifies the resource (defensive stats from a character's equipped gear) and the data source (GGG API, PoB, poe.ninja). It also enumerates the exact stats returned, which distinguishes it from sibling tools like get_offense_stats or get_passive_tree.

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 useful context about where data comes from ('via GGG API, or via active PoB / poe.ninja build') but does not explicitly state when to choose this tool over alternatives or when not to use it. The usage is implied rather than clearly guided.

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

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

Annotations already mark the tool as read-only and open-world, so the description's added value is the fallback behavior: it first tries the GGG API and falls back to poe.ninja or an active PoB build. This is useful context that tells the agent data may come from different sources with potentially different freshness or fidelity.

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?

A single, front-loaded sentence that names the action, the target data, and the source strategy with no filler. Every phrase earns its place.

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?

For a simple read-only fetch with one optional parameter and no output schema, the description adequately conveys what is returned (equipped items and skills) and how data is sourced. It stops short of describing the response structure or error behavior, but the high-level content is clear enough for an agent to call it correctly.

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 schema fully documents the only parameter with 100% coverage, including the 'optional if active build is loaded' condition. The description reinforces this by mentioning the active PoB build fallback, but it does not add new parameter details beyond what the schema already provides.

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?

States a specific verb and resource: 'Fetch a character's equipped items and skills.' It also names the data sources (GGG API, poe.ninja, active PoB build), which clearly differentiates it from sibling tools focused on passive tree, defenses, or offense stats.

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 context is implied by the resource name and by the note that characterName is optional if an active build is loaded. However, it does not explicitly state when to prefer this tool over siblings like get_defenses, get_offense_stats, or get_character_state, nor does it give exclusion criteria.

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

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

Annotations already declare the tool as read-only and open-world, covering the main safety profile. The description adds useful context about the sources and that the aggregation is gear-only, but it does not disclose limitations such as whether buffs, passives, or temporary modifiers are excluded, or what happens when no character/build is available.

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?

A single sentence that front-loads the operation and lists the exact computed values, followed by source options in parentheses. Every phrase earns its place with no filler or repetition.

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?

For a low-complexity tool with one optional parameter, the description gives enough for an agent to call it correctly and understand the scope of output. It does not describe the return format, but the listed aggregate values plus the absence of an output schema make the expected result reasonably inferable.

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 100%: the single optional characterName parameter is already documented in the schema, including its default behavior. The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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 verb ('Aggregate') and a precise resource: weapon damage ranges, crit, attack speed, and gear-derived damage affixes from equipped gear. This clearly distinguishes it from defensive or passive-tree sibling tools like get_defenses, even without explicitly naming them.

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 clearly implies this is the tool for offensive gear-derived stats and identifies the data sources (GGG API, PoB, poe.ninja), which gives an agent context for when to invoke it. It does not explicitly exclude alternatives like get_defenses, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description only needs to add extra behavioral context. It does reveal that the tool may pull from an external API or a local PoB/poe.ninja build, but it does not explain fallback behavior, freshness, or what happens when no build is available. This is useful but incomplete.

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, focused sentence that packs the core action, resource, and data-source choices without any filler. It is front-loaded with the main intent and contains only relevant details.

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?

For a simple read-only getter with one optional parameter, the description is nearly complete: it names what is fetched, where the data may come from, and the schema fills in the parameter default. It could add more about output shape or error conditions, but these are minor given the tool's simplicity and annotation coverage.

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 input schema already provides 100% coverage for the single optional characterName parameter, including its default behavior. The description adds no additional parameter-specific meaning beyond that, so the baseline score of 3 is appropriate.

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 a specific action ('Fetch') and resource ('a character's allocated passive tree node hashes and jewel data'), making it easy to distinguish from sibling tools like get_defenses or get_inventory. It also adds source context (GGG API or active PoB/poe.ninja build), which further clarifies its purpose.

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 the tool is for retrieving passive tree data and mentions possible data sources, but it does not explicitly state when to use this tool over alternatives or when not to use it. The context is understandable but relies on the agent to infer the right situation from the sibling list.

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

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

Beyond the readOnlyHint, the description discloses polling cadence, local-only execution, absence of rate limits, default exclusion of raw unmatched lines, and the security caveat about untrusted chat payloads. This is rich behavioral transparency with no contradiction.

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 compact and front-loaded with the primary purpose, then delivers constraints and caveats in distinct sentences. Every sentence earns its place; there is no filler or redundant restating of the tool name.

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?

For a simple read-only tool with three optional parameters, the description covers source, freshness, filtering behavior, network behavior, and security. It could be slightly more complete by describing the output shape, but the event-type list and default filtering give an agent enough to invoke it correctly.

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 100%, so the schema already documents the three optional parameters and the enum values. The description adds no parameter-specific semantics beyond restating the event categories and the raw-line exclusion behavior, so it meets the baseline but does not exceed it.

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 ('Return') and resource ('recently parsed events from the local Client.txt log'), and it enumerates the event categories: area transitions, level ups, deaths, trade whispers, player chat messages, and instance creation. This makes the tool's purpose unmistakable and distinguishable from the sibling tools.

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?

It gives clear context for when to use the tool: near-real-time local event retrieval with no network calls or rate limits, and raw unmatched lines are excluded unless explicitly requested. It does not explicitly name an alternative tool or state when not to use it, so it stops short of a 5.

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

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

Annotations declare readOnlyHint=true, and the description adds context that the tool derives stats from the local game log and is scoped to the current server session. This goes beyond the annotation by explaining the data source and temporal scope, though it does not mention potential failures or resource limitations.

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?

A single, front-loaded sentence states the core purpose ('Return aggregate stats for the current server session') and lists the specific stats, with no redundant words. Every element earns its place.

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?

For a read-only, parameterless tool with no output schema, the description fully specifies what the agent can expect: the set of returned stats and their source (local game log since server start). Nothing necessary for correct invocation is missing.

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 tool has zero parameters, so the baseline is 4. The schema is empty, and the description does not need to explain parameters. No additional parameter semantics are required.

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 tool returns aggregate stats for the current session and lists specific metrics (areas visited, deaths, level-ups, last known area). It distinguishes from siblings like get_recent_events (event list) and get_current_area (current area only) by focusing on summary data.

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 usage for session-level summaries but does not explicitly contrast with alternatives or state when not to use it. Given siblings like get_recent_events and get_current_area, the intended context is implied but not articulated.

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

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

Annotations declare readOnlyHint=false, so the description's statement 'save it as the active build' confirms mutation without contradiction. It adds useful context about parsing into equipment/skills/passive tree and computed stats, though it does not mention overwriting behavior or side effects beyond saving.

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 sentences with no filler. The core purpose and effect are front-loaded, followed by parameter clarification. Every sentence earns its place.

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 tool is a mutation with two optional parameters and no output schema. The description covers what it does, valid inputs, and the effect on active build. It lacks explicit prerequisites (e.g., active character) but is otherwise complete for an import tool.

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 coverage is 100% with descriptions for both parameters. The description adds the mutual exclusivity ('either... or') and clarifies 'approved URL' and 'configured PoB Builds directory', providing extra meaning beyond the schema.

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 (parse/import/save), the resource (a Path of Building 2 build), and the outcome (saves as active build for gear/defense tools). It distinguishes from sibling import_poe_ninja_character by specifying PoB2 builds.

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 explains how to provide input (either code or filePath) but does not explicitly contrast with alternatives like import_poe_ninja_character or state conditions for use. It implies usage context but lacks explicit when-to-use guidance.

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

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

readOnlyHint: false already flags the mutation; the description adds genuine behavioral context by specifying the exact side effect (replaces the active build) and naming which dependent tools are affected. This is valuable beyond the annotation, though it stops short of describing overwrite/reversal behavior.

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?

A single ~50-word sentence that front-loads the core purpose before the side-effect detail. Every clause earns its place: source, two input methods, and downstream effect. No filler or restatement of the name.

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?

For a 4-optional-param tool with no output schema and a mutation annotation, the description covers the essential agent-facing facts: input source, input alternatives, and the resulting active-build state. A successful-call response shape is undocumented, but the absence of an output schema and clear primary behaviors keep this adequately 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?

Schema description coverage is 100%, so the schema documents all four parameters and their defaulting behavior (accountName defaults to configured account; characterName to currently played character). The description only adds the OR-relationship between profileUrl and account/character name, which is helpful but modest; the schema bears most of the load, so the baseline 3 applies.

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?

States a specific verb (import), a precise source (poe.ninja), and the concrete outcome (set as active build consumed by compare_item, get_defenses, get_offense_stats, get_inventory). Naming the source and the downstream tools distinguishes it from the sibling import_pob_build without needing to open either schema.

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?

Provides operational guidance by laying out the two input paths (profile URL OR account name + character name) and clearly describes what happens on success (becomes the active build that feeds the listed tools). It implies the natural use case (populate the working build from poe.ninja) but does not explicitly contrast with import_pob_build or state when not to use it, so a small gap remains.

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

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

Beyond the readOnlyHint, the description discloses a key behavioral subtlety: the check is by process name, not verified against a confirmed process name, so a false result is not definitive. Also noting that the response contains 'checkedNames' gives agents useful interpretation 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 compact, front-loaded with the core purpose, and every clause adds value: the best-effort caveat, the false-negative warning, and the routing to import_pob_build.

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?

For a no-argument, read-only probe with no output schema, the description covers what the agent needs: what is checked, how to interpret a false result, the presence of checkedNames in the response, and where to go for actual build data. Nothing material is missing.

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 tool has zero parameters and the schema is empty, so there is no parameter detail to document. The 0-params baseline of 4 applies; the description appropriately focuses on output interpretation instead.

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 ('check') and resource ('running Path of Building 2 process'), and clearly distinguishes itself from the sibling import_pob_build by calling itself informational only. This prevents an agent from mistaking the tool for one that returns build data.

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 explicitly says this is a best-effort informational check and directs agents to use import_pob_build when they actually need build data. This gives both a when-to-use and a when-not-to-use signal, and names the relevant alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context: it names the two underlying data sources (GGG API or poe.ninja) and the condition that selects between them. No contradictions with annotations.

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?

A single, front-loaded sentence conveys the core action, scope, and fallback behavior with no filler. Every clause earns its place.

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?

For a read-only, zero-parameter tool, the description is nearly complete: it states what is listed, whose account, and how the data is sourced. It does not describe the return format, but the absence of an output schema and the phrase 'character names' make the expected result reasonably clear.

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?

This tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 for a 0-parameter tool applies, and the description adds relevant scope context without needing to explain inputs.

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 states a specific verb and resource: 'List character names on the authorized PoE account'. It also clarifies the two possible data sources, which distinguishes it from sibling tools like import_poe_ninja_character or set_active_character.

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 clear context on when the tool applies (listing character names from the authorized account) and specifies the API fallback condition. It does not explicitly name sibling tools as alternatives, but the context is sufficient for an agent to decide this is the listing tool.

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

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

Annotations already provide readOnlyHint=true, but the description adds valuable context: it is metadata only, the most recent file is a guess based on save recency, and it mentions configuration via POE2_POB_BUILDS_PATH. This goes beyond the annotation and accurately sets expectations.

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 two sentences, each earning its place: the first states the core function and sorting, the second clarifies the metadata limitation and the integration point with import_pob_build. No fluff or redundancy.

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?

For a parameterless, read-only listing tool with no output schema, the description fully covers the agent's needs: what files are returned, the order, the reliability caveat, and how to consume the result. It also handles configuration details. Nothing essential is missing.

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 tool has zero parameters, so there is nothing to explain. Per the guidelines, a 0-parameter tool gets a baseline of 4. The description does not attempt to add parameter information because none exists.

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 'List' and the resource '.xml files in the configured Path of Building 2 Builds folder', and distinguishes this from the sibling import_pob_build by noting it is metadata-only. It also clarifies the sorting order, making the tool's function unambiguous.

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 explicitly explains when to use this tool (to get a list of builds) and warns against interpreting the most recent file as the confirmed current build. It also directs the agent to pass a path to import_pob_build's filePath, effectively chaining tools and covering the follow-up action.

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

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

Annotations already signal non-read-only/open-world behavior and non-destructive intent. The description adds useful behavioral context: it refreshes from a persisted source, preserves the same selection, and explicitly cannot handle pasted codes. This goes beyond what annotations alone convey.

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 tight sentences with no filler. The core operation is front-loaded, and the critical limitation appears immediately after, earning every word.

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?

For a simple zero-parameter, no-output-schema tool, the description provides the operation, source types, and an important exclusion. It could add a hint about what happens after refresh, but nothing essential for invoking it correctly is missing.

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 zero parameters and 100% schema coverage, there is no parameter burden for the description to carry. The baseline of 4 applies because the tool is parameterless and the description correctly imposes no parameter expectations.

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?

States a specific verb ('Reload') and resource ('same pinned/selected build'), and names two source identities (PoB file, poe.ninja). The added exclusion of pasted share codes/XML clearly distinguishes this from import-based siblings.

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 clearly conveys when refresh is valid (pinned/selected builds) and when it is not (pasted share codes/XML), directing those cases to re-import. It stops short of naming the sibling import tools explicitly, but the guidance is actionable.

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

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

Annotations already communicate that this is not read-only and not destructive. The description adds useful context about why the account name is needed and the OAuth-avoidance benefit, but it does not disclose additional behaviors such as validation, persistence, overwriting of an existing name, or failure modes.

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?

A single, efficient sentence that leads with the action, includes concrete examples, and explains the purpose. There is no filler or redundant detail.

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?

For a simple one-parameter setter with no output schema, the description is largely sufficient: it states what is set, why it matters, and what format is expected. It stops short of clarifying when precisely to call it, but the low complexity keeps this from being a significant gap.

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 input schema covers the single parameter completely, including format examples. The description repeats those examples but adds no meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.

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 identifies the action ('Set your Path of Exile account name'), the resource being configured, and the downstream benefit (fetching characters and gear from poe.ninja without GGG OAuth). This distinguishes it from sibling tools like set_active_character, which operate on a different concept.

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 strong context for when this tool is relevant: when the server needs to fetch characters and gear from poe.ninja without OAuth credentials. It does not explicitly list exclusions or name alternative tools, but the purpose is clear enough for an agent to infer the right situation.

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

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

Annotations already indicate this is a state-changing but non-destructive operation. The description adds useful behavioral context by stating the value is validated against the account's actual character list via GGG API or poe.ninja, which implies invalid names will be rejected.

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, front-loaded with the tool's effect and followed by the validation behavior. Every sentence earns its place with no filler.

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?

For a simple one-parameter setter with annotations covering mutation safety, the description is nearly complete. It explains the stateful effect and validation, though it does not describe success/error return behavior, which is a minor gap without an output schema.

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 coverage is 100%, with the characterName property already described as an exact, case-sensitive string. The description does not add new parameter-level detail beyond that, so the baseline of 3 is appropriate.

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 ('Pin') and names the exact resource: which character subsequent tool calls should default to when characterName is omitted. This clearly distinguishes it from siblings like set_account_name and clear_active_build.

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?

It gives clear context for use: it changes the default character for future calls that omit characterName. It does not explicitly name alternatives or exclusions, but the usage context is unambiguous enough that an agent knows when to invoke it.

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