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

With no annotations, the description carries the full burden. It discloses a key prerequisite (player's game stats must be public) and describes the returned data (progress percentage and table). It stops short of discussing error handling or rate limits, but for a read-only tool the most important behavior is covered.

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

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

Three sentences, all substantive and front-loaded. The first sentence states the core purpose, the second covers parameters, and the third describes output and a prerequisite. No filler or redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, no output schema exists, and the description adequately summarizes return values (progress percentage and table). It does not explicitly cover the language parameter (but schema does) and could mention what happens if stats are private, but overall is complete for typical use.

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

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

Schema coverage is 100%, giving baseline 3. The description adds real semantic value beyond the schema: it explains that SteamID can be SteamID64 or vanity URL, gives a concrete AppID example (730 for CS2), and clarifies the status filter options and their meaning. This exceeds mere parameter repetition.

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

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

The description clearly states the tool returns a player's achievement progress for a specific game, using the specific verb 'Returns' and naming both the player and game context. This differentiates it from sibling tools like global achievement stats or game schema.

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

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

The description gives useful parameter usage guidance (status values, SteamID format, example AppID) and notes the public-stats requirement, but does not explicitly say when to choose this tool over siblings like steam_get_global_achievement_stats. Usage context is implied rather than stated as alternatives/exclusions.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It plainly states the core output, but does not mention response format, error behavior (e.g., invalid AppID), authentication requirements, or rate limits. The example adds a helpful scale reference but leaves key behavioral details unaddressed.

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

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

The description is succinct, front-loaded with the main purpose, and every sentence provides value: the core function, the input, a usage guideline, and a concrete example. No wasted words.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers the essential purpose, input, and use case. It omits the exact response structure (e.g., field name), which could matter to an agent, but the phrase 'number of players' and the example mitigate this. Overall it is nearly complete, with only minor gaps.

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

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

The schema already fully documents the appid parameter with type, pattern, and an example, so description-level detail is redundant. The description does reinforce the example (730 for CS2) and adds typical player count context, but it does not add meaning beyond the schema's coverage.

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

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

The description clearly states the verb ('Returns'), the resource ('the number of players currently in-game for a Steam app'), and the required input (AppID). It distinguishes from sibling tools that handle player summaries, friend lists, bans, etc., by focusing specifically on live player counts.

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

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

The description provides clear usage context ('Useful for checking if a game is still active/popular'), which implies when to use it. However, it lacks explicit alternatives or when-not-to-use guidance, though the sibling tools are distinct enough that this is a minor gap.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It explicitly states the 50-friend limit, the extra API calls when resolve_names is true, and the error message for private profiles. This is thorough and sets accurate expectations for the agent.

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

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

The description is three sentences with the primary action first, followed by input details, then options and error handling. Every sentence adds value and there is no redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter read-only tool with no output schema, the description covers inputs, outputs, constraints, and error conditions. It explains return values (friend names and dates) and the optional raw SteamID format, making it complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces parameter meaning (e.g., 'Set resolve_names=false to skip name resolution') but does not add information beyond what the schema already provides for both steamid and resolve_names.

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

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

The description clearly states 'Returns the friend list of a Steam player' and provides specific details about the input (SteamID64 or vanity URL) and output (up to 50 friends with names and friend-since dates). This makes the tool's distinct purpose obvious compared to sibling tools like steam_get_player_summary or steam_get_player_bans.

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

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

The description gives clear context on how to use the tool, including accepted input types and the optional resolve_names flag. It does not explicitly mention alternatives or when-not-to-use scenarios, but the tool's specialized behavior and the note about private profiles provide enough guidance for most cases.

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

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

With no annotations, the description carries the full burden. It transparently lists the returned content (achievement names, descriptions, hidden status, icon URLs, count of stats). It does not disclose potential errors or rate limits, but for a simple read-only getter, the disclosed behavior is sufficient.

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

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

The description is three sentences with no fluff. It front-loads the purpose, details the output, and ends with a usage tip. Every sentence adds value.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description compensates by enumerating the return fields. It also provides usage context. It is complete for a simple schema retrieval tool, though it does not address edge cases like invalid appids or authentication.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description only mentions accepting a Steam AppID, which adds no new information. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns the full schema of stats and achievements for a game. It explicitly differentiates itself from player-specific achievement data by noting it is useful before querying such data, distinguishing it from sibling tools like steam_get_achievements.

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

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

The description provides clear context: it is useful before querying player-specific achievement data. This implies when to use it, but it does not explicitly mention alternatives or when not to use it. A 4 is appropriate because the context is clear without exclusions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal output content (10 easiest/hardest achievements with unlock percentages), but it is ambiguous: first saying 'all achievements' and then '10 easiest and 10 hardest.' It also omits response format details 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.

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

The description is short and front-loaded with the primary action, but there is minor redundancy between 'global completion rates' and 'global unlock percentages,' and the standalone sentence 'Accepts a Steam AppID' adds little beyond the schema.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description gives adequate high-level information. However, it leaves unresolved whether the tool returns all achievements or only the 10 easiest/hardest, and it does not address error conditions or output structure.

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

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

The input schema already provides 100% coverage with the description 'Steam AppID' for the appid parameter. The tool description merely repeats this and adds no additional constraints, formatting details, or usage nuances beyond the schema.

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

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

The description clearly states it 'Returns global completion rates for all achievements in a game' and specifies the output includes the 10 easiest and 10 hardest achievements with percentages. The term 'global' effectively distinguishes it from sibling tools like steam_get_achievements, which are player-specific.

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

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

Provides an explicit use case: 'Useful for understanding how rare an achievement is across all players.' However, it does not mention when to prefer alternatives or give any exclusion criteria, so it stops short of full guidance.

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

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

With no annotations, the description carries the full burden. It discloses the return format (table of game names, AppIDs, playtime), the private-library error, and supports filtering/sorting/limiting. It does not mention rate limits or auth, but the safety profile is clear: this is a read-only operation.

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

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

The description is three concise sentences that front-load the main purpose, then summarize options and behavior. Every sentence adds value and there is no verbosity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description adequately explains the return values (game names, AppIDs, playtime) and the error condition for private libraries. It doesn't detail pagination or rate limits, but for a fairly simple read tool with a 5-param schema, this is reasonably complete.

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

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

The schema already describes all five parameters with 100% coverage. The description largely restates the schema (e.g., default 50, max 500, sorting keys, SteamID format). It adds no new meaning beyond the structured input definitions, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the game library of a Steam player, using the specific verb 'Returns' and identifying the resource (owned games). It differentiates from siblings by focusing on the full library with filtering/sorting options, which is distinct from recently played, friends, or achievements.

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

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

The description provides clear context on input types (SteamID64 or vanity URL) and options, but does not explicitly mention when to use this instead of alternatives like steam_get_recently_played. It gives a strong sense of purpose without explicit exclusions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the input format (single or array up to 100), the type of data returned (ban counts, days since last ban, economy ban status), and implicitly that it is a read-only check. It does not mention potential edge cases or rate limits, but the core behavior is well explained.

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

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

The description is three concise sentences, all of which contain substantive information. It front-loads the core purpose, then covers input and output, with no wasted words or redundant details.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is sufficiently complete. It explains what the tool does, the accepted input shape, and the nature of the return data. It could provide more detail on the exact response structure or error handling, but it is not necessary for an agent to understand the tool's role.

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

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

Schema coverage is 100%, so the description does not need to add much. It reaffirms the schema's parameter description ('single SteamID64 or an array of up to 100 SteamID64s') without providing additional meaning beyond noting it applies to 'one or more Steam accounts.' This adds little value over the schema itself.

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

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

The description clearly states the tool's function with a specific verb ('Checks') and resource ('VAC, game ban, and community ban status'). It distinguishes this tool from siblings (e.g., steam_get_player_summary, steam_get_friend_list) by focusing specifically on ban-related information.

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

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

The description makes it clear this is for retrieving ban statuses for one or more Steam accounts, providing relevant context. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of the explicit when/when-not guidance required for a 5.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals that private profiles return limited data, which is a key behavioral caveat. It also lists all returned fields, setting expectations for output. It does not discuss errors or authentication, but for a simple fetch tool, this is sufficient.

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

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

The description is three sentences: purpose, input syntax, and output/limitation. It is front-loaded with the main action and uses a compact list for return fields. No wasted words, though the field enumeration makes it slightly longer than strictly necessary.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is quite complete: it covers input types, return fields, and privacy behavior. It does not mention error cases or rate limits, but those are minor gaps given the simplicity of the operation.

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

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

Schema description coverage is 100%, so the schema fully documents the 'steamid' parameter. The description repeats the same information (SteamID64 or vanity URL) with examples, adding no new semantic content beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Fetches') and resource ('public profile of a Steam player'), clearly distinguishing it from sibling tools like friend lists, bans, and owned games. It also enumerates the exact data returned, leaving no ambiguity about its function.

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

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

The description clearly indicates the tool is for fetching profile information and explains accepted input formats (SteamID64 or vanity URL), giving practical guidance. It does not explicitly contrast with sibling tools, but the purpose is so distinct that usage context is clear.

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

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

Without annotations, the description carries the full burden. It discloses the output limit (up to 20 games), the data points (recent and total playtime), and the error condition for private profiles. It also mentions the accepted input formats. However, it omits details like authentication requirements, rate limits, and the exact return structure (field names) since there is no output schema.

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

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

The description is three sentences, each adding unique information: the primary action, input formats, and an output/error note. It is front-loaded with the main purpose and contains no redundant or filler content. Ideal conciseness for a simple tool.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no output schema and no annotations, the description covers the essential behaviors: timeframe, output limit, playtime metrics, and private profile error. It is missing the exact return format and auth/rate-limit info, but given the tool's simplicity, it is nearly complete. The absence of an output schema makes the return structure a notable gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema: it reiterates 'SteamID64 or vanity URL' for steamid and 'up to 20' for count, which are already in the schema descriptions. No extra context or usage tips for parameters are provided.

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

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

The description states the specific action: 'Returns games played by a Steam user in the last 2 weeks.' This clearly identifies the resource (recently played games) and differentiates from sibling tools like steam_get_owned_games (full library) and steam_get_current_players (current online status). The output focus on playtime and time window is unambiguous.

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

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

The description provides clear context on when to use this tool: to retrieve games played in the last 2 weeks with recent and total playtime. It also specifies the input format (SteamID64 or vanity URL) and behavior with private profiles. However, it does not explicitly mention alternatives or when not to use it, such as for a full game library or friend lists.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It clearly states the conversion action and the output type (SteamID64), and even adds context about why the output is needed. It does not mention error behavior, but for a simple conversion tool, the core behavior is sufficiently disclosed.

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

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

The description is two sentences, front-loaded with the primary purpose and immediately followed by a practical usage scenario. No wasted words or redundant information.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter conversion tool with no output schema, the description fully covers purpose, usage context, and result. The complexity is low, and the description is sufficient for an agent to select and invoke the tool effectively.

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

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

Schema coverage is 100%, with the parameter description already providing an example ('gabelogannewell'). The tool description repeats this example but adds no new semantic detail beyond what the schema provides. Baseline 3 applies.

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

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

The description uses a specific verb 'Converts' with a clear resource: Steam vanity URL to SteamID64. This distinguishes it from sibling tools, which are all data-retrieval operations rather than conversions.

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

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

The description explicitly states when to use the tool: 'Use this when you have a username like ... and need the numeric SteamID64 required by most other Steam tools.' This provides clear context and implicitly conveys that the output is needed as an input for other tools.

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

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

No annotations are provided, so the description carries the full burden. It transparently lists the return fields and gives an example, but does not disclose potential edge cases like empty results, API rate limits, or authentication requirements. For a read-only search, this is adequate but leaves room for additional behavioral detail.

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

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

The description is a concise two-sentence explanation with an example, containing no filler. The main action and return fields are front-loaded, followed by usage context and a practical example, making every sentence earn its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with two parameters and no output schema, the description covers purpose, return values, and usage context adequately. It could improve by mentioning error/empty handling, but the provided information is largely complete for the task of searching for a game and obtaining its AppID.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by including a concrete example ('search "Counter-Strike" to get AppID 730') and by explaining the purpose of the result (AppID needed for other tools), which goes beyond the schema definitions.

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

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

The description clearly states the action ('Searches for games on Steam by name') and resource (Steam games), and specifies the return fields (AppID, name, price, discount, Metacritic score). It distinguishes itself from sibling tools by focusing on game lookup rather than player/user data, and the example reinforces the purpose.

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

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

The description explicitly states when to use the tool: 'Use this to find a game's AppID before calling other tools that require it.' This provides a clear usage context, though it does not explicitly list alternative tools or exclusion scenarios. The guidance is sufficient for the agent to understand it's a prerequisite lookup tool.

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