Infinite Backlog MCP Server

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

With no annotations, the description carries the full burden and largely succeeds: it discloses the search order (DLC, then PACK/ADDON, EDITIONS, extras widgets), that one UPDATE GAME persists changes, that it never deletes, and which fields it does not touch. Auth requirements and side-effect surface beyond the listed exclusions are not covered, keeping it from 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?

Dense and front-loaded, leading with the core action before constraints. It is somewhat run-on with many short clauses, but each sentence contributes constraint or behavior information rather than 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 browser-driven mutation tool, it covers ordering, persistence, and exclusions, and an output schema exists so return values need not be explained. The main gap is that several parameters remain undocumented for an agent to call it 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 0% and there are 6 parameters, so the description must compensate. It explains `names` (a JSON array of Steam/IB titles) and that `platform`/`digital` are ignored, but says nothing about `parent_slug`, `collection_id`, or `wait_ms`, leaving half the parameters undocumented.

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: adding owned extras (DLC/packs) to a parent collection game. It is clear what operation it performs and even names the UI surface ('parent collection edit form'). Sibling differentiation is implicit rather than explicit, so it falls short of a 5.

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 constraints ('Does not use /games/add for DLC/packs', 'Does not change edition, play status...') but never states when to choose this over siblings like add_game_platform_copy or set_game_acquisition. Usage is only implied via the excluded behaviors.

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: idempotency ('skips if that platform copy already exists'), side-effect boundaries ('Never fills Acquisition Info', 'Never DELETE GAME'), and a dry-run mode via submit=false. It omits permission/auth requirements and error behavior, so it is not 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?

Dense, front-loaded, and every sentence carries distinct information (mechanism, skip condition, two invariants, dry-run flag, platform inference, digital semantics). No filler or restatement of the name.

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 exists so return values need not be explained, and the behavioral picture is largely complete for a mutation tool. The remaining gap is the three undocumented parameters (slug, wait_ms, collection_id) that neither schema nor description clarifies.

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 0%, so the description must compensate. It explains submit (fill without saving), digital (only changed when passed), and platform (taken from caller or inferred from a single-option select), but leaves slug, wait_ms, and collection_id entirely unexplained.

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 precise verb and resource ('Add another GAME INFORMATION copy') and even names the exact UI mechanism ('button.extra-platform on the collection edit header'). The explicit 'Never DELETE GAME' clause distinguishes it from the sibling delete_game_copy.

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 usage conditions: it skips when the platform copy already exists, and 'Pass submit=false to fill the form without saving' defines a dry-run mode. It does not name alternative sibling tools or state when not to use this one, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the auth requirement ('Requires login'), a hard content constraint (800+ chars to publish), a non-destructive guarantee ('Never clicks DELETE'), and update-in-place behavior for existing reviews. It omits reversibility/error handling and rate behavior, so not 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?

Four short, front-loaded sentences with no filler; the most actionable facts (body required, publish rule, login) lead. Slightly telegraphic but nothing 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?

The output schema exists so return values needn't be described, and the safety/auth/limit context is solid. However, for a 10-parameter mutation tool with 0% schema coverage, the description leaves too many parameters and their effects opaque, so it is only minimally 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 0% across 10 parameters, so the description must compensate but does not. It clarifies only body (required) and publish (draft semantics) and implies slug via the URL template, leaving feed, title, mature, wait_ms, language, platform, and spoilers entirely unexplained.

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 pair and resource ('Add or update a review') plus the concrete endpoint shape, so an agent can distinguish it from delete_game_review and set_game_rating without opening any schema.

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

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

Gives clear conditional guidance on the publish flag ('Publish needs 800+ characters; use publish=false for Save draft') and notes that an existing review opens the existing editor, but never names sibling alternatives or when to prefer them over this tool. Usage is implied rather than routed.

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

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

With no annotations, the description bears the full behavioral burden. It does disclose one real trait beyond the schema, a blocking restriction on destructive actions, but says nothing about page-load waits, timing behavior, failure modes, or permissions for a browser-mutating click.

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 short, front-loaded sentences with no filler: the action first, then the restriction. Efficient, though the second sentence's cryptic "IB" wording costs it a point.

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 exists, so return values need no explanation. Still, for a parameter-heavy browser action with zero annotation and zero schema-description coverage, the definition leaves wait_ms semantics and the scope of the blocking rule undefined.

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 0%, so the description must compensate. It meaningfully clarifies the required selector parameter by revealing the "text=..." selector syntax, but leaves wait_ms entirely unexplained (wait before or after the click?). Partial compensation only.

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 concrete verb and mechanism ("Click by CSS selector or text=..."), which is specific enough that an agent understands it clicks a page element rather than submitting a form (fill) or running arbitrary code (evaluate_js). It lacks any explicit sibling differentiation, so it lands at 4 rather than 5.

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?

"Blocked for destructive IB actions owned by dedicated tools" is a partial when-not rule, giving implied guidance to use other tools for those actions. However, "IB" is undefined jargon and no alternative tool is actually named, so the agent must infer both the usage context and the fallback.

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 behavioral burden, and it discloses almost nothing beyond the action itself. It does not say whether closing discards session state, whether it is idempotent or errors when no browser is open, whether an in-progress run_browser_use_task would be affected, or whether the browser can be relaunched by later calls.

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 the verb first and zero filler. Nothing could be cut without losing scope 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?

An output schema exists, so return values need not be explained. However, for a teardown tool with no annotations and no side-effect disclosure, an agent cannot tell what state is lost or whether other browser tools remain usable afterwards.

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 there is nothing for the description to disambiguate; the empty schema is self-explanatory. Baseline 4 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 and resource — 'Close the shared Playwright browser' — and scopes it to the browser 'used by deterministic tools', which hints at the distinction from run_browser_use_task. It is clear and unambiguous, though it does not explicitly contrast itself with any sibling tool.

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 statement of when to call this versus alternatives, or when not to call it (e.g., while another browser task is in flight). The phrase 'used by deterministic tools' implies the context in which the shared browser exists, so usage is inferable but not 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 behavioral burden. It implies a read-only retrieval but says nothing about prerequisites (e.g., a browser must be open and a page navigated) or what happens when no page is loaded, which matters in a browser-automation family with close_browser and open_site siblings.

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 short sentence with no filler, and the verb and returned values are front-loaded. Nothing wastes space.

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 exists, so the return shape need not be described. However, for a browser tool with no annotations, the description omits the state prerequisite (an open page) that an agent needs in order to call it at the right time.

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 there is nothing for the description to disambiguate; baseline is 4.

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?

Clear verb ("Return") and specific resource ("current URL and title"), so an agent knows exactly what it yields. It does not distinguish itself from siblings like get_page_text, get_page_html, or get_links, which also read browser state, so sibling differentiation is left to inference.

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 when-to-use guidance and no mention of alternatives such as get_page_text or get_page_html. The agent must infer that this is for URL/title retrieval rather than page content.

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 disclose meaningful traits: it is destructive, requires confirm=true, and — critically — warns that deleting the last remaining copy removes the game from the collection. It omits any mention of permissions, reversibility, or rate limits, so it is strong but not 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?

Three dense, front-loaded sentences with no filler; the required-parameter constraints and the destructive caveat come early. The phrasing is telegraphic but every clause 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 destructive mutation with no annotations, the description does cover the confirm gate and the last-copy side effect, and an output schema exists so return values need not be explained. The unexplained 'slug' parameter and absent permission/reversibility guidance leave a real gap.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate. It documents collection_id ('always required') and confirm ('=true required'), but the required 'slug' parameter is never mentioned at all and 'wait_ms' is unexplained, leaving two parameters undocumented in both places.

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 ('Delete a saved collection copy') and clarifies the exact UI action used ('via DELETE GAME'), implicitly separating it from the draft/unsaved variants. It does not explicitly differentiate from a sibling like delete_game_review, but the mechanism is unambiguous.

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

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

It gives implicit when-not guidance by stating what it does NOT click (DELETE DRAFT, DELETE GAME FOR unsaved extra platforms), which helps scope the action. However, it never names an alternative tool or states in which situations an agent should prefer another operation over this one.

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 key safety gate (drafts only, published + ownership override), the confirm requirement, and an explicit scope warning. It stops short of stating irreversibility or failure/error behavior for a destructive operation.

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

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

Four tight fragments, front-loaded with the core action and preconditions and ending on the safety warning. No waste, though the phrase "you named that review" is slightly ambiguous.

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 exists so return values needn't be explained. But for a destructive tool with zero annotations, the description omits irreversibility, permission/ownership mechanics, and the meaning of slug and wait_ms, leaving meaningful gaps.

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

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

Schema description coverage is 0% with 4 parameters, so the description must compensate. It explains confirm and published, but leaves slug (the required identifier) and wait_ms entirely undefined in both schema and description — roughly half the parameters are unaccounted for.

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 ("Delete a review") and adds a scope guard ("Never DELETE GAME") that separates it from game-deletion operations and the sibling add_game_review. Clear and distinguishable, though terse.

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 explicit preconditions for use: drafts only unless published=true AND you named that review, plus confirm=true required. It states when the tool is applicable but names no alternative tool or describes what to do instead when the conditions fail.

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. It usefully discloses the required environment flag, but does not explain that executing arbitrary JavaScript can mutate page state, what security implications exist, or whether the operation is read-only. The disclosure is partial but valuable.

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 short sentences with no wasted words and front-loads the core action before the enablement caveat. It is appropriately sized for a one-parameter 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 exists, so return values need not be explained. However, important context is missing: the description does not help an agent choose this tool over sibling browser tools, and it leaves the expression parameter entirely undocumented despite the schema providing no description.

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 0% and the description does not describe the 'expression' parameter's expected format or syntax. The phrase 'return JSON result' hints that the expression should evaluate to a JSON-serializable value, but this is only implicit and does not compensate for the missing 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 states a specific verb ('Run') and resource ('JavaScript in the page') with the output form ('return JSON result'). No sibling tool executes JavaScript, so the purpose is unambiguous even without naming an alternative.

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 only gives an enablement precondition ('Disabled unless IB_ALLOW_EVAL_JS=true') and never says when to use this tool versus alternatives like click, fill, or get_page_text. It provides no context or exclusions for selecting it.

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 one genuine behavioral trait: it refuses password and credential selectors. That is useful, but it omits other behaviors an agent needs, such as whether existing content is cleared, waiting/visibility handling, and what happens on a failed selector.

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 short sentences with no filler, and the core action is front-loaded ahead of the security caveat. It is slightly under-specified rather than padded, so the size is appropriate but leaves gaps.

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 exists, so return values need not be explained, and the security caveat is covered. However, for a browser-automation write tool with zero annotations and zero schema coverage, missing selector-format and failure/replace behavior leaves the agent with notable blind spots.

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 0% and neither parameter has a description. The description implies 'selector' identifies the input field and that a value is supplied, but it adds no syntax detail (CSS vs XPath), no clarification that value is the text to type, and no compensation for the documentation gap.

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 ('Fill') and resource ('an input field'), so the agent knows this writes text into a DOM element. It does not explicitly differentiate itself from siblings like click, evaluate_js, or open_site, but the resource is unambiguous.

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

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

There is no guidance on when to use fill versus alternatives such as evaluate_js or click, nor any prerequisites (e.g., element must exist/be visible). The only constraint given is the negative one about password selectors, which is a safety rule rather than usage routing.

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 discloses little: it doesn't mention that a browser session must be open, how links are ordered or truncated, pagination, or any rate/permission constraints. It only restates the output shape, which the output schema already covers.

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 efficient sentence with the resource front-loaded and no wasted words. It is tight, though arguably too terse given the gaps elsewhere.

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

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

The presence of an output schema removes the need to explain return values, and the read-only nature of link extraction is intuitive. However, the max_links parameter is unexplained and no session prerequisites are given, leaving meaningful gaps for a browser-context tool.

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 0% and the single parameter max_links (default 50) is never mentioned in the description. The 'text + href' note describes output fields, not the parameter, so the description does not compensate for the undocumented truncation behavior.

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 (extract), resource (links), and scope (current page), plus the returned shape (text + href). This clearly differentiates it from siblings like get_page_text and get_page_html that retrieve other page content, though it doesn't name 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?

There is no guidance on when to use this versus get_page_html, get_page_text, or evaluate_js for link extraction, and no stated prerequisites or context about the browser session it operates on.

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 delivers only the default selector. It does not disclose that output may be truncated (max_chars defaults to 15000), whether the page must be open, or what happens if the selector matches nothing. This is a significant gap for a tool with a truncation-capable parameter.

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 short sentence, front-loaded, with zero filler. It is efficient, though the terseness is part of the under-specification problem rather than a virtue here.

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 exists, so return values need no explanation, but the description omits truncation semantics, page-state requirements, and any routing versus get_page_text. For a 2-param DOM extraction tool with 0% schema coverage, this is too thin to guide correct 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 coverage is 0%, so the description must compensate. It explains the selector default ('body') but says nothing about max_chars, even though truncation behavior is the more consequential parameter. Half the parameters remain semantically opaque.

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: 'Get HTML of an element'. The parenthetical '(default body)' clarifies the default scope. It implicitly contrasts with the sibling get_page_text (text vs. HTML), though it never names that alternative 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?

No indication of when to use this over get_page_text, get_links, evaluate_js, or screenshot. No prerequisites or context about which page state it operates on. The agent must infer selection from the name alone.

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. "Visible text" is a useful hint that only rendered content is returned (vs. raw markup or hidden nodes), but it says nothing about truncation, pagination, or how the page state is obtained.

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 front-loaded sentence with no filler or redundancy. It is efficient, though arguably over-terse given the undocumented parameter and missing usage 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?

An output schema exists, so return values need not be explained. But for a tool with an undocumented max_chars parameter and no usage routing, the description leaves real gaps an agent needs filled before calling it 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?

The single parameter max_chars has 0% schema description coverage and no default/min/max explanation, yet the description never mentions it. The truncation behavior implied by max_chars is left entirely undocumented, so the description fails to compensate for the coverage gap.

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 ("Extract") and resource ("visible text from the current page"), which is clear enough to act on. However, it never differentiates itself from the many close siblings such as get_page_html, get_links, or evaluate_js, so the agent must infer the boundary itself.

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 when-to-use guidance, no statement of when this is preferable to get_page_html or get_links, and no mention of prerequisites (e.g. that a page must already be open). The description gives no routing help at all.

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 an auth requirement ('Requires login'), a timing/sequencing constraint ('Wait for UPDATE GAME'), and a read-only guarantee ('Does not change the form'). It stops short of describing return shape, but an output schema exists to cover that.

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-loads the core purpose and keeps the enumeration tight; each clause adds information. Slightly list-heavy but no wasted sentences.

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 safety profile, auth requirement, and timing for a moderately complex browser-automation tool, and an output schema exists so return values need not be explained. The unexplained parameters, especially the required edit_path, leave a meaningful gap.

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

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

Schema description coverage is 0% and neither parameter is explained: edit_path is never named (only implied by 'edit form'), and wait_ms is not mentioned at all despite the loose 'Wait for UPDATE GAME' hint. The description fails to compensate for the complete lack of schema 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?

States a specific verb (List) and resource (extras widgets on a collection edit form), and enumerates the concrete widget types (Add DLC dropdown, owned DLC, addon/pack checkboxes, GAME EDITION text). This is far more specific than a tautology, though it does not explicitly distinguish itself from siblings like list_collection_game_options or list_related_content.

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?

Offers prerequisite context ('Requires login', 'Wait for UPDATE GAME') and a safety note ('Does not change the form'), which implies when the tool is usable. However, it never states when to choose this over the sibling listing tools, so usage is implied rather than guided.

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 reasonably: 'Read-only', 'Does not save', and 'Requires login' disclose the safety profile and an auth requirement. It omits rate limits, pagination, and return-shape behavior, but the core mutation/auth traits are covered.

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

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

Two short sentences, front-loaded with the read-only scope and followed by the save and auth caveats. Every clause carries information, though the enumeration of returned items is slightly dense.

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 exists, so return values need not be described, and the read-only/auth context is present. But with three undocumented parameters and no annotations, the definition leaves meaningful gaps an agent would need to guess at.

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 0% across three parameters, so the description must compensate and does not: it never explains what 'slug' identifies, what 'wait_ms' (default 3000) controls, or what 'collection_id' (default empty) scopes. An agent gets no meaning beyond the bare parameter names.

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

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

The description names a specific verb and resource ('read-only dump of copies, extra-platform plus button, progress widgets, ratings, and reviews for a collection game'), giving the agent a concrete picture of what is returned. It implicitly contrasts with the many set_* mutation siblings by declaring itself read-only, though it never names an alternative 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?

'Requires login' states a prerequisite, and 'read-only' implies a safe inspection use case. However, it never says when to prefer this over list_collection_content_menus, list_related_content, or the individual set_* tools, leaving routing to 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 the operation is read-only and non-persisting, requires login, and notes a UI quirk (tab hidden when status is No Status). It stops short of describing pagination or timing behavior, but covers the key safety and auth traits.

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 short, front-loaded sentences with no filler. The read-only framing leads, and each sentence adds 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?

An output schema exists, so return-value explanation is not needed, and behavior is reasonably covered. However, with three undocumented parameters, zero annotations, and no note on the required slug or the wait_ms timing semantics, the definition is only minimally complete for correct 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?

All three parameters (slug, wait_ms, collection_id) have 0% schema description coverage and the description explains none of them. slug is required and wait_ms/collection_id have defaults, but an agent gets no meaning for any of them from either source.

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: a 'Read-only dump of Play Records categories and Add new category options.' The read-only nature distinguishes it from mutation siblings like set_play_record_category, though it never names an alternative 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?

'Read-only' and 'Does not save' implicitly signal when to prefer this over the set_*/remove_* siblings, but there is no explicit when-to-use or when-not-to-use instruction. Usage must be inferred from the 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 does disclose a real behavioral trait — it expands each tab before scraping, implying browser interaction and delay — but says nothing about required session state, whether it navigates or acts on the current page, or side effects.

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

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

Two compact sentences, front-loaded with the resource and scope, then the expansion behavior. Almost no waste, though the enumeration is verbose given the schema lists nothing.

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 exists, so return values need not be described. However, for a browser-driven tool it omits necessary context: whether the agent must already be on the game page, and what wait_ms controls. Adequate but with clear gaps for a scraping tool.

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 0% with two parameters. The description never mentions game_slug or wait_ms; 'expands each tab before scraping' hints at a timing/delay concern but does not explain wait_ms's role or units. The schema gap is left uncompensated.

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?

Names a specific verb (list) and resource (related games & content tabs on a game page) and enumerates the concrete section types covered: editions, DLC, packs, add-ons, remakes, bundles. An agent can distinguish this from siblings like list_collection_content_menus or get_page_text without opening either schema.

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

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

The phrase 'on a game page' implies the context in which to use it, but there is no explicit when-to-use versus alternatives (e.g. list_collection_content_menus, get_links) and no stated prerequisites. Usage is inferable but not guided.

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 does disclose one genuine behavioral trait: headless=false opens a visible window enabling login. It omits other important traits such as whether navigation replaces the current page, how the browser session is shared, or timeout/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?

Two short sentences, purpose front-loaded and the parameter tip placed second. No filler or redundancy; 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?

An output schema exists, so return-value explanation is not required, and the navigation target plus login hint cover the basics. For a browser-automation entry point with zero annotation coverage, though, more on session behavior and parameter meaning would be needed to be fully 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 coverage is 0%, so the description must compensate. It explains the headless flag's purpose well, but leaves 'path' (presumably relative to infinitebacklog.net) and 'wait_ms' (its purpose and units) entirely undocumented, so two of three parameters remain opaque.

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 (navigate) and resource (a page on infinitebacklog.net), which clearly distinguishes it from read-only siblings like get_page_text or get_links and from action tools like click/fill. It stops short of explicitly naming the browsers it doesn't cover or the alternative (run_browser_use_task).

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 second sentence gives one implicit usage rule ('pass headless=false ... so you can log in'), which hints at a login-then-other-tools workflow. However, there is no explicit when-to-use guidance relative to siblings like run_browser_use_task or click, 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?

With no annotations, the description carries the full load and does meaningful work: it discloses destructiveness, the non-obvious scope escalation (one row vs. whole category), and the confirm=true gate on the dangerous path. It still omits permission/auth requirements, irreversibility, and the significance of wait_ms, which suggests asynchronous execution.

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 short sentences with zero padding; the destructive scope-escalation rule leads, followed by the confirm requirement and the safety warning. Every clause 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?

The output schema means return values need no explanation, and the description covers the key destructive mechanic well. But for an unannotated destructive tool with 6 parameters at 0% schema coverage, leaving four parameters and the irreversibility of the delete unspecified is a real gap.

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

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

Schema description coverage is 0% across 6 parameters, yet the description only explains two of them (row_index's empty-string semantics and confirm's role). The required slug and category, plus collection_id and wait_ms, remain completely undocumented in both schema and description.

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 ('Remove') and resource ('a Play Records row'), and adds the critical scope distinction that an empty row_index escalates the operation to an entire category. The trailing 'Never DELETE GAME' warning explicitly disambiguates it from the game-deletion siblings, though it doesn't name those siblings directly.

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 clear operating condition (row_index empty ⇒ category delete, which needs confirm=true), which is genuinely useful routing information. However, it never names an alternative tool or says when to reach for remove_play_record versus set_play_record or delete_game_copy, so guidance beyond the conditional remains implied.

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 supplied, so the description carries the full burden — and it does most of it: it discloses the URL scoping/enforcement behavior, the runtime prerequisite (pip install browser-use plus an LLM API key), and that authenticated pages need cookies/login. What's missing is failure/cost behavior (what happens on step exhaustion, latency, whether it can mutate 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?

Front-loads the purpose, then routing guidance, then prerequisites, then examples — a sensible information hierarchy. The example lines are justified because they define what a valid `task` string looks like; only mild redundancy in the two-part requirements sentence.

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 exists, so return values need no explanation, and the description covers scope, prerequisites, and sibling routing. It falls short only on the non-task parameters, which is a real gap given 0% schema coverage but not fatal for a tool whose primary input is a natural-language prompt.

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 0%, so the description is responsible for the four parameters, but it only illustrates `task` via two examples. `model`, `headless`, and `max_steps` receive no explanation beyond their bare titles and defaults, leaving an agent to guess at the cost/time tradeoffs of max_steps or when headless should be false.

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 action (run an autonomous browser-use agent) for a specific class of work (complex multi-step tasks on Infinite Backlog). It explicitly contrasts itself with the sibling deterministic tools (open_site, click, fill, etc.), so an agent can route without opening a schema.

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

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

Gives explicit routing guidance: 'Prefer the deterministic tools for simple reads/clicks' and reserve this for complex multi-step tasks. Also states a hard scope boundary (infinitebacklog.net only; refuses tasks containing non-IB URLs), which functions as an explicit when-not-to-use rule.

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 does add one useful behavioral detail: the output is saved under the OS temp infinitebacklog-mcp directory. However, it says nothing about whether a page/browser must already be open, what happens on failure, or any overwrite behavior for the default filename.

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 short sentences, front-loading the action and then the output location. 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?

An output schema exists, so return values need not be explained, but two undocumented parameters at 0% coverage with no annotation support leave real gaps. The full_page behavior in particular is never addressed, which an agent needs to invoke the tool deliberately.

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 0% for both parameters, so the description must compensate and does not. It never explains what 'path' controls (e.g., that it overrides the temp-dir save location) or what 'full_page' changes, which is a meaningful viewport-vs-entire-page distinction.

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 and resource ('Take a screenshot of the current page'), which is clear and distinct from text/html retrieval siblings like get_page_html. It does not explicitly name or contrast with siblings, so it stops short of a 5.

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 use this versus the other page-inspection siblings (get_page_text, get_page_html, get_links), nor any stated prerequisite such as a browser being open. 'Current page' only weakly implies context.

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 non-obvious traits: the Vue native value setter requirement, that /games?search= silently fails to filter, and that #platforms-search must never be typed into. It omits auth expectations, rate limits, and how wait_ms affects 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?

Front-loads the purpose in the first sentence, then delivers compact operational bullets with no filler. Slightly terse for the amount of parameter ground it should cover.

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 exists so return values need no explanation, and the description usefully covers the search mechanism. However, with two parameters at 0% description coverage and no annotations, key calling details (query meaning, wait_ms effect) remain unaddressed.

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 0%, so the description must compensate, and it does not. It alludes to a search field but never names or explains the required `query` parameter, and `wait_ms` is entirely unaddressed in both schema and description.

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 ("Search the Infinite Backlog games catalog") plus the return shape ("return page text"). It is clear but does not differentiate itself from browser-control siblings like run_browser_use_task or get_page_text, which also can act on a page.

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 strong operational guidance for executing the search (Vue native value setter, live filter param /games?q=, and a negative rule about #platforms-search), but gives no when-to-use-this-vs-an-alternative framing relative to siblings such as run_browser_use_task or open_site. Usage is implied through mechanics rather than stated via 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the domain restriction and the required JSON shape, and the output schema covers return values, but it omits whether injected cookies replace or merge with existing session cookies, whether they persist across browser restarts, or any auth/permission requirements.

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

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

Three short lines, front-loaded with the action and use case, followed by the concrete payload format and the acceptance constraint. No sentence is wasted, though the format example could arguably 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 one-parameter tool with an output schema, the payload format and domain constraint are adequately covered. The main missing context is lifecycle behavior relative to the surrounding browser tools (when in the workflow to inject, and whether it must precede open_site).

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?

With a single parameter at 0% schema description coverage, the description compensates well by giving the exact JSON array structure and the object keys (name/value/domain/path) expected for each cookie. Only minor gaps remain, such as whether additional cookie attributes like expires or secure are honored.

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 (inject/set) and resource (cookies) with the added scope constraint that only infinitebacklog.net cookies are accepted. An agent can immediately tell this is an authentication-setup action, though it does not name a sibling tool to distinguish itself from the other browser/session tools.

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?

'For authenticated sessions' implies the use case, so the agent can infer this is called to establish a logged-in state. However, there is no explicit when-to-use instruction, no mention of when not to call it, and no reference to alternatives such as open_site or run_browser_use_task.

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 burden and does disclose meaningful behavior: partial mutation, single-record scope, the multi-copy prerequisite, and explicit negative guarantees (never DELETE GAME, never UNLOCK CUSTOM TAGS). It omits auth/permission needs, wait_ms timing behavior, and what happens when a copy cannot be disambiguated.

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 and front-loaded: the core action leads, then mutation semantics, then the clear_fields contract and constraints. Telegraphic style is efficient but the terse fragments make the safety clauses feel appended rather than integrated.

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 exists so return values need not be explained, and safety/scope are covered. However, for a 12-parameter, zero-coverage, annotation-free mutation tool, the silent parameters (slug, wait_ms, subscription) and the absence of permission/error behavior leave the picture incomplete.

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 0% across 12 parameters, so the description must compensate. It names seven of them (source, amount, date, notes, acquisition, digital_service, additional_cost) and explains clear_fields as a JSON list plus collection_id's condition, but leaves slug, wait_ms and subscription unexplained and gives no format hints for date/amount.

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 pair (set/clear) acting on a specific resource (ACQUISITION INFO on a collection copy), and the 'One UPDATE GAME' clause pins the scope to a single record. An agent can distinguish it from set_game_progress, set_game_rating and the delete tools without opening the schema.

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

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

Gives concrete usage conditions: partial-update semantics ('only provided fields change'), how to express deletions (clear_fields JSON list with allowed members), and the 'collection_id required when multiple copies exist' prerequisite. It lacks any explicit routing to a sibling alternative, 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 annotations, the description carries the full burden and does so well: 'Changes only provided fields' documents patch semantics, 'Never DELETE GAME' and the exclusion list disclose a non-destructive safety profile, and 'One UPDATE GAME' signals single-write behavior. It still omits auth/permission requirements and any wait_ms/rate-limit context, so it is strong but not 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?

The core purpose is front-loaded, and each subsequent clause adds distinct information (field scope, conditional param, patch semantics, clear_fields, non-destructive guarantees). It is dense and telegraphic but not padded; a light restructure would improve flow without adding content.

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 8-param mutation tool with no annotations, the description covers scope, patch behavior, clear semantics, and destructive-safety limits, and an output schema exists so return values need not be described. Remaining gaps are the unexplained required 'slug' and the 'wait_ms' parameter, which leave it slightly short of fully self-contained.

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 0%, so the description must compensate, and it explains most of the 8 params: status, completion, the 0-100 progress bar, progress notes, clear_fields' JSON-list behavior, and the collection_id condition. However, 'slug' (the sole required param) and 'wait_ms' are left entirely unexplained, and the JSON syntax for clear_fields is only gestured at.

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 ('Set') and resource ('per-copy progress') and lists the exact fields affected (status, completion, progress bar, notes). It also carves out its scope by naming what it does NOT touch (edition, DLC, Digital Service, Acquisition Info), which distinguishes it from siblings like set_game_acquisition. An agent can tell it apart from adjacent setters without opening the schema.

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

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

Gives one concrete usage condition ('collection_id required when multiple copies exist') and implies it operates on the collection edit form, but never routes the agent to alternatives such as set_game_acquisition or set_game_rating for the excluded fields. Usage context is implied rather than explicit, so it lands at minimum-viable.

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 real weight: it discloses the auth requirement ('Requires login'), partial-update semantics ('Empty sub-fields stay unchanged'), the clear/remove behavior, and the 1-10 value range. Missing are rate-limit or side-effect/reversibility notes, but this is solid disclosure for an unannotated mutator.

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 terse sentences, front-loaded with the action and scope before the mode/behavior details. No filler or repetition; every sentence adds a distinct fact.

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 exists so return values need no explanation, and the safety/auth profile is covered. Still, for a 9-parameter tool the description leaves wait_ms and the slug/game-identification mechanism undocumented, and the sub-field value encoding ambiguous.

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 0%, so the description must compensate. It usefully explains score (1-10), clear (true removes), and that empty sub-fields are left unchanged, which implicitly covers sound/story/visual/gameplay/playability. However slug and wait_ms remain wholly unexplained, and the sub-field value format is never specified.

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 pair ('Set or clear'), the exact resource ('IB ratings on the collection game page'), and disambiguating scope ('per IGDB game, not per copy'). That scope note alone separates it from per-copy siblings like add_game_platform_copy and set_game_acquisition, and the rating resource separates it from set_game_progress.

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 explains the two internal modes (set vs. clear=true) but gives no guidance on when to reach for this tool over sibling raters/progress setters, and no prerequisites beyond login. An agent gets no routing help between this and set_game_progress or the play-record tools.

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

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

With no annotations, the description carries the full burden, but it does disclose real domain behavior — how payload fields map per category type (keyValue = name+value, checkbox = name, progress = name+value as progress_earned). It stays silent on whether existing rows are overwritten, what row_index/collection_id do, and why wait_ms exists.

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?

Short and front-loaded with the primary operation first. However, the second sentence ('action is add or update') restates what the first sentence and the schema default already say, and the final clause is a dense run-on that trades clarity for brevity.

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 8-parameter mutation tool with no annotations and 0% schema coverage, the description is far too thin, omitting prerequisites, row-addressing semantics (row_index/collection_id), and the meaning of wait_ms. Return values are covered by the output schema, so that omission is acceptable.

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 0% across 8 parameters, so the description must compensate. It clarifies name/value/action semantics but leaves slug, category, row_index, collection_id, and wait_ms entirely undocumented in both schema and description.

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 concrete verb+resource: add or update a Play Records row within a category on a game. It is distinguishable from set_play_record_category, though it never names that sibling or explains the boundary 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 no when-to-use or when-not-to-use guidance, no prerequisites (auth, game context, slug acquisition), and no routing between this tool and siblings like set_play_record_category, list_play_records, or remove_play_record. The only implicit usage signal is that 'action is add or update'.

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 and does disclose a real behavioral trait: it returns profile_scope unless confirm_new=true and the category was named in chat. That guard on global-library writes is valuable. It omits mutation-safety, wait_ms timing behavior, and whether edits are reversible, so it is not 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?

Two sentences, purpose front-loaded, and the type list is compactly embedded. Dense but no obvious waste; slightly more could be trimmed but it stays tight.

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 exists so return format needn't be spelled out, and the profile_scope guard is covered. However, for a 9-parameter mutation tool with zero annotations and 0% schema coverage, the description leaves most parameters and all permission/mutation semantics unaddressed.

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 0% across 9 parameters. The description only supplies the valid 'type' values (keyValue, checkbox, progress, table), which compensates for one param. The remaining eight (slug, name, layout, wait_ms, template, category_id, collection_id) get no meaning beyond their titles.

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 (add or edit) plus resource (Play Records category) and explicitly bounds scope with 'on this game (not the user profile)', which helps distinguish it from profile-scoped siblings. It stops short of naming the closest sibling (set_play_record) so an agent must still 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?

The '(not the user profile)' clause acts as an implicit when-not, and the confirm_new condition gives some routing guidance, but there is no explicit when-to-use versus set_play_record or the other category siblings. Usage is implied rather than stated.

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