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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that pre-fetched reviews cause other filtering parameters to be ignored, and that filterOfftopicActivity defaults to false to show all reviews including controversies. However, it doesn't mention rate limits, API call behavior, or what happens when fetching fails. The description adds some behavioral context but not comprehensive.

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

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

The description is a single, focused sentence that front-loads the core purpose and then lists key capabilities. It's concise and every phrase adds value. It could be slightly more structured (e.g., separating the core function from optional features), but it's efficient and readable.

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 complexity (9 parameters, no output schema), the description covers the main capabilities and important behavioral notes (pre-fetched reviews, filtering behavior). It doesn't explain return value structure, but since there's no output schema, that's a gap. However, the description is reasonably complete for an agent to understand what the tool does and when to use it.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters. The description adds context about the pre-fetched reviews parameter ('Useful to avoid duplicate API calls') and clarifies that filtering parameters are ignored when pre-fetched reviews are provided. However, most parameter semantics are already in the schema, so the description adds marginal value beyond it.

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

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

The description clearly states the tool's function: 'Fetch and analyze Steam game reviews to extract sentiment, common themes, and key insights.' It uses a specific verb ('analyze') and resource ('Steam game reviews'), and distinguishes itself from sibling tools like fetch_reviews by combining fetching with analysis. The mention of optional topic drill-down, time-bounded analysis, and pre-fetched reviews further clarifies its scope.

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

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

The description implies when to use this tool: when you need sentiment, themes, and insights from reviews, rather than just raw reviews (fetch_reviews). It also mentions the pre-fetched reviews option to avoid duplicate API calls, which is a clear usage hint. However, it doesn't explicitly state when NOT to use it or name alternatives like fetch_reviews for raw data needs.

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, and it delivers useful behavioral context: bodies retain Steam's raw markup, truncation/malformed states are reported, and author labels do not imply verified roles. It does not cover auth, rate limits, or pagination behavior, but the disclosed output caveats are genuinely informative.

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 tightly scoped sentences, each with a distinct purpose: the operation, the output/truncation behavior, and an important interpretation caveat. The main action is front-loaded and there is no filler.

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

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

Given there is no output schema, the description adequately explains the return characteristics (raw markup, truncation/malformed flags) and the scope of the announcements. Minor gaps remain around pagination behavior and sorting, but the core information needed to call and interpret the tool is present.

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

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

Schema description coverage is 100%, so the schema already explains appId, limit, and cursor. The description reinforces the app-scoped behavior and the notion that content length can be truncated, but it does not add meaningful parameter-level meaning beyond what the input schema provides.

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

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

The description names a specific verb and resource: 'Fetch official Steam Community announcements for one app' and adds concrete content ('patch notes and hotfixes'). This clearly distinguishes it from siblings like fetch_reviews or search_app_discussions, even without naming them explicitly.

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 no guidance on when to use this tool instead of sibling tools, such as search_app_discussions or fetch_discussion_thread. It implies the use case (needing official announcements for one app) but gives no alternatives, exclusions, or conditions.

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?

It discloses experimental status, a 50-reply cap, a 20,000-character post cap, truncation flags, and the fact that Steam markers are not proof of employment. It also warns that status/reason/pagination should be checked for blocked or partial evidence—far beyond what the annotations already state.

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 purpose is front-loaded and the sentences are information-dense. It is longer than minimal because of important caveats about markers, verification, and pagination, but each sentence earns its place; a few could be tightened.

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

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

With no output schema, the description carries the burden of explaining return fields, and it does: identifier, title, opener, up to 50 replies, text caps, links, markers, timestamps, deleted status, and truncation flags. Pagination semantics and failure/partial-evidence checks are also covered, making the tool safely invocable.

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 meaning by explaining that the page parameter defaults to 1 and that a search-match fragment does not select the reply page, plus noting that IDs come from the discussion identifier.

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

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

The description names a specific verb ('retrieval') and resource ('one public Steam Community discussion page') and explicitly identifies the required IDs (app, forum, thread). It also draws a boundary against 'an arbitrary URL', which helps distinguish it from search_app_discussions even without naming the sibling.

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: the tool requires app/forum/thread IDs, defaults to page 1, and requires manual pagination. It does not explicitly name sibling tools or state when to avoid this tool, so it stops short of a 5.

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

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

With no supplied annotations, the description carries the behavioral burden. It does describe return contents (review text, author info, timestamps, voting data) and mentions time-bounded queries and review-bomb filtering, which is useful. It does not disclose rendering error behavior, rate limiting, or that the operation is strictly read-only beyond the word 'fetch'.

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

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

The description is compact and front-loaded, with each sentence adding a distinct piece of value: what is fetched, what is returned, and which special capabilities are supported. Some wording such as 'actual' and 'advanced' is slightly vague but harmless.

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 10-parameter tool with no annotations and no output schema, the description covers the core purpose and return contents but leaves details like cursor-based pagination flow and response shape to be inferred. The schema's high coverage softens this gap, but the description alone is not fully self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters. The description adds high-level categories like filtering and pagination but does not add meaning to individual parameters beyond what the schema states.

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

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

The description names a specific verb and resource ('Fetch actual user reviews for a Steam game') and differentiates this tool from siblings like search_steam_games, get_game_info, analyze_reviews, and discussion tools by emphasizing raw review data, review text, pagination, and review-bomb filtering.

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

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

The intended use is implied clearly: use this when you need raw user reviews with filtering and pagination. However, it never explicitly names alternatives or explains when to use analyze_reviews or get_game_info instead, so the routing guidance is implied rather than explicit.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure, and it does so extensively. It explicitly warns that missing notices do not prove absence of requirements, the server does not infer launcher or DRM behavior, store categories are unverified declarations, and enrichment failures produce warnings without losing base data. It also notes optional fields like system requirements and DLC. This is exceptional transparency for a 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.

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

The description is long but every sentence carries meaningful information. It is front-loaded with the primary purpose, follows with a structured list of output categories, then detailed caveats. The text is not redundant and avoids filler; the length is justified by the tool's complexity. One minor drop from 5 because the caveats section is somewhat verbose but 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?

Given 8 parameters and no output schema, the description thoroughly explains what information will be returned and clarifies optionality and failure modes. It covers the main output categories and acknowledges the risk of enrichment errors. It could be more specific about the exact response structure or rate limitations, but for a data-retrieval tool it is quite 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 description coverage is 100%, so every parameter (appIds, country, criteria, language, includeDlc, includeStats, includeRequirements, includeCurrentPlayers) already has a clear description. The tool description adds minimal parameter-specific detail beyond restating that filtering is supported and that some fields are optional. No extra meaning is provided beyond the schema, so the baseline score of 3 stands.

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 ('Get detailed information about one or more Steam games by AppID') and specifies the optional country/language parameters. It enumerates the exact categories of returned data (regional quote, DRM notices, review stats, Steam Deck compatibility, etc.), making it distinct from siblings like search_steam_games (which searches) and fetch_reviews (which focuses on review content). This is a specific and unambiguous 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 provides no guidance on when to use this tool versus its siblings (e.g., search_steam_games, fetch_reviews). It does not mention alternatives, use cases that would favor a different tool, or exclusions. While it states what data it returns, an agent must infer when this is the right choice without explicit direction.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: results are grouped by thread, matchingPostsObserved counts only the fetched sample, author/date describe each match rather than thread creation, community claims are not verification, and pagination is bounded. This is rich, non-obvious behavior that an agent needs to interpret results correctly.

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 dense but every sentence earns its place: scope, result shape, counting semantics, verification caveat, return fields, pagination behavior, and sibling routing. It is front-loaded with the most important scoping and read-only facts. It could be slightly more compact, but the density is justified given the number of non-obvious behaviors.

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 search tool with no output schema, the description covers the key things an agent needs: what is searched, what the results mean, what is not verified, and how pagination works. It also names the sibling for fetching a thread. The only minor gap is that it doesn't describe the exact shape of the returned provenance/availability fields, but it explicitly names them, which is enough for an agent to proceed.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including defaults, constraints, and the pagination.nextPage hint. The description adds some context by explaining that author/date describe each match and that results are grouped by thread, which helps interpret query results, but it doesn't add much parameter-level meaning 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 states a specific verb ('search'), a specific resource ('public Steam Community discussions for one app'), and immediately distinguishes it from a general Steam search by scoping it to one app. It also names the sibling fetch_discussion_thread and explains the relationship, so an agent can tell this tool apart without opening schemas.

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

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

The description explicitly says this is experimental, read-only, and not exhaustive, and tells the agent to paginate manually. It also names the alternative fetch_discussion_thread and explains that it starts at page 1 even when a match links to a later reply, which is exactly the kind of when-to-use vs alternative guidance that helps an agent avoid mistakes.

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 states the tool returns basic game information and supports batch searches, but does not disclose rate limits, pagination behavior, or what happens with invalid queries. The description is honest but lacks depth on edge cases and operational constraints.

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 with no fluff. It front-loads the core purpose, then explains the single vs batch usage, and ends with the return fields. Every sentence earns its place.

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

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

For a search tool with no output schema and no annotations, the description covers the main usage and return values. It lacks details on error handling, rate limits, or result ordering, but for a simple search tool, the essential information is present. The batch search constraint (max 5 queries) is in the schema, not the description, but the description mentions the non-empty array requirement.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds context by explaining the batch search option and the return fields, but it does not add significant meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 searches for Steam games by name or keywords and returns basic game information (AppID, name, price, preview image). It distinguishes itself from siblings like get_game_info and fetch_reviews by focusing on search and listing basic game data.

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

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

The description explains how to use the tool: provide a single query or a non-empty queries array for batch searches. It implies when to use it (searching for games) but does not explicitly state when not to use it or mention alternatives like get_game_info for detailed info. The batch search guidance is clear and useful.

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