3DAssets.dev

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

With no annotations, the description carries the behavioral burden and does well: it discloses the email verification code flow, the absence of passwords, the need for consent, and the fact that the API key comes from verify_account rather than this tool. It still leaves some edge behaviors (e.g., duplicate email handling, code expiry) unstated, but the core side effects are clear.

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

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

Four short sentences with no filler; purpose is front-loaded, followed by the most decision-relevant warnings and the next-step pointer. Every sentence earns its place.

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

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

For a mutation with no annotations or output schema, the description covers the essential workflow: required fields, emailed code, user consent, and verify_account for the API key. It could be more complete by addressing duplicate accounts or what this call returns, but the agent has enough to invoke it correctly.

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

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

Schema coverage is 50%, and the description adds some semantics by stating that only username and email are required and that no password field exists. However, it does not explain the optional name/website parameters beyond what the schema already says, so it 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?

States a specific action ('Create a contributor account for the user') with a clear resource, and positions itself against verify_account by explaining that create_account is the first step and verify_account retrieves the API key. The no-password note further removes ambiguity about what this tool is for.

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

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

Gives explicit when-to-use context: create only with the user's explicit consent, and only a username/email are needed. It also gives a when-not rule ('never ask the user for a password') and names verify_account as the required follow-up, so the agent knows the exact sequence.

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. It states that the asset is submitted for processing and review, implying a side effect, but it omits important details such as the irrevocable attestation requirement, the public CC0 dedication, or any potential for rejection. It gives some transparency but lacks comprehensive disclosure.

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

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

The description is a single concise sentence that flows well, leading with the prerequisite and then stating the action. It is efficient and front-loaded, with no redundant words 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?

Given the tool has 12 parameters with 5 required, the description is too sparse to be complete. It does not mention mandatory fields such as attestation (a legal requirement), category, or quarantineKey, nor does it explain the submission workflow beyond the basic step. An agent would need to inspect the schema deeply and may still miss critical context like the irrevocable nature of the dedication.

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 covers 67% of parameters with descriptions, and the tool description adds no extra parameter information. It only says 'describe the asset,' which loosely maps to summary and description fields but does not clarify required fields like attestation, category, or quarantineKey. Since schema coverage is high, baseline is 3, and the description does not elevate it.

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 action: finalizing an upload after the file has been PUT to the URL from get_upload_url. It specifies the sequence (after PUT) and the outcome (describe asset and submit for processing and review), which is specific and distinguishes it from other upload-related tools.

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

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

The description provides a clear precondition (after PUTing to the URL from get_upload_url), giving some guidance on when to use it. However, it does not mention alternative tools like submit_asset_from_url or when to choose one over the other, leaving usage decisions partly to inference.

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

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

With no annotations provided, the description carries the full burden. The 'get' verb implies a read-only operation, and the description transparently lists the returned content. However, it does not explicitly state that no side effects occur or how errors are handled for invalid slugs, leaving minor behavioral gaps.

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 sentence that front-loads the core purpose and then uses a colon to list the specific details returned. Every element is informative 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 simple getter with no output schema, the description adequately conveys what the tool returns by enumerating the main detail categories (CDN URL, licence, stats, bounding box, animations, loader snippets). It does not mention response format or error scenarios, but these are less critical for a single-asset fetch and the listed fields provide strong completeness.

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 has zero description coverage, so the description must explain the 'slug' parameter. It only says 'by slug', which adds little beyond the parameter name itself; it does not define what a slug is, how to obtain one, or provide examples. The schema's pattern covers format but the description fails to add meaningful semantic context.

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 a specific verb+resource ('Full details for one asset by slug') and enumerates the returned fields, making the purpose immediately obvious. It implicitly distinguishes from siblings like search_assets and get_asset_usage by focusing on a single asset's full detail set, but does not explicitly name alternatives.

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 'by slug' gives clear context on when to use this tool: when the caller has a specific asset slug and wants complete details. It does not mention exclusions or alternatives, but the intended usage is evident from the description.

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 and a minimal description, the behavior is only implied as returning code or steps. There is no mention of output format, potential side effects, or whether it is a read-only operation.

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

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

The description is a single concise sentence with no unnecessary words. It directly conveys the tool's purpose.

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 core purpose, but lacks details about the expected output structure or any additional context such as error conditions. For a simple retrieval tool, the missing output information is a notable 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 schema defines slug and framework but provides no descriptions. The tool description does not explain the meaning or purpose of these parameters, leaving the agent to infer from context. Since schema description coverage is 0%, the description should compensate but does not.

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 returns code or steps to load an asset in various frameworks, which distinguishes it from asset metadata tools. It is specific about the resource and action, though it doesn't explicitly name the verb '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?

No guidance is provided on when to use this tool versus alternatives like get_asset or search_assets. The description does not mention conditions or scenarios where this tool is preferred.

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?

The description discloses the returned data in detail and implies a read-only 'Get' operation, but with no annotations it does not state side effects, authentication requirements, or failure behavior. It is transparent about output but not about operational 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 a single dense sentence that packs all relevant output fields, but it remains focused and avoids fluff. The length is justified by the amount of specific data returned.

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

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

The output structure is well specified, which is important since there is no output schema. However, the description omits the meaning of the slug parameter and any error or edge-case behavior, leaving some context incomplete.

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

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

The only parameter, slug, is not explained in the description; the schema only provides pattern and length constraints. The description adds no semantic meaning about what slug refers to or how it should be supplied.

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 fetches one demo and enumerates its contents (pack, spawn point, walkable bounds, POIs, placements). This distinguishes it from sibling tools like list_demos, get_pack, and get_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 explains how to use the result ('Load the models with a plain GLTFLoader and apply the transforms'), but it does not explicitly state when to choose this tool over list_demos or other alternatives. Usage guidance is implied rather than direct.

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?

Since no annotations are provided, the description carries the full burden. It implies a read-only operation (fetching a manifest) without side effects like modification or creation. It does not explicitly state that no data is changed, but the phrasing is clear enough to infer non-destructive 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 concise, front-loaded with the main action, and uses two clear sentences. It avoids unnecessary detail while conveying the essential 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 is sufficient for an agent to understand the general function, but it lacks context about what a 'pack' represents and how 'slug' is used. Given the broader set of sibling tools, this missing detail could cause confusion, though the description covers the core action adequately.

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 only parameter 'slug' is not described in the schema, and the description does not explain what a slug represents or how it should be formatted. The name itself gives some hint, but the description adds no meaningful semantic detail beyond what is already visible from the parameter name.

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 purpose: retrieving a free pack manifest with CDN URLs and related details. It also mentions the alternative usage of downloading models individually or using the starter scene, which provides a clear functional scope.

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 does not explicitly compare this tool to sibling tools like get_asset or search_packs. It implies its use case by describing what it returns, but does not give direct guidance on when to choose it over alternatives.

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

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

With no annotations, the description carries the burden of explaining side effects. It states it 'returns a presigned PUT URL' which is a behavior, and implies the actual upload happens later via finalize_upload, so it does not create or modify permanent records directly. However, it omits details like URL expiration, authentication requirements, or whether any server-side state is created. This is acceptable for a simple operation but not 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 two sentences, direct, and free of redundant or irrelevant information. It front-loads the core purpose (presigned PUT URL) and immediately follows with the next step, making it efficient and scannable for an agent.

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?

Lacking an output schema, the description does not need to explain return values, but it does indicate the next operation (finalize_upload). It covers the key workflow steps, though it omits potential error cases, upload limits, or how the URL should be used (e.g., HTTP method, headers). For a simple two-step flow, it is reasonably complete.

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

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

The schema has no descriptions for parameters, and the description only partially explains them. It connects 'filename' to .glb and 'withPreview' to optional PNG preview, but 'contentLength' is entirely unexplained—what it represents, why it's required, and how it's used remain ambiguous. Given the low schema coverage, the description should provide more detail but does not.

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 returns a presigned PUT URL for a .glb file with an optional PNG preview, which is a specific and distinct action. It names the exact resource type and even names the next step (finalize_upload), making its purpose unambiguous relative to sibling tools like submit_asset_from_url or finalize_upload.

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 by saying 'For clients that can upload bytes' and instructs to call finalize_upload after, which tells the agent when to use this tool and what to do next. It does not explicitly mention alternatives (like submit_asset_from_url), but the condition 'can upload bytes' effectively distinguishes it from URL-based uploads.

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. It discloses freshness ('refreshed hourly'), completeness ('not exhaustive'), and non-blocking behavior ('never block uploads'), which is helpful, but it omits details on permissions, rate limits, errors, or side effects. This is partial transparency.

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 sentences, each carrying meaningful information without redundancy. It is tightly written and front-loads the primary action before adding secondary 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?

Given the tool's simplicity and the absence of an output schema, the description covers core aspects like source, refresh policy, and non-blocking behavior. However, it does not describe the shape or content of the returned model suggestions, which would be helpful for an agent to understand the tool's full utility.

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

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

There is only one parameter (q), and the description provides no explanation of what q means or how it is used. The schema itself also lacks a description for q, so there is zero coverage. The description fails to compensate, leaving the parameter completely unexplained.

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

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

The description clearly states the action ('Search'), the resource ('model suggestions'), and the source ('OpenRouter'). It distinguishes this tool from other listing/search tools by focusing on models specifically.

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 some usage context (e.g., 'refreshed hourly', 'not exhaustive', 'unavailable suggestions never block uploads') but does not explicitly state when to use this tool versus any alternative, and no sibling tools are mentioned. Guidance remains implicit rather than explicit.

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?

The verb 'List' implies a read-only operation with no side effects. With no annotations provided, the description carries the burden, and it is sufficiently transparent for a simple listing tool.

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, concise sentence with no unnecessary words, while the parenthetical adds useful cross-tool context.

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

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

For a parameterless, read-only listing tool with no output schema, the description fully covers what an agent needs to know to call it correctly.

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

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

The tool has no parameters, so no parameter documentation is needed. The baseline of 4 applies per the rubric for tools with zero 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?

Clearly states the tool lists categories on 3dassets.dev, and the parenthetical about slugs being accepted by other tools helps distinguish its purpose from related list tools.

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

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

Implies usage for retrieving categories, and hints that slugs are used elsewhere, but does not explicitly state when to prefer this over alternative listing tools or provide exclusion criteria.

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 must convey behavior. It says 'list', implying a read-only operation without side effects. However, it does not specify what the returned list contains (e.g., IDs, names, URLs), which is a transparency gap for the agent.

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 no unnecessary words. It directly states the resource ('walkable demo scenes'), the action ('list'), and a pointer to a related tool, all efficiently.

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 should clarify what the list output looks like. It doesn't mention whether it returns names, IDs, or other details. The pointer to get_demo adds some context, but the lack of output specification makes it incomplete for an agent to fully anticipate the result.

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

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

There are no parameters in the schema, and per the rubric, 0 parameters earns a baseline score of 4. The description correctly makes no mention of parameters, aligning with the schema.

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

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

The description clearly states the action: 'list the walkable demo scenes'. It explicitly distinguishes this tool from get_demo by noting that get_demo is for placements, making the purpose unambiguous.

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

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

The description provides usage guidance by stating 'Use get_demo for the placements', which tells the agent when to use this tool versus the sibling. However, it could more explicitly state when to use this tool itself, such as 'when you need an overview of available demos'.

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 or output schema, the description carries the full burden. It states the return value but does not explicitly mention side effects, authentication, or error behavior. For a read-only constant lookup, the disclosure is adequate but not rich.

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

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

The description is two short sentences, front-loaded with the key fact and with no unnecessary words. It is concise and well structured.

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 absence of an output schema, the description adequately conveys the sole return value. It could be slightly more explicit about the returned format, but for such a simple constant result it is sufficiently complete.

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

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

The tool has zero parameters, so the baseline score is 4. No parameter documentation is needed, and the description does not introduce any conflicting parameter expectations.

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?

Description clearly states the tool returns the sole accepted submission dedication, CC0 1.0 Universal, and explicitly notes that no licence selection is needed. This is specific and distinguishes it from other list-type tools like list_categories or list_tags.

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

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

Provides clear context that this is the only accepted dedication and that no selection is required, which implicitly tells an agent when to consult it. It does not explicitly name alternative tools, but the guidance is sufficient for this simple read operation.

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 implies a read-only operation and gives the slug hint, but it does not disclose authentication requirements, rate limits, or response format. For a simple list, this is adequate but not comprehensive; it does not contradict annotations since none exist.

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 sentence with no redundancy, front-loading the core action and following with a useful parenthetical. Every word earns its place.

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

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

For a parameterless list tool with no output schema, the description provides the key fact that the result contains slugs for other tools, which is sufficient for an agent to understand the purpose and use the output. It could be more explicit about the response structure, but the hint about slugs covers the essential need.

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 the baseline is 4. The description does not need to explain parameters, and it adds the contextual note about slugs, which is helpful for understanding how the output will be used.

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 verb 'List' and the resource 'tags available on 3dassets.dev', and adds the valuable note that slugs are what other tools accept, which clarifies the output's utility. It is not a tautology and distinguishes the tool's purpose from other list tools like list_categories or list_licenses.

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 implies the tool is used to obtain tag slugs for other tools, but it does not explicitly say 'use this when you need tag identifiers to pass to other tools' nor does it contrast with sibling list tools. The usage context is inferred rather than stated.

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

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

The description is transparent about the read-only nature of the operation ('List') and clarifies the meaning of the 'pendingEdit' status. However, it does not disclose potential details like pagination, sorting, or whether only published items are included. With no annotations provided, the description carries the burden, but it is adequate for a simple listing operation.

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

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

The description is a single, concise sentence that conveys the essential information without any extraneous detail. It is well-structured and easy to read.

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 empty input schema and lack of output schema, the description provides sufficient context by stating what is returned (submissions with status) and explaining the 'pendingEdit' state. It could be more complete by listing return fields, but it is adequate for an agent to understand the tool's purpose and expected 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 no parameters (empty schema), so the baseline score is 4. The description does not need to explain parameters, and it correctly indicates that the tool takes no input.

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 function: listing the user's submissions with status. It distinguishes itself from siblings like 'my_packs' (lists packs) and 'search_assets' (searches assets) by explicitly focusing on the user's own submissions.

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 does not provide explicit guidance on when to use this tool versus alternative tools. It does not mention that search_assets might be better for filtered searches or that my_packs is for packs. The differentiation is only implied by the wording, not explicitly stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly describes the returned content (statuses of proposals and member models), but it does not explicitly state that this is a read-only operation, nor does it mention any limitations like pagination or ordering. The description is adequate but lacks explicit safety or edge-case context.

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 sentence that front-loads the action ('List') and the resource, followed by the specifics of what is included. Every word adds value, with no filler or redundancy.

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

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

For a parameterless list tool with no output schema, the description provides the essential return details: statuses of proposals and member models. It is reasonably complete, though it could mention that it returns only the authenticated user's proposals (already implied) or any pagination behavior. Given the simplicity, it suffices for an agent to call it correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (trivially). With no parameters to document, the description does not need to add parameter meaning. The baseline for 0 parameters is 4, and the description does not introduce any ambiguity about input.

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 lists the user's pack proposals along with status details (submitted/approved/rejected) and member model status. The verb 'List' plus the specific resource 'user's pack proposals' differentiates it from siblings like search_packs (which searches all packs) and get_pack (which fetches a single pack).

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 no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for the user's own proposals only, nor does it contrast with search_packs or my_assets. The usage context is only implied by the phrasing, leaving the agent to infer when to call it.

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

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

With no annotations, the description carries the behavioral burden. It discloses return format (direct CDN URLs with CORS * and immutable), loading method (GLTFLoader), and licensing (CC0, no attribution). It doesn't mention pagination or sorting behavior, but covers the key operational aspects.

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

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

Four sentences, front-loaded with purpose, then returns and licensing. No fluff, every sentence adds value.

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 9-parameter search tool with no output schema and no annotations, the description covers purpose, return format, licensing, and search dimensions. It doesn't detail pagination or sort defaults, but the schema covers those. It is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 78%, so baseline is 3. The description adds meaning by explaining category (what it is), theme (what world), style (what look), which goes beyond the schema's terse slug descriptions. It also mentions text search, aligning with q/query.

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

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

States a specific verb (Search), resource (free GLB catalogue on 3dassets.dev), and search dimensions (text, category, theme, style). Clearly distinguishes from sibling search_packs by focusing on assets rather than packs.

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

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

Provides clear context on what it searches (free GLB catalogue) and the search facets. Does not explicitly mention alternatives like search_packs, but the purpose is unambiguous, allowing an agent to infer when to use it.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it signals a read-only search operation and specifies the returned data (file counts, total bytes, starter scene URLs) and the free-only scope. It does not mention pagination or ordering, but those are minor for this type of tool.

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

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

Three short sentences, each earning its place: the first defines the search scope, the second states the output, and the third routes to the relevant sibling. The most important information is front-loaded with no filler.

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

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

The description compensates for the absence of an output schema by listing key return fields, and the schema fully documents all four parameters. It lacks explicit filter-combination semantics and pagination details, but an agent has enough information to invoke the tool 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 description coverage is 100%, so the baseline is 3. The description reinforces the text/theme/style dimensions but does not add meaning beyond the schema's parameter descriptions. The q/query alias is already documented in the schema.

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

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

The description uses a specific verb ('Find') with a precise resource ('cohesive free GLB game kits') and names the search dimensions: text, theme, and style. It also distinguishes itself from get_pack by explicitly routing individual model retrieval to that sibling.

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 states when to use search_packs (searching kits by text, theme, or style) and explicitly names get_pack as the alternative when individual models or loader snippets are needed. This gives the agent a clear decision rule.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses download/validate/re-encode steps, human review before publishing, the CC0 dedication requirement, file size and triangle limits, texture constraints, and the need for the user's API key. No contradictions with annotations exist.

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 four tight sentences that front-load the core action and then add constraints in order of importance. Every sentence adds a meaningful fact, with no filler or repetition of schema boilerplate.

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 covers the essential operational context: source format, hosting requirement, processing pipeline, human review, license/legal caveat, and size limits. Combined with the rich schema descriptions for required fields, an agent has enough information to invoke the tool 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 description coverage is 73%, and the schema already explains most parameters. The description adds useful constraints for the URL parameter (public HTTPS, .glb, max 25 MB, 1M triangles, embedded textures only) and reinforces the CC0/attestation requirement, but it does not systematically address all parameters. It is adequate but not transformative beyond the schema.

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

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

The description states a specific action ('Submit a .glb hosted at a public https URL on the user's behalf') and a clear resource (a hosted .glb asset). It also distinguishes itself from sibling upload/submit tools by emphasizing the URL-based submission flow and the human review pipeline.

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 clearly implies when to use the tool: when the asset is already hosted at a public HTTPS URL and needs to be submitted on behalf of a user with their API key. It does not explicitly name alternatives like get_upload_url/finalize_upload or state when not to use it, but the context is strong enough for an agent to select it.

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

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

With no annotations, the description carries the full behavioral burden. It transparently explains that each model is reviewed individually, the pack requires human approval, pending members become published only after approval, nothing goes live beforehand, and the user is emailed the outcome.

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 concise and well-structured, using clear sentences that convey the workflow, constraints, and outcome without unnecessary verbosity or repetition.

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

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

The description provides good context about prerequisites, review, approval, and email notification. It does not mention response format or error cases, but given there is no output schema and the workflow is clearly outlined, it is reasonably complete.

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

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

The description only explains the assets parameter by referring to model slugs. It does not clarify the meaning or expected content of title, summary, or description parameters, leaving those to be inferred from the schema constraints alone.

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 purpose: grouping the user's own uploads into a pack proposal. It also distinguishes itself by referencing related upload tools and clarifying that these are proposals subject to review.

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?

Explicit guidance is provided on the correct sequence: upload models first with finalize_upload or submit_asset_from_url, then pass the slugs. It also explains the review and publishing behavior, leaving little ambiguity about when to use this 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 provided, the description carries the full burden and does well: it discloses the immutable GLB file and the review-queue behavior where a proposal awaits human approval while the live version keeps serving. It stops short of covering auth requirements, error conditions, or success/return semantics, but the key side effects of this mutation tool are 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?

Three sentences with zero filler, front-loaded with the core purpose, followed by the hard constraint, then the published-asset caveat. Each sentence earns its place and the structure builds logically from action to boundary to side-effect.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the most important behavioral contract (immutable GLB, review queue for published assets) but leaves gaps: it gives no guidance on required slug identification, no parameter context, and no success/error semantics. Adequate for core use, incomplete for edge cases.

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 only 25% (2 of 8 params: aiModel and category), so the description must compensate, but it adds no parameter-level meaning whatsoever. It never explains that slug identifies the asset to edit, nor the semantics of tags, title, summary, or description. The behavioral notes are useful but do not clarify any individual parameter.

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 first sentence names a specific verb+resource ('Edit the metadata of one of the user's own assets'), which clearly distinguishes it from read tools (get_asset, my_assets) and creation/upload tools (submit_asset_from_url, finalize_upload). The GLB-immutability sentence further sharpens the boundary between metadata editing and file replacement.

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 clear context for when the tool applies (editing one's own assets' metadata) and an explicit exclusion ('The uploaded GLB can never be changed'), plus a critical caveat that editing a published asset does not change the live version. However, it names no alternative tool explicitly, so the when-to-use-vs-when-not guidance is implied rather than stated.

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

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

The description discloses the main side effect: showing the API key to the user and instructing them to configure it as a Bearer token. This is transparent about the output and subsequent user action. It does not mention error conditions or rate limits, but that is not critical for this verification action. No annotations are present, so the description carries the full transparency burden, which it mostly fulfills.

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 concise, consisting of two clear sentences. It states the action, the output, and the user instruction without any redundant wording or unnecessary detail. It is well-structured and front-loaded with the core purpose.

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 there is no output schema, the description explains what should be done with the returned key (show and instruct). It covers the essential context for an agent to complete the task. However, it does not mention potential failure scenarios (e.g., invalid code) or any additional context like token expiry, but for a simple verification step, this is adequate.

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 description provides no explanation of the 'email' and 'code' parameters beyond their names. The schema defines formats (email format and 6-digit pattern), but the description adds no semantic meaning, such as why the email is needed or how the code is validated. With 0% schema description coverage, the description fails to compensate for its lack of parameter guidance.

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 function: exchanging a 6-digit code for an API key and instructing the user to configure it. It uses specific verbs ('Exchange', 'Show', 'tell') and uniquely identifies the resource (account API key). This distinguishes it from sibling tools like create_account, which handles account creation.

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 implies usage after receiving an emailed code, but it does not explicitly state when to use this tool versus alternatives such as create_account. No direct comparison or decision guidance is provided, leaving some ambiguity for an agent deciding between verification and other account-related operations.

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