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

With no annotations, the description carries the full burden. It usefully discloses that aggregation is server-side and that a metadata-enabled corpus is required (implying failure otherwise), but it omits the read-only nature, response shape, and any limits or rate constraints. Adequate but incomplete for a 12-param 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?

Three sentences: purpose first, then capabilities, then precondition. Well front-loaded and largely waste-free, though the capability enumeration is a fairly long run-on list that 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?

For a 12-parameter tool with no annotations and no output schema, the definition should explain the return shape, but it never does – it only names aggregation types. Combined with the missing alternatives guidance, the picture is serviceable but not complete.

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

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

Schema description coverage is 100%, so the schema documents all 12 parameters (date filters, group_by grain, voted_up sentiment, language list, playtime thresholds, text match). The description's capability list maps loosely onto these but adds no syntax, units, or defaults beyond what the schema already 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 gives a specific verb+resource ('Aggregates a stored Steam review corpus server-side') and enumerates the aggregation outputs it produces. It implicitly separates itself from query_steam_review_corpus by framing the tool as summarization rather than retrieval, but it never names the sibling explicitly to fully disambiguate.

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

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

It states a prerequisite ('Requires a corpus created with review metadata enabled'), which is genuine usage guidance, but it never says when to choose this over query_steam_review_corpus or the corpus-status tools. Usage is implied by the enumeration of capabilities rather than prescribed.

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 provided, so the description carries the burden but does well: it discloses async behavior, server-side persistence, chunking, opaque token return, follow-link behavior for stub announcements, and that data is not exported as files. It doesn't cover error conditions or auth requirements.

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, front-loaded with the core action and return value. The Events & Announcements edge case is useful but slightly detailed; overall efficient with minimal waste.

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 an async tool with no annotations and no output schema, the description covers initiation, return value, follow-up usage, storage semantics, and a special-case handling path. Auth and error behavior are absent but not critical for initial invocation.

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 three parameters including defaults and null semantics. The description adds no extra parameter meaning beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (starts a server-side background fetch), resource (Steam Community topic), and output (opaque identifier). Clearly distinguishes itself from synchronous siblings like get_steam_forum_topic by emphasizing background fetch and chunked storage.

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?

Implies use when a caller needs fire-and-forget fetching followed by status/chunk reads, and names the follow-up tools' purpose implicitly. However, it does not explicitly say when NOT to use this versus get_steam_forum_topic for small threads, leaving some inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the fetch is server-side/background, that the identifier is returned immediately, that data is not exported as files, and that per-review metadata is retained by default. It omits auth requirements, rate limits, and corpus lifetime/eviction, keeping it short of a 5.

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, front-loaded with the action and return value, then two sentences of behavioral context. Nothing is redundant and each sentence carries distinct 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 10-parameter tool with no output schema and no annotations, the description covers the critical unknown an agent would have: what it returns (an opaque identifier) and where the data lives. It doesn't explain how to poll for completion, but that is delegated to get_steam_review_corpus_status.

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, including enums for language, review_type, purchase_type, and traversal_mode. The description's only parameter-linked value is reinforcing the metadata-retention default, which largely restates the include_review_metadata schema text, so 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 names a specific verb chain (starts a background fetch, stores into a corpus, returns an opaque identifier) and pins the resource to Steam reviews. The async/corpus framing cleanly separates it from synchronous siblings like get_steam_review and from the status/query/aggregate tools it feeds.

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

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

The description implies the workflow (call this, then use the returned identifier for status checks, queries, and aggregates), which is genuine usage context. But it never states when to prefer this over get_steam_review or the forum-corpus sibling, and offers no exclusions or prerequisites.

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

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds that the return payload is a name and a package version, which is useful but thin. It says nothing about when the values are captured or any error behavior.

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

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

A single, front-loaded sentence with zero padding. It communicates the complete contract for a no-argument 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?

An output schema is present, so the description does not need to enumerate return fields. For a trivial read-only diagnostic tool, the description is essentially sufficient; a brief note on when an agent should call it would be the only improvement.

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

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

The tool takes zero parameters, so per the baseline there is no parameter semantics to explain. Descriing param behavior would be superfluous here.

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

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

States a specific verb and resource ('Returns the name and package version of the running MCP server process') rather than restating the name. No sibling ambiguity exists — every other tool is Steam-content-oriented, so an agent can instantly route here for server metadata.

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?

No explicit when-to-use guidance or mention of alternatives. The diagnostic/health-check use case is only inferable from the tool's semantics, not stated. No exclusions or conditions are provided.

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 does well: it explains timestamp semantics for original posts vs replies, the ?ctp=N pagination mechanism, and the special behavior where a stub linking to an announcement article is followed to return the full body. It does not discuss rate limits, auth, or error handling, but the behavioral disclosures given are specific and non-obvious.

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 compact sentences that front-load the core purpose. Each sentence adds distinct information (timestamp guidance, supported surfaces, stub-following). It is slightly dense with subordinate clauses but no sentence is wasted.

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 fetch tool with no output schema and no annotations, the description covers purpose, timestamp semantics, pagination, supported surfaces, and a special fallback behavior. Nothing critical for correct invocation or interpretation appears missing.

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

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

Schema coverage is 100%, so all three parameters are documented in the schema, and the description only reinforces the pagination syntax with '?ctp=N'. It adds the note about following stub links which is more behavioral than parameter-specific, and does not elaborate on fetch_all_pages beyond the schema. Baseline 3 is appropriate when the schema already provides full parameter documentation.

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 ('Fetches') and resource ('a public Steam Community topic') and immediately scopes what is returned ('original post and replies'). It is distinguishable from siblings like list_steam_forum_topics (which lists) and get_steam_review (different resource).

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

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

It clearly states what this tool is for and includes a crucial decision rule: use topic.original_post_timestamp rather than listing activity for publication-date claims. It enumerates compatible surfaces (General Discussions, Events & Announcements), giving context on applicability, but does not explicitly name which sibling to use instead for other tasks.

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 discloses the shape of the returned data (manifest plus progress summary) and implies a read-only, non-destructive status check, but says nothing about permissions, rate limits, or what 'progress' values look like.

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

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

A single economical sentence with the verb and resource front-loaded and no filler. It is appropriately sized for a simple status read, though it is not maximally informative.

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 and no annotations, the description should do more work: it names the returned artifacts but not their structure or the meaning of progress states. It is adequate for identifying the tool but leaves the agent guessing about the response contract.

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

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

There is one parameter and schema description coverage is 100%, so the schema already documents corpus_id as an opaque identifier from the corpus tools. The description adds no syntax or format detail beyond that, which matches the baseline for a fully documented single parameter.

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

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

States a specific verb ('Returns') and a concrete resource ('persisted manifest and progress summary') scoped to a server-side Steam Community topic fetch, which separates it from the review-corpus sibling. It is clear and specific, though it never names the sibling tools it complements or contrasts with.

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

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

There is no guidance on when to poll this tool, whether it must follow create_steam_forum_topic_corpus, or when the corpus is considered ready versus still fetching. The agent must infer the workflow entirely from the 'status' framing.

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 usefully discloses that metadata is English-only and that the detailed description is cleaned into plain text for LLM consumption, which is genuine behavioral context. It omits failure modes (invalid appid, missing games) and any rate-limit or auth notes.

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

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

Two tight sentences with the resource and returned fields front-loaded; nothing is wasted. The trailing sentence about plain-text cleaning is mildly ancillary but earns its place as behavioral context.

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 read tool with no output schema, the description names the returned fields and notes the text-cleaning behavior, so an agent knows what to expect. It is adequate, though it could say more about scope limits or errors.

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 appid parameter is already documented. The description only restates it as 'a specific app' and adds no format or value guidance, which is the expected baseline when 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?

States a specific verb and resource (retrieves game metadata for a Steam app) and enumerates the returned fields (release date, developers, publishers, genres, price), which makes the scope concrete. It does not, however, distinguish itself from siblings like get_steam_review, leaving the agent to infer the boundary.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as get_steam_review even though reviews differ from metadata. Usage is only implied by the tool name and field list.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose useful traits: off-topic reviews are included by default, the response always contains a cleaned reviews text array, and review_details is opt-in. However, it omits error behavior, rate limits, and the pagination-termination caveat that actually matters for correctness, so it is only partially complete.

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?

Four sentences, front-loaded with the core purpose, with no filler. Slight redundancy with the schema's parameter descriptions, but the structure is efficient and easy to scan.

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 12-parameter tool with no output schema and no annotations, the description partly compensates by sketching the return shape (cleaned text array plus optional review_details). It still leaves the cursor/next-cursor return contract and multi-page termination behavior underspecified relative to the tool's complexity.

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 12 parameters including cursor, filter, fetch_all, and include_review_metadata. The description restates a few of these (metadata opt-in, off-topic default) but adds no syntax or format detail beyond the schema, matching the baseline.

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

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

States a specific verb and resource ("Retrieves Steam reviews for a specific app"), so the agent knows exactly what it fetches. It does not distinguish itself from related siblings like query_steam_review_corpus or create_steam_review_corpus, which could plausibly serve similar review-oriented needs.

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 never says when to use this raw fetcher versus the corpus-building or query siblings, and offers no exclusions or prerequisites. The mention of manual vs automatic collection hints at modes but not at tool selection, so the agent must infer context on its own.

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 behavioral burden. It says it 'returns' data (implying a read) but does not disclose whether it requires authentication, what happens if corpus_id is unknown, whether progress is live or cached, or how failures are surfaced. Only a minimal read implication is conveyed.

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

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

One efficient sentence that front-loads the action and resource with no wasted words. It could be marginally more structured by noting the return shape, but it is appropriately sized for a simple status endpoint.

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 one parameter at full schema coverage, no output schema, and no annotations, the description is minimally adequate: it states what is returned but not why or when, nor how the manifest/progress should be interpreted. An agent can call it correctly but lacks context about lifecycle or error states.

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% and the sole parameter corpus_id is fully documented as an opaque identifier from review corpus tools. The description adds no extra syntax or format detail beyond the schema, so the baseline 3 for high coverage 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 states a specific verb (Returns) and resource (persisted manifest and progress summary) for a server-side Steam review fetch, which is clearer than a tautology and distinguishes it partially from siblings through the 'status' concept. However, it does not explicitly differentiate from get_steam_forum_topic_corpus_status or explain what 'manifest and progress summary' contains, leaving a small gap versus a model that names its 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?

There is no explicit guidance on when to use this tool versus create_steam_review_corpus or query/aggregate alternatives. An agent must infer from the name and description that this checks fetch progress after corpus creation, but no conditions or prerequisites are stated.

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, and it does disclose the returned payload shape (section id and URL), which is useful since no output schema exists. However, it says nothing about whether this is a read-only/public call, whether authentication is needed, or how results are ordered or bounded.

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

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

A single, front-loaded sentence that leads with the action and resource and adds no padding. Slightly dense but every clause (public sections, hub surfaces, ids, URLs) carries 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 one-parameter listing tool with no output schema and no annotations, the description adequately conveys what is returned (sections, ids, URLs) and the scope (a game's hub). Minor gaps remain around ordering, pagination, and auth, but nothing essential to invoking it correctly is missing.

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

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

Only one parameter exists and schema description coverage is 100% ('appid' documented as Steam application ID). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Lists') and a precise resource ('public Steam Community discussion sections and forum-like app hub surfaces for a game's hub'), scoped to one appid. It is distinguishable from list_steam_forum_topics (sections vs. topics within a section), though it does not explicitly name that sibling to reinforce the distinction.

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

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

There is no statement of when to use this tool versus alternatives such as list_steam_forum_topics. The mention of 'numeric id when applicable' hints that ids feed downstream calls, but no prerequisite, sequencing, or exclusion is spelled out.

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

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

No annotations exist, so the description carries the full burden, and it does meaningful work: last_activity_timestamp/last_activity_display are explicitly 'never original publication time,' and some surfaces (Events & Announcements) omit row-level author and preview markup, so those fields may be null. It still omits auth/permission requirements and rate-limit or pagination-termination behavior.

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

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

Five tight sentences, front-loaded with the core purpose, then pagination mechanics, then the timestamp caveat, then the null-field caveat. No filler, though the pagination sentence overlaps with schema text and could be trimmed.

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 usefully names the returned fields (last_activity_timestamp, last_activity_display, author, preview) and their caveats, which compensates for the missing output contract. It is near-complete for a listing tool, missing only auth/permission context and pagination end conditions.

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 page, appid, forum_key and section_id are already documented in the schema, including the ?fp=N convention. The description's mention of '?fp=N' and section selection largely restates what the schema already says, adding little beyond the baseline.

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?

Specific verb (Lists) + resource (topics) + scope (a game's public Steam Community discussion section or compatible app hub forum surface). It clearly distinguishes itself from list_steam_forum_sections (lists sections, not topics) and get_steam_forum_topic (retrieves one topic), so an agent can route 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?

It gives a clear when-not and an explicit alternative: 'Call get_steam_forum_topic and use topic.original_post_timestamp before making publication-date claims.' It also frames section selection as a usage condition. It stops short of stating when to prefer this over list_steam_forum_sections or how pagination terminates, so it is strong but not exhaustive.

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 discloses the key behavioral constraint that date/sentiment/playtime filters require a corpus created with review metadata enabled, which is valuable. However, it doesn't cover permissions, result shape, pagination limits, or failure modes beyond the metadata caveat.

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 earning their place: purpose front-loaded, usage hint, then prerequisite. No filler or repetition of name/title. Slightly dense but efficient.

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?

Covers the purpose and a critical prerequisite for filters. For a 16-param retrieval tool with no annotations and no output schema, an agent needs more: pagination behavior (limit/offset defaults), field-selection tradeoffs, or what happens on empty results. The metadata caveat is the strongest addition, but completeness is only moderate.

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 16 parameters thoroughly. The description adds a minor gating note about which filters require metadata-enabled corpora, which is useful, but otherwise defers to the schema as expected. Baseline 3 applies.

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

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

States a clear verb+resource: 'Queries a stored Steam review corpus' with server-side filtering, pagination, and field selection. It distinguishes itself from create_steam_review_corpus and aggregate_steam_review_corpus by being the retrieval tool, though it doesn't explicitly name those alternatives.

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 a contextual hint ('retrieve only the subset of reviews you actually need for analysis') and notes a prerequisite (metadata-enabled corpus), but doesn't explicitly state when to use this vs. aggregate_steam_review_corpus or read_steam_forum_topic_corpus_chunk. Usage is implied rather than directive.

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 reveals that data is server-side and persisted, which is useful context beyond the schema, but it omits key behavioral details: whether chunks are immutable once created, what happens if chunk_index is out of range, whether corpus_id expiration matters, and what the return format looks like.

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

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

Single efficient sentence that front-loads the verb and resource. No waste, though it could be structured to separate the action from the prerequisite.

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

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

For a tool with no annotations, no output schema, and a dependent workflow (requires a previously created corpus), the description is too thin. It doesn't explain how chunk_index relates to total chunks, whether there's a limit, what the response contains, or error behavior for invalid/expired corpus_id. The agent lacks critical operational context.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema (corpus_id as opaque identifier from corpus tools, chunk_index as zero-based). The description adds no parameter-level detail beyond what the schema provides, 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?

States a specific verb (reads) and resource (stored reply chunk from server-side Steam Community topic fetch). It clearly distinguishes itself from siblings like get_steam_forum_topic (live fetch) and the corpus creation/status tools. However, it doesn't explicitly name the sibling it depends on (create_steam_forum_topic_corpus), relying on the phrase 'previously created' to imply the workflow.

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 says it reads from a 'previously created' corpus, implying the corpus must exist, but gives no explicit when-to-use guidance, no mention of pagination strategy, no bounds on valid chunk_index, and no alternative tools to consider. An agent must infer the entire usage pattern.

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