poe2-build-mcp

by MaxWilk

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.40
Disambiguation4/5
Most tools have distinct purposes, but the optimization sub-tools (optimize_build, plan_gear, optimize_item, optimize_passives, optimize_supports) overlap in intent and could confuse an agent on which to call for a given task. Detailed descriptions help, but boundaries are not always crisp.
Naming Consistency5/5
Tool names consistently use snake_case and follow a verb_noun pattern (e.g., alloc_passive, optimize_item, search_mods). A few exceptions like corpus_info are noun_noun but rare. Overall highly predictable.
Tool Count2/5
64 tools is far beyond the typical 3-15 range. While the complexity of Path of Exile 2 justifies many tools, the count feels bloated with many specialized utilities (e.g., separate tools for each search type). Could be consolidated.
Completeness4/5
The tool set covers almost all aspects of PoE2 build theorycrafting: passive tree, skills, gear, jewels, support gems, statistics, optimization, comparisons, market prices, mechanics explanations, and imports/exports. Minor gaps like no tree visualization or explicit tool for managing tree data, but core workflows are supported.
Average 4.3/5 across 60 of 64 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- Last stable release on June 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns gems with recommended supports, but does not cover ordering, pagination, error handling, or performance implications. The behavioral statement is helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a main sentence followed by brief explanations of key parameters. It is front-loaded and avoids unnecessary words, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and 0% schema coverage, the description should cover all parameters. It covers only three partially, omitting 'query' and 'limit'. The presence of an output schema does not fully compensate for missing parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains gem_type, tag, and color values, but does not explain the 'query' parameter or 'limit'. This leaves two out of five parameters undocumented, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: finding skill/support gems by text, tag, color, or type. It identifies the resource (gems) and the filtering criteria, but does not explicitly differentiate from the sibling tool 'find_supports_for'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific values for gem_type, tag, and color, giving some guidance on how to use the tool. However, it lacks explicit guidance on when to use this tool versus alternatives like 'find_supports_for', and does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation by saying 'Return full data', but does not explicitly state safety, error handling, or side effects. Detail on read-only behavior would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 16 words, front-loaded with purpose and scope. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately outlines the return fields. It is sufficient for a single-resource retrieval tool but could mention error behavior or that it returns a gem object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter name_or_id is described as accepting a name or id, which adds value beyond the schema's type string. However, schema coverage is 0%, and the description lacks detail on valid formats or search behavior (e.g., exact match, case sensitivity).
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 clearly states the tool returns full data for a single gem, specifying the resource (gem) and the scope (full data including tags, granted skills, supports, types). This distinguishes it from sibling tools like get_item, get_passive, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_item or get_passive. The agent must infer usage from the resource name. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors such as side effects or required permissions. It states a comparison and report but does not clarify if the tool modifies data, requires network access, or is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, extremely concise, and front-loaded with the action. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the basic purpose. Given there is an output schema (not shown), the description could benefit from specifying what the report contains (e.g., version comparison results) to be more complete.
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?
The tool has no parameters (0 required, schema coverage 100%), so the description does not need to add parameter meaning. Baseline is 4 for zero parameters.
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 clearly states the tool's action: 'Compare the bundled game-data corpus against upstream and report the current league.' This is a specific verb+resource combination that distinguishes it from siblings like 'corpus_info' or 'check_for_updates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'corpus_info' or 'check_for_updates'. It lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. It does not disclose behavioral traits like pagination, result limits beyond the default, read-only nature, or any side effects. The limit parameter is mentioned but not explained.
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 description is concise with two sentences that front-load the main purpose. It is efficient but could benefit from brief parameter explanations without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be explained. However, the description lacks parameter guidance and behavioral context, making it only moderately complete for a search tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains item_type with examples. The query parameter is implied to search by name, base, or mod text but lacks specifics (e.g., exact vs fuzzy). The limit parameter is not described at all.
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 clearly states the tool searches Path of Exile 2 unique items by name, base, or mod text. It also mentions filtering by item_type and distinguishes from sibling tool 'get_unique' which is for full text retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use this tool (search) and when to use 'get_unique' for full text, providing an explicit alternative. However, it does not mention when not to use it or other related tools like 'search_items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool mutates state ('Set') and returns updated stats, which is positive. However, without annotations, it does not disclose potential side effects, validation rules, or whether the level change impacts other attributes beyond stats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (12 words) that front-loads the action and key constraint. Every word adds value—no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and presence of an output schema, the description is largely complete. It covers the essential constraint (range) and return behavior. Minor omission: it could note that setting level affects the build's stat calculations.
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?
The schema provides only the parameter name and type, but the description adds the valid range '1-100', which is crucial for correct invocation. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('active build's character level'), and the valid range ('1-100'). It also mentions the return value ('Returns updated stats'), which helps distinguish it from sibling tools like set_class or set_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't indicate that level should be set before or after other configuration, or any prerequisites like having an active build.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states that the tool deallocates a node and its dependencies, returning points and stat deltas, but does not mention side effects (e.g., permanence, reversibility, authentication requirements) or error conditions. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states the action and input method, the second explains the return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema (content unknown), the description covers the core functionality and return value. It is adequate for a simple deallocation tool, though it does not address edge cases or prerequisites.
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?
The only parameter 'node' has no schema description (0% coverage). The description clarifies that it can be an id (integer) or name (string), which adds essential meaning. However, it does not provide format examples or constraints beyond the schema's anyOf.
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 uses a specific verb 'Deallocate' and clearly identifies the resource as 'passive node'. It also mentions what the tool returns (points freed and stat deltas), which distinguishes it from siblings like 'alloc_passive' and 'get_passive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'apply_updates' or 'optimize_passives'), nor does it state prerequisites or conditions for use. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the mutation nature (download and install) and scope (engine + corpus). However, with no annotations, it fails to mention potential side effects like service restarts, rollback options, or status when already up-to-date.
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?
Single sentence is concise and front-loaded. Every word earns its place, though could be slightly more structured with a brief note on usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is clear enough. However, it lacks mention of preconditions like checking for updates first, which would improve completeness given sibling tools.
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?
No parameters exist, so schema coverage is 100%. Description adds no param info, which is acceptable per baseline rule (score 4).
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?
Description clearly states the verb-adverb (download and install) and resource (latest validated release, engine + corpus). It is specific and distinguishes from sibling tools like 'check_for_updates' (check only) and 'update_corpus' (corpus only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus checking first with 'check_for_updates' or other alternatives. The 'now' implies immediacy but lacks prerequisites or context for safe invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only describes the search functionality and return values but does not mention safety (e.g., read-only), required permissions, or side effects. As a search tool, it is likely safe, but this is not explicit. The description lacks transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence for purpose and a code block for parameter details. It is front-loaded with the main action and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main function and output composition but omits explanation of the 'query' and 'limit' parameters. Given that an output schema exists, return values are adequately described. However, for a tool with 4 parameters and no annotations, the description could be more thorough. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains two of the four parameters (item_tag and mod_type) with clear meaning. However, it does not describe the 'query' parameter (obvious from name but not explained) or 'limit' parameter. This partial coverage is adequate but not complete.
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 clearly states the tool searches for Path of Exile 2 affixes/modifiers by readable text, using a specific verb 'Search' and a distinct resource 'affixes/modifiers'. This distinguishes it from siblings like search_items (items) and search_passives (passives).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool (searching mods/affixes by text) and explains parameters, but does not explicitly state when not to use it or provide alternatives. The context from sibling tools helps, but no direct exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It discloses return values (points spent, stat deltas) and a failure condition, but omits whether the operation is destructive or idempotent, and any permission or state requirements. Adequate but not thorough for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states purpose, the second adds behavioral details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and presence of an output schema (not shown but referenced), the description provides necessary context. However, it could mention that allocation modifies the build state (e.g., 'This modifies the current build.') to improve completeness.
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?
The single parameter 'node' has 0% schema description coverage. The description adds meaning by clarifying that it accepts both id (integer) and name (string), which is not evident from the schema alone.
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 uses a specific verb ('Allocate') and resource ('passive node'), and adds scoping details ('by id or name', 'shortest path', 'fails if not reachable'). It clearly distinguishes from siblings like dealloc_passive and optimize_passives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to use alloc_passive vs search_passives or optimize_passives). The failure condition is mentioned but does not constitute usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only check for updates, but does not disclose potential side effects, required permissions, or how results are returned. Adequate but minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with key action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema (not detailed), the description is largely complete. However, it could clarify what 'validated' means or how to interpret the result.
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?
No parameters exist (schema coverage 100% trivially). The description does not need to add parameter information, and baseline for 0 parameters is 4. No additional meaning required.
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 clearly states the tool checks for a newer validated release (engine + corpus) available to install. It uses a specific verb 'check' and specific resource 'release', distinguishing it from sibling tools like apply_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., apply_updates, update_corpus). The description does not provide usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Return full data' without disclosing read-only nature, error behavior, rate limits, or any side effects. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words. Front-loaded with verb and resource; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description appropriately omits return value details. The tool's single-param, exact-match retrieval is simple enough that the description covers the core behavior. Minor gap: no mention of error handling for missing items.
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?
Description adds meaning to the sole parameter 'name_or_id' by specifying it accepts 'exact name or metadata id', which is missing from the schema (0% coverage). This clarifies the parameter's acceptable values.
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 clearly states the verb ('Return'), resource ('full data for a single item base'), and method ('by exact name or metadata id'). It distinguishes from sibling search tools that imply partial matches or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives like 'search_items'. The description implies exact match usage but does not clarify exclusions or alternative tool scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the basic listing action and optional filtering, but does not reveal behavior like whether all ascendancies are returned when no filter is provided, or any rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 11 words with no redundant information. It effectively communicates the tool's purpose without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, it lacks context on the default behavior when no filter is provided and does not mention if only valid classes are accepted. For a simple tool, it is nearly complete.
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 description coverage is 0% so the description must add meaning. The description clarifies that the 'character' parameter refers to a base class for filtering. This adds value beyond the schema, though it could specify allowed values or format.
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 uses a specific verb 'list' and resource 'ascendancies' with clear scope 'Path of Exile 2' and optional filter 'by base class'. It distinguishes itself from sibling tools like list_config_options or search_passives by its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing ascendancies but provides no explicit guidance on when to use it over alternatives or any when-not conditions. It lacks context like prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states computed by 'real PoB engine' but lacks details on side effects, error behavior (e.g., no build loaded, invalid keys), or performance implications. This is insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. Every word earns its place; no fluff. Ideal length for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not specify what the default summary includes or any error conditions (e.g., if no build is loaded). For a tool with a single parameter, it is minimally adequate but leaves room for ambiguity.
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?
With 0% schema coverage, the description adds critical meaning: explains 'keys' is an optional array of strings for specific stats, gives examples, and clarifies omission yields a default summary. This compensates well for the schema gap.
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 clearly states the tool returns PoB-computed stats for the currently loaded build, with a specific verb ('Return') and resource ('build stats'). It distinguishes from siblings like get_defenses (specific defense stats) and get_build (full build data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: pass 'keys' for specific stats or omit for a default summary. It does not explicitly mention when to use alternatives like get_defenses, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description only states that it returns details, without mentioning whether the operation is read-only, if it requires authentication, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and parameter usage. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, output schema present), the description is largely complete. However, with 31 sibling tools, additional context about what 'details' entail (e.g., properties returned) could further aid differentiation, though the output schema may compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameter. It clearly explains that the 'node' parameter can be an id (preferred) or exact name, adding essential meaning beyond the schema's type definition.
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 explicitly states the action (Return details), the resource (passive node), and the two methods of identification (by id or exact name). This clearly distinguishes it from siblings like search_passives or alloc_passive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends using id over name, providing a preference for usage. However, it does not explicitly state when to use get_passive versus alternatives like search_passives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool recomputes and returns stats, a key behavioral trait. However, it does not mention side effects, whether changes are reversible, or any permission requirements.
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 description is concise, with the main purpose front-loaded. It efficiently conveys key information without fluff, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters) and presence of an output schema, the description adequately covers purpose, parameter usage, and outcome. It does not address error cases, but completeness is sufficient for the context.
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 description coverage is 0%, so the description must compensate. It explains both parameters well: 'options' are PoB config keys with examples, 'custom_mods' is free-form text. This adds substantial meaning beyond the schema.
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 clearly states the tool sets combat/configuration options and custom modifiers on the active build. It uses specific verbs ('Set') and resource ('active build'), and provides examples that distinguish it from sibling tools like set_class and set_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it versus alternative configuration tools. It lacks mention of prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the behavioral process: snapshotting, loading source, restoring, and returning stats with deltas. It also explains the 'without losing it' safety trait. The only missing detail is the effect on the application state after use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's behavior, process, and output format. It misses details about the 'keys' parameter, but overall it is sufficient for a build comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 'source' by specifying it can be a code, link, or XML, which is absent in the schema. However, 'keys' is not explained, leaving its purpose unclear. Since schema coverage is 0%, the description partially compensates but lacks full parameter clarity.
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 clearly states the tool's purpose: 'Compare the active build against another build' and details the process. It distinguishes itself from siblings by specifying the comparison action and preservation of the current build, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting 'without losing it,' but it does not explicitly state when to use this tool over alternatives like evaluate_build or export_build. No when-not guidance or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'live' prices and default league behavior but does not explicitly state that the operation is read-only or discuss rate limits, caching, or potential side effects. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a short backtick block. Every sentence adds value, front-loading the purpose then parameter details. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description covers the core input (kind, query, league) but omits category and limit. The output schema compensates for return values, so overall it is mostly complete for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains kind, query, and league parameters with examples, but does not describe category or limit. Thus, it adds partial value but leaves gaps for two parameters.
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 clearly states the tool's purpose: 'Look up live Path of Exile 2 market prices' with the source poe2scout.com. It distinguishes itself from sibling tools like get_item and get_unique by focusing specifically on market prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context, including defaults for kind, query, and league, and example filters. However, it does not explicitly specify when not to use this tool or mention alternative tools for similar queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It discloses that the jewel only applies in allocated sockets and that jewels bypass the equip legality check. However, it does not mention whether the operation is destructive, reversible, or what happens if the socket is already occupied. The description provides some context but lacks comprehensive behavioral details.
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 description starts with the main action and then explains parameters and behavioral notes. It is mostly concise, but the last sentence about mana-stacker power is somewhat tangential and could be considered extra detail. Overall, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core usage and parameter details, but lacks information on return values (despite an output schema existing) and error conditions. It also does not mention reversibility or side effects. For a simple tool with two parameters, it provides adequate but not comprehensive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. It clarifies that 'raw' is 'raw PoB item text' and for 'socket', it specifies it is a socket ID from 'list_jewel_sockets' and defaults to the first allocated empty socket. The schema only provides types and required status, so the description is essential.
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 clearly states the action 'socket a jewel' into a 'passive-tree jewel socket', using a specific verb and resource. It distinguishes itself from sibling tools like 'equip_item' (which equips normal items) and 'list_jewel_sockets' (which lists sockets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the optional 'socket' parameter and references 'list_jewel_sockets' for obtaining socket IDs. It provides context on allocated sockets and notes that jewels are not covered by the equip legality check, but does not explicitly state when not to use this tool or compare it directly to alternatives like 'equip_item'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the tool as a read-back (non-destructive) and lists returned data, but it does not disclose potential side effects, permissions needed, or behavior when no build is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. The first sentence immediately states the tool's purpose, and the second provides a clear, bullet-like enumeration of what is returned.
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 the tool has no parameters and an output schema exists, the description is complete: it tells the agent exactly what data to expect, covering all major aspects of a build without missing context.
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?
With zero parameters and 100% schema coverage (empty schema), the baseline is 4. The description adds meaning by detailing the contents of the returned build, which goes beyond the minimal schema.
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 clearly states the tool returns a full read-back of the active build and enumerates specific categories (class, skill group, allocated nodes, gear, stats), making the purpose unambiguous and distinguishing it from more specific getter tools like get_build_stats 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a comprehensive view of the build is needed, but it does not explicitly state when to use this tool over alternatives such as get_build_stats or get_defenses, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently states the tool returns candidates based on matching criteria and that numbers come from the engine. It does not disclose state-dependence explicitly but implies it via 'active build'.
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 description is about five sentences, well-structured starting with purpose and then details. It is efficient but could be slightly more concise. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, output schema, and no nested objects, the description covers purpose, matching logic, candidate status, and recommended follow-up actions. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'limit' parameter. However, the parameter is a single optional integer with a self-explanatory name and default, so minimal additional meaning is needed. The description does not compensate for the coverage gap.
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 clearly states the tool surfaces unique items and jewels that synergize with the active build, matching against scaling and skill name. It distinguishes from related tools like get_unique by noting these are candidates, not verified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance, advising to follow up with get_unique, equip_item, or equip_jewel to measure actual impact. However, it does not explicitly state when not to use this tool or list direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns principles and sections, but does not explicitly state it is read-only or safe. However, it implies no side effects and is consistent with a safe advisory tool.
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 description is concise: one sentence for purpose and one sentence for parameter usage. It is front-loaded with the core purpose. Minor improvement could combine sentences, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter and the existence of an output schema, the description sufficiently covers usage and output concept. It might benefit from listing possible topics comprehensively, but the examples are representative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the default behavior when omitted and providing concrete examples of valid topics. This adds complete semantic meaning beyond the parameter name.
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 clearly states the tool provides 'Evergreen PoE2 build-optimization principles' and distinguishes itself from numeric compute tools by noting that actual DPS/EHP numbers come from elsewhere. This separates it from sibling tools like evaluate_build and get_build_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to omit or pass the 'topic' parameter, listing examples of valid topics. It also clarifies that this tool is for principles, not a meta snapshot, directing the agent to use compute tools for actual numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what is reported (liveness, versions, data source) without mentioning side effects, which is appropriate for a read-only diagnostic tool. No annotations provided, but description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loading the key purpose and listing specifics. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficiently complete for a zero-parameter tool with an output schema. Covers all aspects an agent needs to understand the tool's function.
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?
No parameters, schema coverage 100%. The description adds value by explaining the purpose beyond the empty schema, earning baseline 4.
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 clearly states it reports 'engine + install diagnostics' including specific items like versions and data source. This distinguishes it from sibling tools that deal with builds, items, or updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a diagnostic tool without explicit when-to-use or alternatives. No sibling tools serve a similar diagnostic purpose, so it's clear but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only export operation but does not explicitly state whether it modifies state or requires authentication. With no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences; first states purpose, second adds usage. No filler words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with no parameters and an output schema, the description covers the purpose and output usage. Could mention potential errors or prerequisites, but adequate.
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?
No parameters in schema, but description adds value by explaining the output 'code' and its usage. Baseline for 0 params is 4.
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 clearly states 'Export the active build as a Path of Building import code', which is a specific verb and resource. It distinguishes from 'import_build' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance on pasting the returned code into Path of Building. However, it does not mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return fields and filtering, but does not mention idempotency, auth, or side effects. Adequate for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema existing, description explains return fields. However, limit parameter behavior is not described, leaving a minor gap. Otherwise complete for a filtered list tool.
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 0%, so description compensates well. Describes query parameter with examples and behavior; limit parameter is left to defaults, no additional meaning. Adds significant value.
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 clearly states it lists configuration options for use with set_config, specifying categories and filtering. It differentiates itself from sibling tools by focusing on config options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: usable with set_config, can filter by query with examples like 'boss', 'charge'. Does not explicitly state when not to use or suggest alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output (matching affixes, gems, unique items) but does not disclose other behavioral traits such as whether it is read-only, rate limits, or ordering 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence defining the purpose followed by clear examples. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with two parameters and an output schema, the description covers the essential purpose and usage. It could mention that 'limit' caps results, but overall it is complete enough.
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 has 0% description coverage, but the description adds meaning by providing an example for the 'stat' parameter and implying 'limit' controls result count. However, 'limit' is not explicitly explained.
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 clearly states the tool's purpose with a specific verb ('Find') and resource ('where a stat comes from'), and distinguishes it from sibling tools by focusing on reverse lookup of stat sources across affixes, gems, and uniques.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage examples ('reverse_lookup("maximum life")') that imply when to use, but does not explicitly state when not to use or mention alternative tools like search_mods. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral trait of returning matching bases with specified fields, which implies a read-only operation. It does not mention authentication, rate limits, or search semantics (e.g., exact vs. fuzzy), but given the output schema existence, the return structure is defined elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the main purpose, then provides return info and a pointer to an alternative. Very concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (none required) and an output schema, the description covers the core functionality, return values, and an alternative. It lacks explicit parameter format details but is reasonably complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning by indicating that 'query' searches by name/tags and 'item_class' filters results. However, the 'limit' parameter and any default behavior are not described, leaving some ambiguity.
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 clearly states the tool searches Path of Exile 2 item bases by name/tags with optional item class filtering. It specifies the return fields (name, item_class, drop_level, tags) and distinguishes itself from sibling get_item by directing users to that tool for full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use this tool (searching by name/tags) and explicitly mentions an alternative (get_item) for full details. However, it does not specify when not to use this tool versus other siblings like search_mods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses search behavior, node_type filter, return fields (id, stats, allocated, pathDist), and notes pathDist's condition. Lacks mention of rate limits or authentication, but read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences), front-loads the purpose, and conveys essential information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely details return fields), the description covers key outputs and usage. However, it lacks mention of pagination or the limit parameter's effect, which is a minor gap for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains node_type with allowed values and query usage ('by node name or stat text'), but does not describe the limit parameter or query format. Partially covers the parameters.
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 uses a specific verb ('Search') and resource ('active build's passive tree'), clearly distinguishing from siblings like get_passive (retrieval by ID) and optimize_passives (optimization).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool for searching and then using the id with alloc/dealloc, but it does not explicitly state when not to use it or compare to search_items or search_mods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read-only reporting action, which is transparent. However, it could mention if the data is cached or if there are any side effects, but the simple nature makes a high score appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the key action and resource. No redundant or extra information.
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 the tool's simplicity (zero parameters, output schema exists), the description fully covers what the tool does. It is complete for an agent to understand its purpose and output.
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?
There are zero parameters, and the input schema covers 100% (empty). Per the baseline for 0 params, a score of 4 is suitable since the description adds no parameter info, but none is needed.
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 clearly states the tool reports 'bundled game-data corpus version and entity counts,' using a specific verb ('report') and resource. This distinguishes it from siblings like 'check_data_version' and 'update_corpus'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines are provided. The description implies use when you need corpus version or entity counts, but it does not mention when not to use or suggest alternatives. For a zero-parameter tool, guidance is minimal but acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the tool is read-only, returns item and craftSteps, and describes the gambling nature of corruption. It explains the inclusion of runes, essences, and corruptions, but does not detail all potential side effects or limitations beyond 'theoretical best-in-slot with idealized rolls.'
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 description is somewhat lengthy but well-structured: first sentence states purpose, then details the extra systems, then explains key parameters and return. It front-loads the core idea and maintains clarity, though some sentences could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, 1 required, output schema present), the description covers the main aspects: tool purpose, key parameters, return format (item + craftSteps), and behavioral notes (read-only). The required 'slot' parameter is not explained, but its purpose is implied. Overall, it provides sufficient context for an agent to use the tool correctly.
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?
Despite 0% schema description coverage, the tool description adds significant meaning: it explains rune_sockets, distinguishes metric vs goals, and mentions essences/corruptions. However, parameters like 'base' and 'rolls' are not explicitly described. Overall, it compensates well for missing schema descriptions.
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 clearly states it crafts the best-in-slot item using a full crafting system beyond a plain rare, distinguishing itself from optimize_item by adding runes/essences/corruptions. The verb 'craft' and resource 'best-in-slot item' are specific, and it explicitly contrasts with a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (for full crafting beyond rare optimization) and explains key parameters (metric/goals, rune_sockets). It compares directly to optimize_item, offering context, but does not list all alternatives or explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers key behaviors: it describes the goal format, and states returns per-goal pass/fail with actual values and overall pass. It lacks discussion of error handling or side effects, but is sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) with a clear front-loaded purpose. The example is helpful without being verbose. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter with nested object) and presence of an output schema, the description adequately explains behavior and return value structure. It could mention output format details if schema were absent, but it is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and no details for the 'goals' parameter. The description fully compensates by explaining the format (bare number or object with min/max) and providing an example, adding essential meaning.
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 clearly states the tool checks an active build against numeric goals, using a specific verb and resource. It distinguishes from siblings like get_build or compare_to by focusing on goal validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example but does not explicitly state when to use this tool versus alternatives (e.g., compare_to). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses offline/deterministic nature and attribution requirements. No annotations provided. Lacks details on error handling or performance, but sufficient for a read-only knowledge tool.
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?
Well-structured and concise. Front-loaded purpose, followed by return details, examples, and fallback instructions. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single param and output schema, description covers key aspects: data source, attribution, curated topics, and fallback. Complete enough for agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'topic' with 0% schema description coverage. Description adds example topic values (resistances, ailments, etc.) but does not explain format or constraints. Partially compensates for low coverage.
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?
Clearly states the tool explains a Path of Exile 2 mechanic using offline deterministic corpus. Specifies return value (principle + wiki page) and lists example topics. Distinguishes from siblings like search_mechanics and lookup_mechanic.
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?
Explicitly provides when-not-to-use and alternatives: 'If nothing matches, use search_mechanics to browse, or lookup_mechanic to fetch a page live from the wiki.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It indicates a read-only listing operation (lists candidates, no mention of modifications), and notes that the results are ordered by relevance but lacks support magnitudes. It does not explicitly state non-destructiveness or permissions, but the listing nature implies safety. A score of 4 reflects good transparency for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and the second sentence adds critical usage guidance without any unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema (not shown), the description covers the core function, differentiation, and a limitation. It does not mention error handling or prerequisites, but the context is sufficient for an agent to use the tool correctly. A score of 4 reflects adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the parameters beyond mentioning 'for a skill' (implying the skill parameter). The `limit` parameter is not described at all. With low coverage, the description should compensate, but it fails to provide meaningful parameter details, resulting in a score of 2.
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 clearly states it lists support gems for a skill, with curated recommendations and tag-compatible supports ordered by relevance. It also distinguishes from the sibling `optimize_supports`, making the purpose specific and unambiguous.
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 explicitly tells when to use this tool (to list candidates) and when to use the alternative `optimize_supports` (to actually pick the best set). It also explains why `optimize_supports` is needed (the corpus lacks support magnitudes), providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavior: elemental resists include a configurable area penalty, the cap is 75%, and the response includes resistPenalty and a note. This adds context beyond the schema, as no annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. Every sentence provides essential information, and the structure clearly lists the defensive stats in a readable manner.
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 0 parameters, no annotations, and an output schema, the description is complete: it explains what the tool returns and includes critical details like the penalty and cap. No gaps are identified for this simple tool.
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?
With 0 parameters and 100% schema coverage, the description adds value by explaining the output content (stats, penalty, cap). The baseline of 3 is exceeded because the description effectively compensates for the lack of parameter info.
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 explicitly states it provides a 'Defensive summary for the active build' and lists specific stats (life, ES, mana, ward, armour, evasion, block, resistances, TotalEHP). This clearly distinguishes it from sibling tools like get_build_stats or get_build which cover broader aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for defensive evaluation but does not explicitly state when to use this tool over alternatives like get_build_stats or evaluate_build. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses that it returns {ok: false} on unreachable poe.ninja, emphasizes it's a live snapshot and not a recommendation, and specifies scope (ascendancy only). Missing details like potential latency or caching, but still strong.
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?
Description is a single paragraph but well-structured: starts with purpose, then details return data, then usage notes, then error case. Information-dense without being verbose. Slight improvement could break into list for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters and presence of output schema, description covers return shape (ascendancies with share %, trend, sample size) and error case. Leaves no major gaps for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions league defaults to current challenge league and limit defaults to 15, which adds some meaning to parameter names. However, no detailed explanation of parameter behavior beyond value ranges.
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?
Clearly states it retrieves live ascendancy popularity from poe.ninja's ladder snapshot, returning share %, trend, and sample size. Distinguishes from siblings like 'get_build' and 'build_advice' by emphasizing it's context, not a target, and covers ascendancy distribution only.
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?
Explicitly tells when to use: to inform build decisions, not dictate; only steer toward meta when user asks for 'strongest'/'popular'/'meta'. Also clarifies it should not override user's stated goal. No implicit usage without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains behavior: lever names are forgiving, custom levers work, and a lever only affects metrics if applicable. Good transparency for a read-only tool.
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?
Three sentences, front-loaded with key function. Each sentence adds value, though could be slightly tighter. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no input parameters, and output schema exists, description covers return value and usage nuances adequately. Sufficient for a discovery tool.
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?
No parameters. Baseline 4 is appropriate because there is nothing to add beyond schema coverage (100%).
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?
Describes itself as listing named levers accepted by solve_for and rank_levers for discoverability. Clearly distinguishes from siblings by specifying its role as a helper for those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: 'discoverability' indicates when to use. Provides guidance on forgiving names and custom levers. Lacks explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the output flags the current league, which is a key behavioral trait. For a read-only list tool with no side effects, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It conveys the essential information efficiently.
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 the tool's simplicity (0 parameters, no nested objects) and the presence of an output schema, the description provides complete context: it lists leagues and flags the current one. No gaps.
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?
There are 0 parameters and schema coverage is 100%, so baseline is 4. The description does not need to add parameter semantics, and it does not detract from clarity.
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 clearly states it lists Path of Exile 2 leagues for pricing, with the current league flagged. It uses a specific verb and resource, and the context distinguishes it from sibling tools like get_prices which use leagues as input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned, but the purpose implies it is a prerequisite for pricing queries. The description does not provide exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses affix detection is best-effort and unmatched lines are returned under 'unrecognized'. Tiers and ranges are corpus facts. No annotations exist, so description carries full burden; it does well but could mention potential side effects or data sources.
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?
Concise 4-5 sentences, front-loaded with purpose. Structure is clear but could be slightly tighter without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently covers what is returned (affix tiers, open slots, unrecognized lines). Complete for evaluating drops and planning crafts.
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?
Only one parameter 'text' with 0% schema coverage; description explains it expects in-game clipboard or PoB item text, adding meaning beyond schema. Could specify expected format or constraints.
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?
Description clearly states it parses PoE2 item text and enriches it with mod tiers and open slots. It distinguishes from sibling 'equip_item' by directing to that tool for build impact, making purpose distinct and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it to evaluate a drop or plan a craft, and to use 'equip_item' to see build changes. Provides clear context but could be more explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what signals it reads and that it surfaces a diagnostic for uncomputable layers. No annotations, but the description adequately conveys behavior without contradiction.
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?
Three sentences, front-loaded with the overall purpose. Minor room for trimming but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description covers inputs, processing, and outputs sufficiently for a diagnostic tool.
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?
No parameters exist, so baseline 4 applies. No additional semantics needed.
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 clearly states it reads the active build's signals and points each to its best corpus mechanics page, with a specific verb and resource. It distinguishes itself from siblings like 'explain_mechanic' by focusing on the active build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage: 'Use it when starting/auditing a build to read up before theorycrafting.' No exclusion or alternatives mentioned, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the search is offline, deterministic, and returns specific content. Mentions the licensing requirement. No destructive behavior is relevant, and with no annotations, this provides sufficient transparency for a search tool.
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 description is two sentences, front-loading the core functionality. The licensing note adds necessary context. Could be slightly more concise but is efficient overall.
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 the tool's simplicity, the description covers the return format, corpus source, attribution, and alternative tool. With an output schema present, no further detail on return values is needed. It is complete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explicitly explain the 'query' and 'limit' parameters beyond stating 'full-text search' and implying result selection. It does not mention default values or parameter details, leaving the schema to carry the burden.
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 clearly states it performs full-text search on a bundled wiki corpus, returning titles, snippets, and source links. It distinguishes itself from the sibling tool lookup_mechanic, which fetches from the live wiki.
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?
Explicitly states when to use this tool (offline corpus search) and when to use lookup_mechanic (for pages not bundled). Also mentions licensing attribution, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: 'Engine-computed pass/fail for: elemental resists capped...' It discloses the criteria and clarifies that the buffer is advisory. It implicitly indicates read-only behavior by suggesting verification in-game. More explicit statement about side effects could improve, but it's adequate.
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 description is well-structured and front-loaded with the primary purpose. Every sentence adds value, though the paragraph could be slightly more concise. The length is justified by the complexity of the readiness check.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to explain return values. It covers the main criteria and provides enough context for the agent to understand the tool's function. A brief mention of the output format would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so excellently: explains that min_ehp and min_dps are thresholds, provides context for typical values ('~17–20k EHP'), and advises to adjust based on content. This adds significant meaning beyond the raw schema.
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 clearly states the tool's purpose: 'Gate a build against the endgame/pinnacle checklist — defense beyond raw EHP, plus a DPS bar.' It identifies the specific action (checking readiness) and resource (build against checklist), differentiating it from sibling tools like 'evaluate_build' or 'get_defenses' which are more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after building, before pinnacle content. It advises to set thresholds to the player's content and to verify additional mechanics in-game. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses state changes (overwrites active build) and warns about aspirational builds with custom mods, over-budget trees, or uncapped resists. This provides sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three concise paragraphs. It front-loads the purpose, then details parameters, return values, and caveats. Every sentence adds value without redundancy.
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 one parameter and an output schema (implied), the description covers input formats, output summary, side effects, and import caveats. It is complete for effective tool invocation.
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?
The single 'source' parameter lacks a schema description, but the description compensates by detailing what values it accepts: PoB code, links, or raw XML. This adds essential meaning beyond the bare schema.
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 clearly states the tool imports a Path of Exile 2 build for analysis and theorycrafting, listing specific input formats (PoB code, links, raw XML). It distinguishes from siblings like 'export_build'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates acceptable source formats and indicates that the imported build becomes the active build. However, it does not explicitly state when to use this tool versus other build-related tools or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return fields and relationship to other actions. Does not mention side effects or permissions, but as a list tool it's likely read-only. Transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first lists purpose, second explains prerequisite, third tells how to use the output. No fluff, front-loaded.
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 no parameters and a simple list operation, the description is complete. It explains return fields and how the tool fits into the workflow (allocation then equipping). Output schema exists, so return values are covered.
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?
Input schema has zero parameters (100% coverage). Baseline for 0 params is 4. Description adds no param info (unnecessary), so score is appropriate.
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 clearly states the tool lists jewel sockets with specific attributes (id, allocated, filled), distinguishing it from siblings like alloc_passive and equip_jewel by explaining the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides workflow guidance: socket must be allocated before a jewel contributes (referencing alloc_passive), and socket id is used with equip_jewel. While not explicitly stating when not to use, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosing behavior. It explains the greedy heuristic, slot coherence, EHP floor, and that it returns per-slot plans plus projections. It also notes the call is computationally heavy, providing critical decision-making context.
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 description is dense but not overly verbose. It front-loads the core purpose and trade-off, then explains parameters and behavior. Every sentence adds value, though it could be slightly streamlined without loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema, the description covers the main return values (per-slot plan, DPS/EHP/resists). It does not detail error handling or edge cases, but overall provides sufficient context for an agent to use the tool correctly.
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 0%, but the description explains dps_weight (0..1 tilt), auto_base (fills empty slots), min_ehp (survivability floor), and metric (special handling for minion/DoT/trigger). It does not detail rolls or slots parameters, but adds significant value for most parameters.
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 clearly states the tool plans a whole gear set maximizing damage while capping resistances, with a specific focus on cross-slot trade-offs. It distinguishes itself by mentioning it builds from scratch and leaves weapons unchanged, making the purpose very specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (initial gear planning, from scratch) and mentions it is a heavy call (~10-20s). However, it does not explicitly state when not to use or compare directly with siblings like 'scaffold_gear', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: applies each lever at the given unit, measures real Δmetric, ranks high→low, and uses engine computation. It also mentions that levers are measured independently. No destructive behavior is indicated, and the transparency is adequate.
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 description is moderately concise and well-structured. It front-loads the core purpose and then provides details. While it is somewhat long, every sentence adds value (purpose, usage, examples, caveats). Minor redundancy ('Every value is engine-computed') could be trimmed but overall effective.
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 the absence of annotations and the presence of an output schema (not shown but stated), the description is complete. It explains the tool's functionality, input parameters with examples, the greedy nature, and the output as a ranked list. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must add meaning. It does so thoroughly: explains 'metric' as the metric to rank, 'unit' as the amount of investment (default 10), and 'levers' as custom-mod templates with '{}' and gives examples. This significantly enriches the bare schema.
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 explicitly states the tool's purpose: 'Rank which stat levers give the most `metric` per unit on the active build', using a specific verb (rank) and resource (stat levers). It clearly distinguishes this as a direction-finder for investment, setting it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance, including default behavior ('Defaults to a broad damage+defense set') and customization ('pass build-specific `levers`'). It also warns about independent measurement ('Greedy/marginal — levers are measured independently, so verify combined picks'). However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses that the tool replaces the slot, returns updated stats, and checks hand-written items for legal affixes, returning illegalAffixes and legalityWarning. This fully informs the agent of side effects and edge cases.
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 description is multi-sentence but well-structured, with the main purpose first. Each sentence adds valuable information (replacement behavior, slot details, legality checks). Slightly verbose due to warnings, but no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and an output schema, the description covers the main behavior, return values, and a key warning about hand-written items. It does not mention error cases or prerequisites, but given the complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning: it explains that 'raw' is Path of Building item text, and 'slot' optionally forces the slot, with a detailed warning about paired slots and default behavior. This goes far beyond the schema's bare property names.
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 clearly states the verb 'Equip', the resource 'an item on the active build', and the input format 'raw Path of Building item text'. It distinguishes this from sibling tools like equip_jewel and unequip_item by specifying the exact operation and source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance: it replaces the current slot, explains slot inference, warns about paired slots (Ring 2/Weapon 2), and advises using explicit slot to avoid overwriting. It also distinguishes between hand-written and ground gear usage. Though it doesn't explicitly state when not to use it, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses live network call, returns short extract + source link, may be outdated, returns {available: false} if unreachable, single user-triggered, read-only, never sends build data. No annotations provided, so description carries full burden and covers well.
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?
Fairly concise with line breaks. Every sentence adds value, but slightly redundant (e.g., 'live' mentioned twice). Could be tighter.
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 output schema exists, description doesn't need to detail returns, but it mentions extract + source link and error case. Single parameter, good coverage of context. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'topic' with no schema description (0% coverage). Description explains its purpose ('mechanic/skill/item explanation') but lacks examples or format constraints. Baseline 3 with some compensation for low coverage.
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 clearly states the tool fetches a mechanic/skill/item explanation from the PoE2 Wiki live. It distinguishes itself from siblings explain_mechanic and search_mechanics by noting it's a live network call.
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?
Explicitly says 'use this only when explain_mechanic/search_mechanics don't have the topic in the bundled corpus,' providing clear when-to-use guidance and naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses algorithm (greedy, bounded search), respects mod restrictions, returns theoretical best-in-slot (not market price), warns about resistance caps, and reports attainability. No annotations provided, so description carries full burden—excellent transparency.
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?
Front-loaded with purpose. Though lengthy, every sentence adds value for a complex tool. Could be slightly tighter, but acceptable.
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 complexity (8 params, no schema descriptions, no annotations, output schema exists), the description covers algorithm, return values, edge cases, and cross-references. Complete for agent invocation.
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 description coverage is 0%, but description explains most parameters: slot, metric, base, rolls, thorough, goals, and partially keep_resists_capped. Ilvl is not explicitly described, but its default (82) is common. Adds significant meaning beyond schema.
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?
States clearly: 'Craft the best-in-slot rare for a `slot` — one `metric`, or a weighted blend via `goals`.' Specific verb+resource+scope. Though sibling tools like optimize_jewel exist, this description distinguishes item slot optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: when to pass goals vs. single metric, how base defaults, and recommendations to verify price with get_prices. Lacks explicit 'when not to use', but the guidance is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: explains the algorithm (marginal gain ranking, mod independence), states the tool is read-only ('the build is restored'), and describes what the output is (a jewel to socket with equip_jewel). No contradictions.
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 description is concise yet informative, covering purpose, algorithm, usage, and output in a few sentences. It is well-structured, starting with the main action and providing details. Slightly longer than necessary but every sentence adds value.
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?
For a tool that optimizes jewels, the description covers all necessary aspects: what it does, how it works (algorithm), usage instructions (base selection), limitations (no radius jewels), output (jewel to equip), and side effects (read-only). With an output schema present, the description complements it well.
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?
The description adds meaning to parameters: it explains the base parameter (Emerald=dex, etc.) and mentions metric/goals as a weighted blend. However, rolls is not explained. Given 0% schema coverage, the description compensates well but not fully.
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 clearly states the tool's purpose: 'Craft the best-in-slot rare JEWEL for the active build'. It uses a specific verb ('Craft') and resource ('rare JEWEL'), distinguishing it from sibling tools like equip_jewel (which sockets) and optimize_item (which optimizes non-jewel items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: how to pick a base matching the socket's attribute (Emerald=dex, etc.), and explicitly states Radius/Time-Lost jewels are not modelled. It implies using equip_jewel after. However, it does not explicitly exclude other scenarios like non-rare jewels or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool is read-only ('the build is restored'), explains the greedy algorithm, candidate pool selection by measurement not tags, and that it is not a global optimum. This provides complete transparency about behavior.
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 description is moderately concise, front-loading the purpose and then detailing algorithm and parameters. Each sentence adds value, though some technical jargon could be streamlined. It is well-structured with logical flow.
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 the presence of an output schema, the description does not need to explain return values. It covers purpose, behavior, parameter usage, and next steps. It explains read-only nature and algorithm details, making it complete for a tool of this complexity.
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?
The schema has 0% description coverage, so the description must compensate. It explains the interaction between goals and metric, gives an example of goals format, and describes the candidates parameter. However, max_supports (default 5) is not explicitly linked to 'sockets full' and metric's default is noted but not elaborated.
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 clearly states 'Choose the best support-gem set for the active main skill (engine-measured).' It uses a specific verb and resource, distinguishes from sibling tools like find_supports_for (which lists supports) and set_skill (which applies), and adds scope (active main skill).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool by stating 'Supports are usually a build's biggest more multiplier' and instructs 'Apply the result with set_skill.' It explains parameter choices (e.g., goals for multi-objective, candidates for wider search) but does not explicitly contrast with alternatives like optimize_item or find_supports_for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool clears the specified slot and which slots are valid, but does not mention behavior if the slot is already empty or any side effects. Still adequate for a simple, common operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential. Front-loaded with action verb 'Clear' and immediately gives examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and the presence of an output schema (not visible but noted), the description covers the core action and slot validity. It does not mention return values, but output schema may cover that. Slight gap in not explaining error cases, but overall sufficient for a straightforward tool.
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?
Only one parameter 'slot' with no schema description coverage. The description adds meaning by providing examples of valid slot names (e.g., 'Ring 2'), which helps more than a bare string type. Could be improved by listing all possible slots, but examples suffice.
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?
Clearly states it clears an equipment slot on the active build, with specific examples like 'Ring 2', 'Body Armour'. Distinguishes from sibling tools equip_item and equip_jewel by naming them as alternatives for filling slots.
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?
Explicitly tells when to use (to clear a slot) and mentions valid slots including weapon-swap and jewel sockets. Provides clear guidance on using equip_item/equip_jewel for filling, differentiating usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses that the tool rebuilds locally from RePoE and explains the effect of the parameter. It could add more detail about potential impacts (e.g., time, data loss), but the current description provides reasonable transparency for a specialized utility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loads the purpose, and contains no unnecessary words. Every sentence serves a clear function.
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 the single boolean parameter and presence of an output schema, the description provides sufficient context. It covers the tool's purpose, usage guidance, and parameter semantics, making it complete for effective agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description clearly explains the sole parameter's meaning and effect: 'Pass rebuild_from_source=true to re-fetch RePoE and rebuild the corpus right now.' This adds value beyond the schema.
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 clearly states the tool's action ('Rebuild the game-data corpus locally from RePoE') and distinguishes it from other tools (e.g., it's not a check or info tool). The verb 'rebuild' and resource 'corpus' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Most users don't need this' and provides context (power-user/offline path). It implies when to use (when manual rebuild is needed) and notes the alternative (server auto-updates). However, it does not name a specific sibling tool for the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the exceptional behavior for base types, but does not mention any other traits like read-only or side effects. With no annotations, this is adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with the main purpose, no superfluous words.
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?
Covers all relevant aspects for a single-parameter tool with an output schema: core behavior and edge case.
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?
The description explains the 'name' parameter is the unique item name and clarifies edge-case handling. Given 0% schema coverage, it adds necessary meaning.
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 clearly states the tool returns a unique item's full readable text by name, and distinguishes from get_item by handling base type names.
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?
Explicitly says to use when you have a unique item name, and for base types it directs to get_item instead of returning null.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: these builds are 'offline, deterministic', 'deliberately diverse set', and returns only summary data (VERIFIED DPS/EHP, archetype tags, lever) with 'deliberately nothing to copy'. This goes beyond typical list tools and compensates for lack of annotations.
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 description is well-structured with a clear first sentence stating the purpose, followed by details on usage and return values. It is slightly verbose but every sentence adds value; the front-loading is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately avoids detailing return structure but still mentions key fields. It covers purpose, usage, and parameter semantics adequately for a browse tool. It does not discuss pagination or errors, but these are minor gaps.
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?
With 0% schema description coverage, the description adds significant meaning for the 'query' parameter by listing acceptable filter categories (class, ascendancy, skill, element, etc.). The 'limit' parameter is not explicitly described, but its default value is given in the schema, and the description implies it controls result count.
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 clearly states the tool browses 'engine-verified reference / CALIBRATION builds' and explains they are 'corpus — offline, deterministic'. It distinguishes from sibling tools by emphasizing these are not templates and should not be copied or recommended, contrasting with tools like get_build or get_meta_builds that might provide full builds.
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?
Explicitly states when to use ('to calibrate') and provides strong negative guidance: 'never copy, export, or recommend one wholesale when a user asks for a build'. It instructs to 'build to the USER's stated goal and use these to sanity-check it', giving clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses algorithm traits: greedy search (not global optimum), separate ascendancy pool, reset deallocation behavior, and potential skipping of required nodes. It also notes return includes per-step gains and remaining points.
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 description is comprehensive but somewhat lengthy; it is well-structured with clear sections for goal modes and parameter explanations. A bit more conciseness would improve, but it remains efficient.
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 the complexity of 7 parameters and an output schema, the description covers all key aspects: goal modes, constraints, behaviors, and return format. It provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds rich semantics for all parameters: explains metric values, goals as weighted mix, require and reset behavior, and points as budget cap vs full allocation. It compensates fully for lack of schema documentation.
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 clearly states the tool greedily allocates passive points to maximize a goal on the active build. It distinguishes from siblings like alloc_passive and search_passives by focusing on optimization rather than manual allocation or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool, detailing three goal modes, the require and reset parameters, and the points default. It implicitly distinguishes from manual allocation tools but does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states 'Read-only — every probe is snapshotted and restored,' and explains the non-additivity behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, with a clear front-loaded purpose statement. Every sentence adds value—covering mechanism, read-only safety, non-additivity, empty slots, and cross-references to other tools. No fluff.
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 the presence of an output schema (true), the description doesn't need to explain return values. It covers usage context, behavioral notes, and cross-references fully, making it complete for a ranking tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions metric and goals with examples ('TotalDPS' and weighted blend), and implies slots and rolls. However, with 0% schema coverage, it could explicitly define each parameter (e.g., what 'rolls' or 'top' means). Still, it adds some value beyond the schema.
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 clearly states the tool's purpose: 'Rank gear slots by upgrade potential — what should I craft/upgrade next?' It uses a specific verb ('rank') and resource ('gear slots'), and distinguishes from sibling tools like optimize_item by explaining the different use case.
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?
Provides explicit guidance on when to use (for prioritization), when not (gains not additive, re-run needed), and alternatives (optimize_item for empty slots, get_prices for cost). It warns about non-additivity and recommends a workflow: 'recraft the top slot, equip it, then re-run.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavior: group added enabled, effect reflected in stats, main skill preserved, spirit reservation impact, and the pitfall of inflating FullDPS with in_full_dps. Exceptionally thorough.
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?
Somewhat verbose but every sentence is informative. The description is front-loaded with the core purpose, then flows into format, behavior, and parameter guidance. Could be tighter but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, format, parameter semantics, and usage guidance. Lacks mention of prerequisites (e.g., build must be loaded) or error handling. Still very complete given the tool's complexity and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains both parameters: skill (paste format, newline support) and in_full_dps (boolean, with clear guidance on when to use True/False). Adds significant meaning beyond schema.
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 clearly states it adds an ENABLED secondary skill group without changing the main skill, listing specific types (aura, herald, persistent buff). This distinguishes it clearly from sibling tools like set_skill.
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?
Explicitly describes when to use: for auras/heralds/buffs, and when to set in_full_dps=True (only for a second damage skill). Also references paste format from set_skill and advises checking spirit reservation with get_build_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool compares to distributions of real high-end builds, reports scaling levers, and is non-destructive (calibration check only). It sets expectations about what the tool does and does not do.
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 description is moderately long but well-structured, with a clear core statement followed by details and a caution. Every sentence adds value, though it could be slightly tighter.
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 no parameters and an output schema, the description fully covers the tool's purpose, behavior, and output semantics. It explains what the tool returns (which levers to scale) and provides context for interpretation.
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?
The input schema has no parameters, so description does not need to add parameter details. It implicitly uses the active build context, which is clear from the description.
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 clearly states the tool calibrates the active build against a verified reference set, comparing DPS/EHP and reporting scaling levers. It distinguishes this from copying references and from sibling tools like rank_levers and build_advice.
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 explicitly states when to use this tool (calibration check) and when not to (not a license to copy). It directs to use rank_levers if a number is low, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses state modification (leaves build loaded), algorithm details (seed levers, commit-and-max, iterate passes), time estimates (~1-3 min), and limitation (cannot model energy-meta triggers). Comprehensive.
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?
Description is dense and well-structured: high-level purpose, process, parameters, limitations. A bit long but each sentence adds value. Could be slightly more concise but still clear.
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 high complexity, no annotations, and 63 sibling tools, the description thoroughly covers prerequisites, state effects, parameter roles, time cost, and limitations. Output schema exists further aiding completeness.
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 has 0% description coverage, but description explains many parameters (levers, try_uniques, crafting, uniques, archetypes, parallel, passes). However, metric, min_ehp, tier, converge, and combat are not explained. Good coverage but not complete.
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?
Clearly states 'Assemble a complete, engine-verified, high-DPS build for the ACTIVE archetype', distinguishes from greedy per-slot tools, and uses specific verbs like 'synthesize' and 'commit'. Purpose is unmistakable.
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?
Explicitly says to set up archetype first before calling, contrasts with per-slot optimizers, and recommends follow-up with apply_combat_profile and validate_build. Provides clear when-to and what-next guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses re-rooting of passive tree, non-clearance of existing gear/skills/config, and return of stats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main action, then details. No redundancy or wasted words.
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?
Output schema exists, so return values are covered. Description explains purpose, side effects, and usage context completely for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains both parameters with examples ('class_name' as base class, 'ascendancy' as one of its ascendancies), adding significant meaning beyond schema.
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?
Clear verb+resource: 'Set the active build's character class and (optionally) ascendancy.' Distinguishes from sibling 'new_build' by noting it does not clear existing data.
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?
Explicitly states when to use (to re-root passive tree) and when not ('call new_build first if you want a clean slate'). Provides context for subsequent operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses binary search on real engine, computed result, return behavior (unreachable and alreadyMet flags), and limitations.
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?
Well-structured with topic sentence, details, example, scope, and follow-up steps. Slightly verbose with the example but largely efficient.
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?
Covers purpose, methodology, input semantics, return behavior, and post-use actions. Output schema exists but description already explains return values, making it complete.
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 has 0% coverage, but description explains lever (named or custom mod template with {}), metrics (increasing), and tolerance default. Adds significant meaning beyond schema.
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?
Clearly states it solves for modifier magnitude to meet a stat target. Uses specific verb-resource pair and distinguishes from siblings like optimize_passives or evaluate_build.
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?
Provides explicit when-to-use, scope (single lever, increasing metric), and when-not-to-use (no survivability/cost balancing). Gives alternatives for verification: get_defenses, evaluate_build, search_mods, find_supports_for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool modifies engine state (sets enemy condition levers) and returns resulting stats. Warns that assumptions may inflate DPS if not aligned with build. No annotations exist, so description carries full burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: starts with main action, explains motivation, gives important caveats. No redundant sentences; every sentence adds value. Length is appropriate for the complexity.
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 no annotations and 7 parameters, the description covers purpose, when to use, behavioral implications, parameter meaning, and output expectation. It is sufficiently detailed for an AI agent to use correctly.
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 has 0% description coverage, but the description explains the boolean toggles as 'toggles' that represent build assumptions. It groups them together and provides context for each via examples (shocked, cursed). Could benefit from listing each parameter's role explicitly, but overall adds meaningful guidance.
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 clearly states the tool applies a realistic boss-combat profile to reflect actual fight DPS. It explains why, referencing engine defaults and distinguishing from bare 'get_build_stats'. No ambiguity, and it differentiates itself from siblings like 'get_build_stats' and 'set_config'.
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?
Provides explicit guidance: turn off toggles the build cannot sustain, explains tiers (None/Boss/Pinnacle/Uber). Tells when not to use (if build doesn't produce the effect). This helps the agent avoid overstating DPS.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden of disclosing behavior. It clearly states that using this tool will clear gear, skills, passives, and config, which is a destructive action. This is sufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences. The first sentence clearly states the purpose, and the second provides usage guidance. Every word earns its place, with no redundancy.
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?
For a tool with no parameters and a clear purpose, the description covers everything needed: what the tool does, when to use it, and how it relates to sibling tools. Since an output schema exists, the description does not need to explain return values.
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?
The tool has zero parameters, and schema coverage is 100% (trivially). With no parameters, the baseline is 4, and the description does not need to add parameter info. It correctly provides no extraneous parameter details.
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 uses the clear verb 'Reset' and specifies exactly what is cleared: 'gear, skills, passives, and config.' It distinguishes itself from sibling 'set_class' by explaining the key difference, making the purpose specific and unambiguous.
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 explicitly states when to use the tool ('to start a build truly from scratch mid-session') and contrasts it with 'set_class,' which keeps existing data. It also provides a recommended sequence ('new_build first, then set_class → set_level → …'), offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: replacement of skill group, preservation of other groups, cosmetic nature of support gems in PoE2, error handling (returns ok:false on failure), and return of updated stats plus ProjectileCount/dpsNote.
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 description is somewhat lengthy but well-structured: starts with purpose, then format, then side effects, then fallback, then return. Every sentence adds value, though minor redundancy could be trimmed.
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 one parameter, no annotations, and an output schema (so return values explained), the description covers all necessary aspects: format, behavior, error handling, return values, and distinguishes from sibling. It is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'skill' has 0% schema description coverage, but the description compensates with detailed format explanations: examples, accepted delimiters, default level/quality for supports. This adds crucial meaning beyond the input schema.
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 clearly states it sets the active build's MAIN skill (gem + support gems) in PoB paste format. It uses a specific verb 'set' and resource 'active build's main skill', distinguishing it from sibling 'add_skill_group' which handles persistent buffs.
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?
Explicitly tells when to use versus not: 'For persistent buffs, use add_skill_group.' It also notes that this REPLACES the current main skill group while preserving auras/heralds/buffs added via `add_skill_group`. Additionally, it describes the fallback behavior on parse failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: it adds resistances below target_resist, a hit pool based on the pool parameter, only fills empty slots, and produces placeholder baseline items. It clearly states the items are not real or optimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear one-sentence summary. The second paragraph efficiently adds parameter details and workflow context without fluff. Every sentence adds value.
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 the output schema exists, the description doesn't need to explain return values. It covers purpose, parameters, workflow, and limitations thoroughly, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all three parameters: pool (auto, life, energy_shield, none), target_resist (default 75, ignores already capped), and slots (limits which slots, default all). This adds substantial meaning beyond the schema.
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 clearly states the tool fills empty armour/jewellery slots with placeholder baseline gear, specifying verb 'Fill', resource 'empty armour/jewellery slots', and qualifiers 'placeholder baseline'. It distinguishes from sibling tools like equip_item and evaluate_build by noting it handles only defensive gaps and is not for real gear.
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 provides explicit usage guidance: use it to complete a build's defenses, then follow up with get_defenses/evaluate_build and get_prices. It also states the assistant still chooses weapon/offense via equip_item and warns never to present scaffolded gear as finished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![poe2-build-mcp MCP server](https://glama.ai/mcp/servers/MaxWilk/poe2-build-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MaxWilk/poe2-build-mcp)

Score Badge

Copy to your README.md:

[![poe2-build-mcp MCP server](https://glama.ai/mcp/servers/MaxWilk/poe2-build-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MaxWilk/poe2-build-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MaxWilk/poe2-build-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server