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

With no annotations the description carries the full burden, and it discloses a lot: refund status neither excludes nor reweights records, results cover only saved data that may be partial/capped, completed corpora are served locally without refresh, interrupted jobs resume under cooldown, and unsupported formats return UNSUPPORTED_CORPUS_VERSION. It still omits auth/permission needs and concurrency behavior, so it falls short of exhaustive.

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?

Purpose and return summary are front-loaded, then caveats follow in dense but single-purpose sentences. It is long, but for a 12-parameter aggregation tool with no annotations nearly every 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 complex 12-param tool with no output schema and no annotations, the description covers return contents, data-completeness caveats, refresh semantics, resume behavior and an error code, which is close to sufficient. Auth requirements and the exact distinction from query_steam_review_corpus remain uncovered.

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, making 3 the baseline. The description adds only marginal semantics beyond the schema, notably that buckets are UTC and that weeks start Monday.

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 (Aggregates) and resource (committed schema 2 review chunks) plus the filter dimensions used, so the operation is unambiguous. However, it never distinguishes itself from the sibling query_steam_review_corpus, leaving the agent to guess which one to pick.

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 offers a useful routing hint ('Completed corpora are read locally without refresh; create a new corpus for updated data') that points toward create_steam_review_corpus, and notes 'Requires metadata'. But there is no explicit when-to-use vs query_steam_review_corpus, and no when-not 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?

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 behavioral burden and does so richly: background execution, immediate corpus_id return, separate corpus per call, snapshot semantics, no implicit date window, shared request lane with 429 cooldown, and server-side schema 2 storage. It also clarifies metadata and refund behavior, giving the agent substantial operational context.

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

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

The description is front-loaded with the core action and return value, then proceeds through defaults, metadata, traversal, rate limits, and storage. Every sentence carries actionable information, with no filler.

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

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

For a complex asynchronous corpus-creation tool with ten parameters, no annotations, and no output schema, the description is complete: it explains the return value, background nature, default scope, rate-limit behavior, snapshot semantics, and storage location. Nothing essential for correct invocation or downstream tool selection 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?

Schema description coverage is 100%, so the schema already documents all ten parameters, setting the baseline at 3. The description still adds meaning beyond the schema by clarifying that refund status does not exclude reviews and that recent/updated traversal has no implicit date window.

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 first sentence states a specific verb and resource: creates a public Steam review corpus in the background and returns a corpus_id. It distinguishes this from read/status/query/aggregate siblings by making clear that this is the corpus-creation step, not a retrieval or analysis step.

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 says the returned corpus_id is for status checks, local queries and aggregates, and that a new corpus is needed to refresh a snapshot. This gives clear usage context, but it does not explicitly name when to choose this over get_steam_review or other alternatives.

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 does disclose real context: shared request spacing, a 429 cooldown, and up-to-10-minute Steam-side caching of anonymous responses, plus that refunds are not filtered. It stops short of stating read-only nature explicitly or any permission/auth requirements, so it adds strong but not exhaustive context.

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

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

Front-loaded with purpose and dense with useful facts, but it spends a full sentence restating defaults that the schema already encodes (ranking, languages, purchase sources, sentiments) and repeats the fetch_all/recent behavior twice.

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 11-parameter tool with no output schema, the description covers cross-tool routing, default behavior, rate limits, and caching well. It leaves some gaps around return-shape and pagination mechanics, though cursor semantics are handled in the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters in detail. The description largely echoes the defaults (helpful, all languages, all purchase sources, both sentiments, off-topic included) and adds only marginal meaning, e.g. clarifying refunds are not filtered and what review_details contains.

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: 'Reads a page of public Steam reviews directly from Steam.' It distinguishes itself from the sibling corpus tools by pointing large analyses to 'a background corpus,' so an agent can tell it apart from create_steam_review_corpus/query_steam_review_corpus.

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?

Explicitly routes the agent: 'Use recent for new feedback, updated for modifications, and a background corpus for large analyses.' It names the alternative (corpus) and the condition that selects it, plus notes fetch_all's automatic behavior for helpful requests.

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 so well: it defines the running/waiting states, explains next_retry_at as a UTC ISO timestamp, warns that polling cannot bypass rate-limit cooldown, and cautions that total_reviews_expected is not proof of completeness. It also documents resume behavior and error outcomes (UNSUPPORTED_CORPUS_VERSION, not_found).

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?

Dense but tight: every sentence conveys a distinct behavioral fact, and the primary return scope leads the description. No filler or repetition.

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

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

With no output schema, the description fills the gap by describing returned fields (progress, chunks, stop reason, errors) and status semantics. An agent has enough to interpret results and poll 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 coverage is 100%, so the corpus_id parameter is already documented as an opaque identifier. The description adds value beyond the schema by explaining that expired or missing IDs return not_found, clarifying failure semantics.

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+resource: it returns saved review corpus progress, chunks, stop reason and errors. The name and wording make it clearly the status/progress reader for review corpora, distinguishable from query/aggregate/create siblings.

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

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

Gives clear operational context: polling does not bypass cooldown, it resumes interrupted schema 2 jobs, and completed corpora stay local and are not refreshed. This tells the agent when a call is useful versus futile, though it doesn't explicitly name an alternative tool.

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

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

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?

With no annotations, the description carries the burden well: playtime thresholds in minutes, metadata required for timestamp/sentiment/playtime filtering and sorting with null for unavailable values, refunded does not filter, counts cover committed chunks that may be partial or capped, completed corpora read locally, interrupted jobs resume under cooldown, and UNSUPPORTED_CORPUS_VERSION on unsupported formats. It omits explicit read-only framing and response shape, but discloses substantial behavior beyond the 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?

Purpose and core capability are front-loaded in the first sentence, then a dense but relevant run of behavioral caveats. It is a single long paragraph with several clauses packed together, which costs a little readability, but nearly every sentence carries operational 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 16-parameter read tool with no annotations and no output schema, the definition covers filtering prerequisites, query semantics, data freshness, partial-count caveats, and an error code. What remains thin is result-shape and pagination interaction with the capped counts, but the critical calling constraints are present.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds meaning beyond the schema: metadata prerequisite for several filters, null semantics for unavailable metadata, and the clarification that refund status does not filter results despite being a selectable field. This goes beyond restating the per-parameter descriptions.

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 with scope: queries persisted schema 2 review chunks by text, language, date, sentiment and playtime, with pagination, field selection and ordering. An agent can distinguish it from create_steam_review_corpus and aggregate_steam_review_corpus by the 'queries persisted chunks' framing, but no sibling is named 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?

Gives concrete routing context: read completed corpora locally without refresh, create a new corpus for updated data, and inspect corpus status and stop reason for partial/capped counts. It doesn't state explicit exclusions (e.g. versus get_steam_review for a single review), but the when-to-use conditions are 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?

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.