SkinGrind

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

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description still adds real value by disclosing the paginated structure and that results include each skin's current cheapest listing price.

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, front-loaded with the core action and the price-threshold grouping, followed by the conditional slug behavior. Every clause carries information; 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 single-parameter browse tool with readOnlyHint and no output schema, the description covers both invocation modes and the shape of returned data. It does not mention result limits or pagination depth, a minor 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 100% and the single slug parameter is fully documented in the schema, so the baseline is 3. The description restates the omit-to-list-all behavior and gives inline examples rather than adding format or validation semantics beyond the schema.

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

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

States a specific verb ('find') and resource ('cheap Counter-Strike 2 skins') and clarifies the price-threshold page structure, which separates it from query-driven siblings like search_skins. It never names a sibling explicitly, so the differentiation is inference-based rather than stated.

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

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

The description explains the two operating modes (no slug = list pages, slug = return skins on that page), which is useful usage context. However, it gives no guidance on when to prefer this over search_skins or the other browse_* tools, nor any prerequisites.

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

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

readOnlyHint=true already establishes the safe-read profile, and the description adds meaningful behavioral context beyond that: odds follow 'standard CS2 tier weights' and are 'renormalised over the tiers actually present.' That explains how the derived numbers are computed, which an agent could not infer from annotations. It stops short of disclosing pagination behavior or return shape.

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, zero waste, and front-loaded: the primary list behavior leads, the single-container mode follows, and the odds caveat is tacked on last where it belongs. 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?

With no output schema, the description usefully states what comes back (contents, drop odds, expected opening value) and how the odds are derived. For a read-only browse tool whose parameters are fully schema-documented, this is nearly complete, though it omits any note on result volume or pagination defaults.

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 all six parameters are already documented in the schema. The description restates the slug behavior (single container instead of list) and adds the odds-renormalisation note, but adds no syntax or format meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('List Counter-Strike 2 cases, capsules and souvenir packages') and a distinct secondary mode (get one container with contents, drop odds, and expected opening value). The resource is clearly differentiated from siblings like browse_collections, search_skins, and get_case_roi_ranking, so an agent can tell it apart 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?

The description makes the two operating modes explicit: list containers, or fetch a single container by slug ('or get one container with its contents'). It gives clear context for when each mode applies but does not name alternatives (e.g. get_case_roi_ranking, browse_collections) or state exclusions, so it falls just 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds one genuinely useful behavioral note: the trade-up map is 'catalog contract math, not scanner output,' which warns the agent not to treat it as live market data. Nothing is said about pagination limits, response size, or cost of including the map.

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, zero filler, with the primary list/single behaviour front-loaded before the optional map. The last sentence is a compact caveat that earns its place, though 'catalog contract math' is slightly jargon-heavy.

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?

Seven parameters with no output schema and only a readOnly annotation; the description covers the two modes and what the trade-up map contains but says nothing about the paged list response, sorting behaviour, or what a collection payload looks like. Adequate for a browsing tool but with visible 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 100%, so every parameter is already documented and the baseline is 3. The description paraphrases the map contents and the list-vs-slug behaviour that the schema already states, adding little new parameter meaning beyond the provenance caveat.

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 ('List Counter-Strike 2 collections') and cleanly separates two operating modes: the list and the single collection with contents. It is distinguishable from browse_cases and get_skin_detail, though it never explicitly names a sibling to route against.

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 dual-mode structure ('or get one collection with its contents') implies when each mode applies, and the trade-up map is framed as optional. However, there is no explicit when-to-use/when-not guidance and no alternatives named among the many siblings (search_cosmetics, browse_cases, get_tradeup_preview).

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 only declare readOnlyHint=true, so the description usefully adds that the tool returns credit cost, expected value, and per-tile rarity weighting. The dual mode (overview vs. single tile) is disclosed, which is behavioral context beyond the safety hint, though nothing is said about data freshness or how expected value is derived.

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 tightly written sentences: the first front-loads the dual behavior and the returned fields, the second states the use case. No filler or redundancy.

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

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

For a one-optional-parameter, read-only tool with no output schema, the description covers both invocation modes and what each returns, which is essentially all an agent needs. Minor gaps remain around pagination/rotation scope and data currency.

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

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

Schema description coverage is 100% and the slug parameter's behavior (returns that tile with its full item list instead of the overview) is already spelled out in the schema. The description restates the same mode-switch, adding no format or validation detail beyond it, so the baseline 3 applies.

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

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

The description names a specific verb pair (list / get) and a precise resource (current Counter-Strike 2 Armory rotation tiles), and describes both operating modes distinctly. Neither of the siblings mentions Armory, so an agent can readily tell this apart from browse_cases or get_case_roi_ranking.

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 the purpose clearly: 'Use this to compare what Armory credits are worth across the current rotation,' giving a concrete decision context. However, it never names an alternative or a condition under which a sibling (e.g., get_case_roi_ranking) would be the better choice.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful behavioral context about the computation basis ('current listing prices plus the key price') and exclusions ('Cases whose contents are not sufficiently priced are excluded'). This goes beyond the annotations, but it doesn't cover other behavioral aspects like rate limits or authentication. A 3 is appropriate.

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, then details on entries and exclusions. Every sentence earns its place without redundancy.

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

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

Given no output schema, the description explains what each entry contains (price, expected value, return in basis points, chance of profitable opening), which is essential. It also notes exclusions. However, it could mention if there are any parameters or if the ranking is always complete, but for a parameterless read-only tool, it's quite complete.

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

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

There are no parameters (0 params), so the baseline is 4. The description doesn't need to explain parameters, and it correctly doesn't invent any. It provides no parameter information because none exist.

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 ('Rank'), resource ('Counter-Strike 2 cases'), and metric ('expected return on opening'), clearly distinguishing it from sibling tools like get_armory_roi or browse_cases.

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 implicitly defines usage by describing the ranking and what data each entry contains, but doesn't explicitly state when to use this tool versus alternatives like browse_cases or get_armory_roi. However, the narrow focus on ROI ranking provides clear 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?

Annotations only declare readOnlyHint=true, so the description usefully adds behavioral context about what comes back (float range, per-wear prices, collections, cases) and that the trade-up context is optional catalog-derived data. It falls short of disclosing auth needs, rate limits, or failure behavior for an unknown slug.

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, zero filler, with the core resource and returned fields front-loaded before the optional add-on.

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 takes on the burden of describing the return payload and does so adequately for a read-only lookup with fully documented parameters. Minor gaps remain around lookup-failure behavior, but nothing essential to calling 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?

Schema coverage is 100%, so the schema already documents all three parameters including the trade-up flag being catalog-derived contract math. The description references the optional trade-up context but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource (get one CS2 skin) plus the payload it returns: float range, per-wear prices, collections and cases. This clearly contrasts with the sibling search_skins' listing behavior, though it never names that sibling 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?

Usage is implied by 'Get one ... skin' — you call it when you already know the weapon/skin slugs and want detail — but there is no explicit when-to-use vs search_skins/get_tradeup_preview guidance and no stated prerequisites or exclusions.

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

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

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that: costs are hourly price estimates (data may be stale), inputs must be bought at or below target float, some results are locked teasers with unlock timing, and the response carries execution_notes about what to verify before buying. It stops short of 5 only because it doesn't characterize the freshness window or any rate limits.

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 the tool's purpose and return contents, then the caveats (float requirement, hourly estimates, execution_notes) and the auth boundary. Dense and largely waste-free, though the opening clause strings three deliverables together in one run-on sentence rather than structuring them.

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?

There is no output schema, so the description carries the return-value burden and does so: it names the three payload sections, the caveat field (execution_notes), and the data-quality limitation of hourly estimates. With only one optional enum parameter and a read-only annotation, nothing an agent needs in order to call this 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?

The single 'type' parameter has a full schema description with enum values and a default, so schema coverage is 100%. The description never mentions the feed selector, adding nothing beyond the schema. Per the high-coverage baseline, a 3 is appropriate 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 (get the free preview of the SkinGrind Trade Up scanner) and enumerates exactly what the response contains: featured Trade Ups with full recipes, active contract count, and locked teasers. It is immediately distinguishable from siblings like get_case_roi_ranking or browse_bargains, which are ranking/browsing tools rather than a preview feed.

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 clarifies the context of use by contrasting the free preview with the paid path: 'Full recipes for the whole feed need a SkinGrind account and the authenticated server.' That tells the agent when this tool is sufficient and when the user must authenticate, but it never names an alternative tool or states explicit exclusions, 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: normal results return names and cheapest listing prices, while a slug query switches to a rich single-item payload with per-marketplace prices — useful mode-switching disclosure.

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 zero filler: the first establishes scope and exclusions, the second establishes the two return modes. Nothing is buried or redundant.

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

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

With no output schema, the description carries the burden of describing returns and does so for both modes (list vs. single-item detail). Minor gaps remain around pagination/filter interaction with the slug mode, but an agent has enough 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 100% with 6 well-documented parameters, so the baseline is 3. The description's only parameter-adjacent content — that a slug returns one item with full detail — restates what the schema's own slug description already says, so it adds no new semantic value.

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 (Search) plus the exact resource (Counter-Strike 2 cosmetic items) and immediately scopes it by exclusion — 'not weapon skins' — enumerating the six covered categories. This lets an agent separate it from search_skins 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 'not weapon skins' exclusion plus the category enumeration gives clear routing guidance against the sibling search_skins and browse_* tools, and it notes the slug-driven single-item mode. It stops short of naming the alternative tool explicitly or stating when-not-to-use conditions.

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

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

Annotations only declare readOnlyHint=true, so the description adds real value by disclosing the response shape (names, rarities, wear ranges, cheapest listing price in cents). It does not mention rate limits or result caps, but the safety profile is already covered by annotations.

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, both front-loaded: capability first, return values second, sibling disambiguation third. No filler or redundancy.

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

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

With no output schema present, the description compensates by describing the return fields, and it covers the cross-sibling decision for this 10-parameter tool. Everything an agent needs to call and interpret it is present.

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

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

Schema description coverage is 100%, so every parameter including enums and defaults is already documented. The description restates the facet categories (name, weapon, rarity, collection, case) without adding syntax or semantics beyond the schema, which is the expected baseline 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 (search/filter CS2 weapon skins) and enumerates the filter facets that define its scope. It also names the sibling get_skin_detail and the exact condition that separates them, so an agent can route correctly 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?

Explicitly routes single-skin lookups to get_skin_detail with per-wear pricing as the distinguishing reason. It does not address when to prefer this over other browsing siblings (browse_cases, browse_collections, search_cosmetics), but the core use case is clear.

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