Polyfork low-poly 3D assets

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

With no annotations, the description carries the full behavioral burden, and it does so thoroughly. It discloses that the tool 'NEVER charges anything itself,' that payment happens on the Stripe page with user approval, that a key is optional, and that `confirm` verifies payment and activates the plan. This is exactly the kind of side-effect and flow context an agent needs.

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 long but every sentence earns its place: it front-loads the core purpose, then explains safety, usage triggers, key behavior, and post-payment confirmation. There is no filler or repetition; the structure moves naturally from what to how to when.

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 two-parameter tool with no output schema and no annotations, this description is remarkably complete. It explains the no-argument listing mode, the checkout-link flow, the payment page, account creation behavior, and the confirm step with its API-key result. An agent has everything needed to call the tool correctly in all intended scenarios.

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?

Although the schema covers both parameters, the description adds crucial semantics beyond the raw schema: omitting `plan` lists what is on sale, and `confirm` must be the 'WHOLE' checkout_id, potentially with a second part after a dot, and it reports payment status. This transforms simple property names into actionable instructions.

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 specific verb and resource: 'Buy a Polyfork plan: Pro (monthly or yearly) or a one-payment lifetime seat.' It also clarifies the tool's actual role—returning a Stripe Checkout link rather than charging—so an agent can distinguish it from a direct payment tool. This is far beyond a tautology and clearly identifies what the tool does.

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 use the tool: 'Use it when a download needs a plan the user does not have and they say they want it, rather than sending them off to find the pricing page.' It also gives concrete usage patterns for both modes: calling with no arguments to list sale prices and calling again with `confirm` after payment. This leaves no ambiguity about when or how the tool should be invoked.

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 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?

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 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, the description carries the full burden and does meaningfully disclose behaviour: `want` is matched against KNOB NAMES and OPTION VALUES rather than colour vocabulary, the result includes a createAsset() call and a GLB URL for that exact variant, and a confidence value is returned whose low end should change how the agent reports back. Missing pieces are error/failure behaviour and what `id` must refer to, but the matching semantics and output shape are real, non-trivial disclosures.

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 text is short and purpose-first, but the second sentence appears spliced from two sources and dangles mid-clause, forcing the reader to reconstruct the intended instruction. That structural defect costs more than the brevity gains.

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?

No output schema exists, so the description does correctly sketch the return payload (createAsset() call, GLB URL, confidence) plus a confidence-gating rule. But for a tool with a nested `look` object and an unexplained required `id`, it omits how `id` is obtained and what happens when matching fails, leaving a real gap for an agent to trip over.

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%, and the description adds value for `want` by explaining it is matched against knob names and option values using the vocabulary from the asset's -params.json. `look` is already thoroughly documented in the schema itself. The required `id` parameter gets no explanation at all in either place, so the description only partially compensates for the coverage gap.

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

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

The opening states a recognisable transformation – plain-words request in, "a ready call" for a remixable asset plus a GLB URL out – which is a concrete verb+resource pairing. However, the description never distinguishes this from siblings like get_asset, find_matching, or preview_scene, and the middle sentence dissolves into a dangling clause ("not against colour vocabulary: use the words from its -params.json into a ready createAsset() call"), leaving the actual mechanism fuzzy.

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

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

There is actionable post-call guidance: "Check the returned confidence: on anything below high, tell the user what was actually applied instead of presenting it as exact." That is a genuine usage rule. But there is no when-to-use versus alternatives (when to reach for this instead of find_matching or get_asset), and no statement of prerequisites such as needing a valid asset id.

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.