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 provided, the description carries full burden. It details special cases (has_ik returning gait/arm blocks), paid-asset behavior (returns price and buy link), and caller-specific download URLs. It also instructs to 'quote both' for paid assets, providing rich behavioral insight.

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

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

The description is front-loaded with the primary purpose and each subsequent sentence adds valuable specifics. It is somewhat dense, especially the first sentence, but there is no redundancy or filler, making it appropriately concise for the information conveyed.

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 thoroughly explains all return scenarios: standard asset details, the has_ik block, and paid-asset fallback. It also mentions how the data can be applied, making it complete for a one-parameter 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?

The schema already documents the only parameter 'id' with a clear example. The description adds no additional meaning about the parameter itself, only about the output. With 100% schema coverage, the 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 clearly states 'Full detail for one asset' and enumerates specific returned fields (size, triangle count, palette, animatable parts, renders, download URLs). This distinctly differentiates it from sibling search/list tools by focusing on retrieving comprehensive data for a single asset.

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 conveys clear usage context: when you need full detail for a specific asset and even how the data can be used (e.g., with /cdn/walk.mjs). However, it does not explicitly mention alternative tools or when not to use this one, so it lacks explicit 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?

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, the description carries the transparency burden. It adds useful context about kit statuses ('published' vs 'filling-up') and clarifies that filling-up kit parts are usable today, which helps the agent interpret results. However, it does not disclose the return format, pagination, read-only nature, or any other tool-specific 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 has four sentences, each contributing domain definition, usage guidance, status explanation, or an alternative tool. It is slightly longer than the minimal 'list kits' statement, but every sentence earns its place without being verbose.

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 list tool with no output schema, the description covers the key context: what kits are, when to use them, their statuses, and how to fetch parts. It does not explicitly state that the tool returns a list of kits with their statuses, but the name and context make that sufficiently clear.

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 schema coverage is effectively 100%. No parameter description is needed, and the baseline of 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 clearly identifies kits as the resource and distinguishes this tool from get_kit, which fetches parts. However, it never explicitly states that list_kits lists all kits; the purpose is inferred from the tool name and the usage guidance rather than stated 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?

The description explicitly says when to reach for a kit ('building a whole environment rather than looking for one object') and points to an alternative ('Use get_kit to fetch the parts of either'). This gives clear context for when to invoke this tool versus related 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 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?

No annotations are provided, so the description carries the full burden. It discloses several non-obvious behaviors: results mix FREE and PRO assets, paid assets are not sold individually and instead come with plans, the agent should quote the plan rather than a per-asset price, deprecated max_price_usd is superseded by free=true, and coverage responses like 'none' or 'poor' need specific handling. It also warns that full-detail results at limit 50 can be rejected by some clients and directs to get_asset for the rest.

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 states the search purpose, gives usage guidance, discloses pricing behavior, gives recommendation guidance, and explains failure handling. The most important operational facts (search purpose and pricing model) are front-loaded, with compact and deprecated-price details later. It is appropriately sized for an 11-parameter tool with no annotations.

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?

Despite having 11 parameters and no output schema, the description gives enough operational context for an agent to call the tool correctly: when to use it, how to filter for mobile/performance, how to present results (quote plan not price, say which is free), and what to do on poor coverage. The schema already documents most parameters, and the description fills the gaps around pricing, deprecated fields, and response-size handling. No critical missing behavior is apparent.

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 73%, and the description adds meaning beyond the schema for several params: it explains the ik capability ('walks with its feet finding your ground and staying planted', 'rooted boom whose tip you can aim'), clarifies that max_price_usd is deprecated in favor of free=1, and explains when compact=true should be used. It doesn't add syntax for min_triangles or limit beyond schema, but those are fairly self-evident and the description compensates for the main coverage gaps.

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 ('Search the Polyfork catalogue of low-poly 3D assets for three.js') and adds concrete scope: results mix FREE and PRO assets, coverage may return 'none' or 'poor', and the tool is for finding models for scenes, games, or sites. It clearly differentiates from siblings like get_asset (which returns the rest of an asset's detail) and report_need (used when coverage is missing).

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 when-to-use guidance ('Use this whenever the user needs a model for a scene, game or site'), performance-related filtering ('Filter by triangle budget when the target is mobile or performance-sensitive'), and when-not-to-substitute guidance ('If coverage comes back none or poor, tell the user we do not have it and offer report_need rather than substituting something unrelated'). It also explains when to use compact rows ('Use this whenever you are surveying rather than choosing').

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.