Polyfork low-poly 3D assets

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

With no annotations provided, the description must carry the behavioral burden. It discloses the sorting hierarchy ('same kit first, then shared palette, then compatible real-world scale'), the diversification behavior ('spread across classes'), and the return format ('ready preview URL'). This is substantial, though it does not mention read-only status or error behavior, which would make it fully transparent.

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

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

The description is compact yet information-dense. It uses two sentences: one to explain the matching logic and criteria, and one to state the use case and return value. Every word adds value, with no redundancy or fluff.

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 query tool with a schema and no output schema, the description explains the core return value (assets + preview URL) and the matching behavior, which is sufficient for an agent to invoke it. It could elaborate on the structure of the returned asset list or error conditions, but the given context covers the essential information.

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

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

The schema provides descriptions for free, limit, and max_triangles (60% coverage), while id and min_triangles lack descriptions. The description adds context about the matching criteria, which indirectly informs parameters like id (the 'one asset') and limit (diversity control), but it does not explicitly detail parameter meanings or provide examples. Given moderate schema coverage, a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('return') and clearly identifies the resource ('assets that BELONG IN A SCENE WITH IT'). It distinguishes itself from siblings like get_asset and search_assets by focusing on scene compatibility rather than general search or retrieval, and explicitly states its purpose as 'turn a single pick into a scene'.

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 'Use this to turn a single pick into a scene' provides a clear, actionable use case, and the description implies when it is appropriate compared to searching for assets generally. However, it does not explicitly state when not to use it or name alternative tools, so it lacks the full exclusion guidance that would merit 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 behavioral disclosure burden and does so well. It explicitly reveals conditional blocks for has_ik models, the paid/not-owned branch returning price and buy link instead, and caller-specific download URLs. This goes beyond a generic 'get asset' statement and gives the agent an accurate model of response variation.

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

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

The description is dense but every sentence earns its place: it front-loads the core purpose, then details the standard fields, the IK conditional, and the paid-asset branch. Formatting with backticks aids readability without adding fluff.

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

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

Given the low complexity (one required parameter), lack of output schema, and no annotations, the description is remarkably complete. It covers the main return categories, the IK special case, the paid-asset alternate response, and even points to /cdn/walk.mjs for implementation. The only omitted case is an invalid/not-found id, but that is minor against the breadth provided.

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% for the single id parameter and includes an example, so the schema already fully explains the parameter. The description adds no additional parameter-level detail, matching the baseline of 3 for high schema coverage.

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?

Starts with 'Full detail for one asset', a specific verb and resource, then enumerates the concrete data returned: real-world size, triangle count, palette, animatable parts, renders, and caller-specific download URLs. The 'one asset' scope clearly distinguishes it from search/list siblings like search_assets and find_matching.

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 clearly indicates this is for retrieving full detail on a single known asset, and it provides context on conditional reply shapes for IK models and paid assets. However, it does not explicitly contrast with sibling tools such as get_variant or get_kit, nor state when not to use it, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the types of content and even names specific rules (real-world metres, one material, never rescale to fake a fit), giving useful behavioral context beyond what structured fields show.

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 purpose and filled with concrete examples. Every clause earns its place, and the length is appropriate for the instructional 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 a help tool with a single optional parameter, the description fully covers what the tool returns and when to use it. The enum topics are self-explanatory, and no output schema is needed for help content.

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 an enum for topic and a description 'omit for the overview'. The tool description itself does not add parameter details, but schema already documents the single optional parameter. Baseline 3 is appropriate.

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

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

The description clearly states this is a help tool for using the server, with specific content: metadata meaning, easy-to-get-wrong rules, and worked recipes. It distinguishes itself from sibling lookup tools by being a meta-tool that explains server usage.

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 says 'Call it when a tool did not behave as you expected, or before a multi-step build, instead of guessing.' This provides clear when-to-use guidance and states the alternative (guessing) to avoid.

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 transparency burden and does so thoroughly. It discloses that only published parts are returned, that filling-up kits may differ from final kits, and that `layout` is included only when the connection owns the kit. It also explains `look`, `terrain`, and `composition` in confirmation terms, including the consequence of omitting them: 'it is the same parts on a flat floor in clear air'.

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?

There are many sentences, but most are purposeful for explaining non-obvious behavior like `look`, `terrain`, and ownership-based `layout`. The Coral Reef example and the warning about flat-floor pictures are illustrative and not wasted, though a slightly distilled version could maintain clarity with less text.

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 fully covers the return information: published parts in full get_asset detail, optional `look` and `terrain`, the owned-kit `layout` placements, and the always-present `composition` count. It also names the tool needed: `list_kits` or asset's `kit` field for the `id` parameter, making it complete for 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?

The input schema already fully documents both parameters: `id` with source and `compact` with surveying vs building guidance. The description itself adds no new parameter semantics, so it stays at the baseline for 100% schema coverage.

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 opens with 'Every published part of one kit' and 'compose a whole scene from one call', clearly identifying the tool's function as retrieving all parts of a kit with full asset-style detail. It distinguishes itself from get_asset by referencing 'the same detail get_asset gives' and from list_kits by operating on a single kit.

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 explicitly states when to use the tool: 'when you are composing a whole scene from one call' and when not to recommend the kit, as for 'a filling-up kit... recommend its parts rather than the kit'. The description also mentions the alternative get_asset and the compact option's surveying-vs-building guidance in the schema, covering when and when-not to use the tool.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses that terrain is non-flat (y=0 is wrong), returns ground height and slope for `at`, flat building sites, profile details (heights, grade, underwater points), world-coordinate alignment, and how kits join on a 64m grid. This is rich, transparent 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?

The description is somewhat longer than necessary but front-loaded with the core question. Every sentence adds value (e.g., explaining world coordinates, grid joining), so it is not wasteful. Minor redundancy could be trimmed, but structure is effective.

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 8-parameter tool with no output schema, the description covers the essential workflow: height lookup, flat areas, profile querying, and coordinate system. It doesn't detail every parameter, but the schema already does. It also adds context for multi-kit terrain joining, making it quite complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for key parameters: it explains how `at` returns a height to set as position.y, and how `profile` returns grade and underwater status. It also clarifies the output concept of 'flat_areas' (though the schema parameter is `flats`), slightly enhancing the schema's field descriptions.

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

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

The description explicitly states the tool's purpose: to determine the correct ground height for placement ('AT WHAT HEIGHT DO I PLACE THIS') and to identify buildable areas ('and where can I build'). It clearly differentiates from sibling tools like `get_asset` or `list_kits` by focusing on terrain-specific procedural generation and placement support.

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

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

The description provides clear usage guidance: use it before laying out a town, farm, or depot, and use `profile` for roads/walls. It does not explicitly name alternative tools or exclusions, but the context strongly implies this is the dedicated tool for terrain queries.

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 behavioral burden and handles it well. It discloses that matching is against knob names and option values, that the output includes a createAsset() call and GLB URL, and that confidence must be checked and low-confidence matches reported honestly. This goes well beyond the schema and prepares the agent for the tool's real 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?

The description is dense but somewhat rambling; the second sentence runs together multiple ideas ('matched against...', 'use the words...', 'into a ready createAsset() call...') and has awkward grammar. The first sentence is front-loaded and clear, and the confidence check is a useful final instruction, but the middle could be split into tighter sentences without losing 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 description covers the essential behavior: input semantics, output elements (createAsset call, GLB URL, confidence), and the correct handling of low-confidence results. It also covers the `look` edge case about shaders. It lacks a precise return-shape description or error behavior, but with no output schema present it still provides enough context for an agent to call and interpret results 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 67%: `want` and `look` are described, while required `id` is not. The description adds important meaning for `want` by explaining it is matched against knob names/option values and not colour vocabulary, and clarifies that `look` restyles independently of knobs and excludes shaders. It doesn't add anything for `id`, but that parameter is fairly self-evident as an asset identifier.

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

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

The description clearly states the tool's job: turn a plain-words request into a ready createAsset() call plus a GLB URL for a variant of a specific asset. It also distinguishes the matching vocabulary (knob names and option values) from colour vocabulary, which helps separate it from related asset tools. However, it could more directly say 'get/return a variant for an asset' instead of relying on the tool name and phrases like 'ready call.'

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 actionable guidance: use terms from the asset's -params.json, and do not use colour vocabulary for `want`. It also explicitly tells the agent to route shader-related requests (Underwater, Dither, Wobble, etc.) to the asset page instead of using `look`. It does not name sibling alternatives like get_asset or search_assets, but the when-to/when-not-to guidance is clear enough for the main decision.

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 of behavioral disclosure. It explains the statuses ('published' vs 'filling-up'), that all kits have null price and for_sale false, that filling-up parts are usable immediately, and that plans are free. This adds significant real-world semantics beyond the schema, though it doesn't describe the response format or pagination.

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 longer than average but every sentence contributes distinct information: definition, usage context, status meanings, pricing caveat, and routing to get_kit. It is structured logically, though slightly dense and could be tightened without losing meaning.

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 description covers kit semantics, statuses, pricing, and the sibling get_kit, which is strong context. However, it never explicitly states what the tool returns, such as 'a list of all kits' or whether the list is sorted or filterable. Since there is no output schema and no annotations, this is 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?

The input schema has zero parameters, so there is no parameter semantics to document. The description still adds value by explaining data fields like price_usd and for_sale, which helps the agent interpret results even though they are not input parameters.

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 explains what kits are and when to use them, but it never explicitly states the tool's action—there is no verb like 'list' or 'returns all kits.' It relies on the tool name for the core action and only implies the listing behavior through 'Use get_kit to fetch either.' This is clearer than a tautology but still vague about the tool's actual operation.

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 explicit guidance: 'Reach for a kit when the user is building a whole environment rather than looking for one object,' which directly addresses when to use this tool. It also names get_kit as the alternative for fetching a specific kit, so an agent can distinguish the two.

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 of behavioral disclosure. It explains that the tool returns a URL, works with paid assets via a public preview, and includes pricing/purchase info. While it could have been more explicit about read-only nature or error handling, it covers the key behavioral nuance well.

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

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

The description is three concise sentences, each earning its place: purpose, usage alternative, and paid-asset behavior. It is front-loaded with the most important information and contains no fluff.

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 simple one-parameter tool with no annotations or output schema, this description is highly complete. It covers what the tool does, when to use it, how it handles paid assets, and what the result contains, leaving little ambiguity.

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

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

The schema already fully describes the 'ids' parameter (array, up to 24, any order). The description adds only minimal context by mentioning 'assets' and 'scene' composition, but does not go beyond schema. Baseline of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool composes assets into a scene and returns a URL the user can open and orbit. It distinguishes itself from sibling tools by focusing on scene composition rather than individual asset retrieval, and explicitly contrasts with handing over three.js code.

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 explicit guidance to use this tool instead of providing a three.js block the user cannot run. It also provides context on handling paid assets, instructing to pass on pricing information to avoid 404 surprises.

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 explains this is a reporting/feedback call ('a report costs one call and is how this server gets better') and clarifies the four kinds. It does not detail post-call side effects such as whether a record is persisted, but the core behavior is disclosed.

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

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

The description is a single, well-structured paragraph that is front-loaded with the core purpose. It uses space efficiently to explain the four kinds and a motivational nudge, with no tangential details.

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 simple reporting tool with a rich schema and no output schema, the description provides enough context: what it does, how to use it, and the meaning of kinds. It does not state the return format, but that is not critical for a fire-and-forget report call; the overall guidance is complete enough.

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 covers all 5 params, so baseline is 3. The description adds substantial meaning to the `kind` enum by explaining each value in context, and provides an example for `need` ('we do not have that'). This raises it above baseline.

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

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

The description opens with a clear verb+resource ('Report a gap'), then enumerates four distinct kinds and explicitly contrasts server-side vs catalogue gaps, making it unambiguous and well-differentiated from sibling tools like search/get.

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 explicit usage guidance: 'offer this whenever a search is empty or thin' for asset kind, and defines scenarios for capability, output, and docs. It also encourages use rather than silence, providing clear context for when this tool is the right 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?

With zero annotations, the description carries the full burden and delivers: results mix FREE and PRO assets and each carries `free` and `plan`; paid assets are not sold individually so the agent must quote a plan, never a per-asset price; the agent must disclose free-versus-pro when recommending; and coverage "none"/"poor" has a defined fallback. This prevents exactly the high-cost errors (misquoting prices, recommending unavailable items) that annotations would otherwise have to cover. It is also consistent with the deprecated max_price_usd param noting per-asset prices are retired.

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 in the first sentence, and each subsequent block (trigger, triangle filter, pricing model, coverage fallback) earns its place — the pricing rule is critical context. Slight redundancy between "Results mix FREE and PRO assets" and "Paid assets are not sold individually," and the lowercase "you should" breaks flow, but the length is justified by the domain complexity.

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

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

For an 11-parameter tool with no output schema and no annotations, the description covers the critical domain traps: the free/pro result mix, the plan-not-per-asset pricing rule, the disclosure obligation, and the report_need fallback for poor coverage. The compact param partially sketches result fields, though the full-detail return shape and pagination behavior are not described. Nearly complete for a search tool of this complexity.

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

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

Schema coverage is 73%, so the schema already documents most parameters. The description adds genuine value by tying the triangle-budget parameters to the mobile/performance-sensitive use case. However, sort, class, and min_triangles remain undocumented in both schema and description, and the description does not compensate for those gaps — an adequate but not compensating score.

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?

"Search the Polyfork catalogue of low-poly 3D assets for three.js" names a specific verb, resource, and domain. The trigger "Use this whenever the user needs a model for a scene, game or site" clearly positions it as the catalogue search entry point, distinguishing it from sibling retrieval tools like get_asset, get_kit, and get_terrain.

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 an explicit trigger condition (user needs a model for a scene/game/site), a specific filtering rule (triangle budget for mobile/performance-sensitive targets), and an explicit alternative routing: offer report_need when coverage is "none" or "poor" rather than substituting. Missing an explicit when-not-to-use against siblings such as get_asset for an already-identified asset, 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?

No annotations are provided, so the description carries the burden of disclosing behavior. It explains what information is returned (key status, owned assets/kits, download viability) and implies a read-only diagnostic nature. However, it does not explicitly confirm non-destructiveness or describe the response format.

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

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

The description is two sentences, with the first sentence front-loading the tool's purpose and the second providing usage guidance. Every word contributes, and there is no redundancy or fluff.

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 zero-parameter tool with no output schema, the description gives sufficient context: what the tool reveals and when to call it. It is almost complete, though it omits the exact return format, which is a minor gap for agents expecting structured output.

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 has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies, and the description adds no unnecessary parameter details.

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

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

The description clearly indicates the tool reports the connection's current state: key attachment, owned assets/kits, and download viability. It distinguishes from siblings by focusing on the connection rather than individual assets or kits, though it lacks an explicit verb like 'retrieve' or 'list'.

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

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

The description explicitly states when to call the tool: 'before promising the user a paid file' and 'when a download 404s'. It provides concrete usage scenarios but does not mention when not to use it or compare to alternative tools.

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