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

With no annotations, the description carries the full burden for behavioral disclosure. It does not mention that deletion is permanent, require confirmation, or have side effects, adding no context beyond the name itself.

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, but it is under-specified, essentially restating the tool name. It lacks the depth expected for a destructive operation, making it not 'appropriately sized' despite being short.

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 simple delete operation, the description is too minimal. It does not convey required parameters, effects, or any operational context, leaving the agent without enough information to use 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 description coverage is 0%, and the description does not explain the 'name' or 'project_id' parameters. It provides no semantic meaning beyond the schema's structural definition.

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 (delete) and resource (saved search) with a specific verb, distinguishing it from sibling tools like save_search, run_saved_search, and list_saved_searches.

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, nor any exclusions or prerequisites. It only states what the tool does without contextual direction.

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

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

No annotations are provided, so the description carries the full burden. It only states the return value ('description + 3 sample assets') but does not disclose any behavioral traits such as side effects, error conditions, permissions, or assumptions about the input, such as what happens if the label does not 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, concise sentence that immediately communicates the core functionality. Every word provides value, and there is no redundancy or irrelevant detail.

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 an output schema, the description is incomplete because it does not clarify parameter semantics or provide any context about how this tool fits with sibling tools. The lack of schema descriptions combined with minimal textual description means the agent must infer too much from the tool name and parameter names.

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 0% description coverage, and the tool description does not explain the meanings of 'axis' and 'label' parameters beyond their names. The description provides no additional semantic context for the parameters, leaving the agent with only the field names to infer meaning.

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: it returns the description of a single label and three sample assets. This is specific about the resource (label) and output, distinguishing it from sibling tools like list_labels or find_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 implies usage for a single label but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or provide references to sibling tools for other scenarios.

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

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

With no annotations provided, the description carries full burden. It does add behavioral context by revealing that results include recommendation rationale (matched_labels + why), which is useful. However, it does not explicitly state whether the operation is read-only, whether it has side effects, or any constraints like required permissions. The description covers only part of the behavioral picture.

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 extremely concise: two short sentences that deliver the core purpose and a distinguishing output feature. Every word contributes value, with the main point front-loaded. 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?

The tool has a very rich input schema and exists among many asset-related siblings, but the description fails to explain when to use it versus alternatives, how the main parameters work, or what to expect in the output beyond rationale. Even though an output schema exists, the description should still provide enough context for an agent to choose and invoke the tool correctly; it does not.

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 0%, yet the description only clarifies two aspects: natural language (likely the 'query' or 'label_query' field) and label boolean filters (likely labels_all/labels_any/labels_none). The remaining parameters (count, diversity, weight overrides, pack_id preferences) are left unexplained. Since the single req parameter wraps a large object with many distinct fields, the description does not meaningfully compensate for the lack of schema 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 clearly states that the tool 'finds assets' using natural language and label boolean filters, which are specific methods. It also mentions the unique feature of returning matched_labels and why, which differentiates it from siblings like list_assets or get_asset. The verb 'finds' plus resource 'assets' with specific search modes makes purpose unmistakable.

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 use cases (searching by natural language/filters) but does not explicitly contrast with similar tools like list_assets or get_asset, nor does it explain when to prefer this over alternatives. No 'when not to use' or alternative tool names are mentioned, so guidance is merely implied 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?

No annotations are provided, so the description carries the transparency burden. It implies a read-only operation ('retrieve') but does not disclose error behavior, permissions, rate limits, or any side effects. This is minimal but not contradictory.

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, front-loaded sentence with no redundancy. It conveys the core purpose 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?

For a simple get-by-id/path tool with an output schema, the description covers the essential operation. However, it omits the relationship between the two keys and any context for when to use this over sibling search tools.

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 0%, so the description must compensate. It adds that asset_id and path are the identifying keys, which is useful. However, it does not clarify whether they are mutually exclusive or optional, nor explain the required 'req' wrapper 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 description clearly states the action ('조회' / retrieve) and specific resource ('단일 자산 메타' / single asset metadata), and specifies the two lookup keys (asset_id or path). This distinguishes it from sibling tools like list_assets or find_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?

No guidance is given on when to use this tool versus alternatives such as find_asset or list_assets. There is no mention of context, exclusions, or when to prefer another sibling.

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 discloses pagination behavior, which is useful, but it does not mention that the operation is read-only, whether it returns all asset kinds by default, or any potential performance implications. The purpose hint of 'debugging/exploration' adds some context but is minimal.

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 compact sentence that front-loads the verb and resource, with a parenthetical clarifying the intended context. Every word contributes meaning without redundancy.

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

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

Despite having an output schema, the description lacks essential context for correct invocation: it does not explain filtering by kind or pack_id, pagination parameters, or the fact that it lists all assets (which could be a large result). The tool's complexity (nested request object with 4 properties) and zero schema coverage demand a more thorough description.

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 0%, so the description must compensate for the undocumented parameters (kind, page, pack_id, page_size). It mentions pagination generically but provides no detail about how the parameters control behavior, what the kind values mean, or defaults. This is a significant 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 description states the tool lists all assets in the library with pagination, which clearly identifies the verb and resource. It distinguishes from siblings like get_asset and find_asset by emphasizing 'all assets' (전체 자산) and the debugging/exploration intent, though it doesn't 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 parenthetical '(디버깅/탐색)' implies the tool is intended for browsing or debugging rather than targeted retrieval, but it does not explicitly state when to use this tool instead of find_asset or get_asset, nor does it provide exclusions or alternative tool names.

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

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

No annotations are provided, so the description carries the full burden. It clearly states it 'returns a list', which implies a read-only operation, and adds the specific detail of '24 axes'. However, it does not disclose potential errors, data formats, or any other behavioral nuances.

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 front-loads the action and resource. It contains no extraneous information and is highly efficient.

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 zero-parameter list tool with an output schema, the description is sufficiently complete. It clearly states what is returned and the count. The output schema covers return structure, so no further detail is needed.

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 zero parameters, so the baseline is 4. The description adds context about the output (24 axes of the label vocabulary) which is helpful even though no parameter explanations are needed.

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 the specific verb '반환한다' (returns) and clearly identifies the resource: the 24 axes of the label vocabulary. This distinguishes it from sibling tools like list_labels (which likely lists labels) and describe_label (which describes a single label).

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 by stating exactly what the tool returns, but it does not explicitly mention alternatives or when to prefer this over list_labels or describe_label. The usage is clear from the name, but no direct guidance is provided.

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 burden of behavioral disclosure. It adds a useful detail about cache reuse when the signature is identical, which is beyond what the schema or name would imply. However, it omits other relevant traits such as whether this is a read-only operation or if any side effects occur.

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 communicates both the primary purpose and a notable behavioral trait. It is not verbose, but its brevity sacrifices information richness, so it is efficient yet not fully 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?

An output schema exists, so return values are covered. However, the description lacks parameter semantics, usage guidance, and sufficient behavioral detail. For a tool with one required nested request object and three optional fields, the description is insufficient for correct invocation.

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

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

The input schema has zero description coverage, and the description does not compensate. None of the parameters (axis, enabled_only, with_description) are explained, making it impossible for an agent to know how to set them for desired results.

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 clear action ('returns') and a specific resource ('label vocabulary list + catalog signature'). However, it does not explicitly distinguish itself from sibling tools like list_label_axes or describe_label, relying on the tool name and context.

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. The description focuses solely on the return value and caching behavior, with no mention of prerequisites, filters, or intended use cases.

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 burden of behavioral disclosure. It reveals the output scope (catalog, asset count, aggregate_meta) but does not state whether the operation is read-only, whether it triggers any scanning, or if any side effects occur. For a list operation, this is a minor gap, so it earns a 3.

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, compact sentence that front-loads the verb and resource. Every word contributes meaning, and there is no unnecessary filler. This is ideal for a parameterless tool.

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 (0 parameters, output schema present), the description covers the essential output components and resource qualifier. It doesn't explain usage context or alternatives, but that gaps are captured in usage_guidelines. The core functionality is complete enough for an agent.

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 appropriately focuses on the output content rather than parameter details, which are nonexistent. It adds value by explaining what the return payload includes.

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 it lists the registered pack catalog, along with asset count and aggregate_meta. The verb '나열' (list) is specific, and the resource (pack catalog) distinguishes it from tools like list_assets. However, it doesn't explicitly contrast with sibling tools such as list_unity_packages, so it falls short of a 5.

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 about when to use this tool versus alternatives like list_assets or list_unity_packages. There is no mention of use cases, preconditions, or exclusions, leaving the agent to infer appropriateness from the name and description alone.

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 burden of behavioral disclosure. It does reveal that results are ordered by recent usage and scoped by project_id, which is useful. However, it does not state whether the operation is read-only, what happens with a null project_id, or any other behavioral traits.

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, brief sentence that is front-loaded with the core meaning. It contains no unnecessary words and is perfectly sized for the tool's simplicity.

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 existence of an output schema, the description is mostly adequate. However, it fails to clarify the optional project_id behavior (especially the null default), which is a notable gap for an otherwise simple tool.

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

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

The schema has one parameter project_id with no description, so the description is the only source of meaning. It adds that the list is per project_id, but does not explain the default null behavior, leaving ambiguity about whether all projects are included when null is passed.

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 that this tool lists saved searches, organized by project_id and sorted by most recently used. This distinguishes it from sibling tools like save_search, delete_saved_search, and run_saved_search, 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 gives no guidance on when to use this tool versus alternatives, such as list_assets or find_asset. It does not mention any exclusions or specific scenarios, leaving the agent without context for selection.

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 disclosing behavior. It mentions supported features (state/publisher/asset_name filters, pagination, preview count) but does not explain how they behave, result ordering, pagination defaults, or any side effects. This is insufficient for a tool with zero annotation coverage.

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, front-loaded sentence that states the main purpose and key features without any filler. It is appropriately concise and easy to parse.

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 tool has moderate complexity with a nested request object and multiple parameters, yet the description covers only high-level features. With no annotations and no usage context, it leaves significant gaps about when to use it, limitations, and behavioral details. The output schema exists but does not compensate for missing usage and behavioral context.

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 0%, but the description names the high-level concepts (state/publisher/asset_name filters, pagination, preview count) that map to the schema's parameters. It adds some meaning beyond the schema, but does not explain parameter defaults, bounds, or exact semantics. The schema itself provides titles and constraints, so the description partially compensates.

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 it returns a list of unity_imports and enumerates key features (filters, pagination, preview count). The verb+resource are specific, but it does not explicitly differentiate from sibling tools like list_packs or list_assets, though the resource name is distinctive.

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 on when to use this tool versus alternatives. It lists capabilities but does not mention exclusions, recommended scenarios, or why one would choose this over list_packs or list_assets.

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 states the action 'records' but does not disclose whether the operation appends, overwrites, or requires specific permissions, nor does it mention any side effects or idempotence. This is a significant gap for a mutation 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 sentence with no filler or redundant wording. It is efficiently front-loaded with the core action and purpose. However, its brevity contributes to under-specification, which is a completeness concern rather than a structure issue.

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?

Although the tool has an output schema (which may cover return values), the description does not explain the required input parameters or provide guidance on valid invocation (e.g., the meaning of source='manual', when to supply query_id, or how context is used). For an agent to correctly call this tool, it would need to infer parameter semantics from the schema alone, which is insufficient.

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, and the description does not elaborate on any of the parameters (project_id, asset_id, source, context, query_id). The phrase 'asset adoption history' only vaguely hints at asset_id and project_id but provides no concrete semantics, typical values, or relationships between parameters. The description fails to compensate for the schema's lack of detail.

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 ('records') and the resource ('asset adoption history'), using the specific Korean verb '기록한다'. It also notes the tool is a core input for consistency weighting, which distinguishes its purpose from read-only sibling tools like get_asset and list_assets. However, it doesn't explicitly contrast itself with other write tools like set_project_pin, though the distinct resource type provides differentiation.

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 mentions the tool is a 'core input for consistency weighting', which implies it should be used when an asset is adopted. This gives contextual purpose but does not explicitly state when to use versus when not to use, nor does it name any alternatives or exclusions. The usage is only implied by the tool's role.

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 available, so the description carries the full burden. It discloses that feedback serves as penalty learning input, which is a meaningful behavioral implication affecting recommendation models. However, it does not mention reversibility, required permissions, or side effects beyond the learning context, leaving notable 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 concise sentence that efficiently conveys the core function and purpose, with no redundant words or unnecessary detail.

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 lack of annotations and output schema, the description is incomplete for an agent to fully understand invocation context. It does not state when to use the tool, what response to expect, or any usage constraints, which are critical for a feedback recording tool.

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

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

Schema description coverage is 0%, and the description does not explain any parameters such as query_id, asset_id, or reason. The phrase 'recommendation results' indirectly hints that query_id and asset_id relate to a recommendation, but this is not explicit, and the description adds minimal value over the raw 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 tool records user feedback on recommendation results using the specific verb 'records' and the resource 'recommendation results', also noting the purpose as penalty learning input. It distinguishes from sibling tools like record_asset_use by focusing on feedback rather than usage, but it does not explicitly mention the feedback categories (positive/negative/irrelevant) from the schema.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only states what the tool does, leaving the agent to infer the appropriate context from the tool name and schema.

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 of behavioral disclosure. It only says 'triggers re-analysis' without mentioning side effects, async behavior, required permissions, rate limits, or what happens to existing data. This is a significant gap for a mutation-like 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 short sentence with no filler, front-loading the core action and target. It is appropriately sized for the information it conveys, though it lacks depth.

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 tool has no annotations, no output schema, and a nested request schema. The description provides almost no contextual information about what the tool returns, whether it is asynchronous, or what 're-analysis' entails. This is far from sufficient for an agent 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 description coverage is 0%, so the description must compensate. It partially does by indicating the scope options ('specific pack/asset or entire'), which map to pack_id/asset_id and all. However, it does not explain the req wrapper or how to structure the nested fields, leaving some ambiguity.

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 ('triggers re-analysis') and the target ('specific pack/asset or all'), using a specific verb+resource structure. It is easily distinguished from sibling tools that primarily list, retrieve, or manage assets/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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent is left to infer that it should be used when re-analysis is desired, but there is no explicit context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention the long-poll behavior and the UI dependency, which are valuable traits not visible in the schema. However, it does not cover timeout handling, cancellation, or side effects, so transparency is partial.

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, front-loaded sentence that states the main action and adds key constraints without any redundant information. 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?

The description covers the core function and important constraints (long-poll, UI requirement), and an output schema exists. However, it lacks parameter guidance and edge-case behavior, and with no annotations the overall context is only partially 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?

Schema description coverage is 0%, and the description only vaguely references 'candidate assets' without explaining the req object, the required candidates array, reason, project_id, or timeout_seconds. The description fails to compensate for the schema gap, providing almost no parameter semantics.

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 asks the user to directly pick among candidate assets, using a specific verb ('request') and resource ('user pick'). This distinguishes it from sibling tools like suggest_packs or find_asset which do not involve interactive user choice.

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 useful usage context: it is a long-poll (5 minutes) and requires the GAH web UI to be running. However, it does not explicitly state when to use this tool versus alternatives like suggest_packs or list_assets, leaving the guidance implied 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?

With no annotations provided, the description must carry the transparency burden. It discloses the main behavior (returns find_asset results) and the ability to override fields, but it does not mention whether the operation is read-only, what happens with invalid saved search names, or pagination/error behavior. This is moderate disclosure but not comprehensive.

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 front-loads the primary action and output, with the override capability in parentheses. No unnecessary words; ideal for quick understanding.

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 tool has an output schema, so the description is not required to detail return values. However, it omits context around optional parameters like 'project_id', error handling, and when overrides should be used. Given the lack of annotations, the description leaves some gaps, but is adequate for basic usage.

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 0% description coverage, so the description must compensate. It adds meaning to the 'overrides' parameter by explaining it can overwrite some fields, but it does not explain 'name' or 'project_id', nor the nested 'req' structure. The description only partially compensates for the lack of schema 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 clearly states the action ('실행해' meaning execute/run) and the resource ('저장된 검색' saved search), and specifies the output type (find_asset results). This distinguishes it from sibling tools like save_search, list_saved_searches, or find_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 implies when to use the tool: when you want to execute a saved search and retrieve find_asset results. However, it does not explicitly contrast with alternatives or mention when not to use it, so guidance is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions a uniqueness constraint for names per project_id, but it does not disclose what happens on duplicate names (e.g., overwrite vs error), whether the operation is idempotent, what permissions are required, or what the return value looks like. This is a mutation tool with minimal behavioral 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 a single, concise sentence that front-loads the action and includes a key constraint. Every word contributes value, and there is no redundancy or 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?

Despite having an output schema, the tool is complex with many parameters and behaviors. The description does not clarify what constitutes a 'search request', how the uniqueness constraint behaves in edge cases, or any error conditions. It is too sparse for an agent to reliably select and invoke this tool without additional context.

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 0% description coverage and a complex nested SaveSearchRequest object. The description only adds meaning for 'name' and 'project_id' (uniqueness), while providing no explanation for the many other parameters (query, filters, count, diversity, labels, etc.). The schema's field titles and defaults offer some self-documentation, but the description does not compensate for the low 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 'Saves the search request with a name' (검색 요청을 이름 붙여 저장한다), which is a specific verb+resource. It also adds the constraint 'unique name per project_id' (project_id 별 unique name), which distinguishes it from sibling tools like list_saved_searches, delete_saved_search, and run_saved_search.

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

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

The description makes the tool's usage context clear: you use this to save a search request under a name. It does not explicitly name alternatives or when-not-to-use scenarios, but the purpose is unambiguous and aligns with the CRUD nature of the sibling tools.

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

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

No annotations are present, so the description carries the full burden of behavioral transparency. It merely says 'scan and sync' but does not disclose whether the sync is destructive (e.g., deletes missing packages), what permissions are required, or what happens if the cache directory is absent or malformed. The side effects on the DB are undefined.

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 redundant words. It front-loads the main action and outcome, making it easy to parse. There is zero fluff, and the sentence length is appropriate for a tool statement.

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 that the tool has a nested parameter structure and a database-syncing side effect, the description is too sparse. While an output schema exists and reduces the need to describe return values, the description still fails to cover the sync's behavior (e.g., force semantics, filter usage, whether it adds/removes entries) or its relationship to sibling tools. This is a significant gap for a non-trivial operation.

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 0%, and the description does not mention any parameters. The required 'req' object, along with its 'force' and 'filter' sub-fields, is completely unexplained. The description adds no value beyond what the schema already shows, leaving the agent without guidance on how to fill these fields.

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 and resource: it scans the Unity Asset Store cache directory and syncs the .unitypackage list to the DB. This clearly distinguishes it from sibling tools like list_unity_packages, which likely just list packages from the DB, and request_rescan, which may trigger a rescan without the DB sync aspect.

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 only states the function without mentioning prerequisites, exclusions, or any context that would help an agent decide between this and related tools like request_rescan or list_unity_packages.

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 only states that the tool modifies project state by pinning/blocking a pack, with no additional behavioral details. It does not disclose whether pins replace existing pins, how block accumulation works, or any permission requirements. With no annotations, this sparse disclosure is insufficient for a mutation 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 one short sentence with no wasted words, front-loading the action and resource. It is concise but at the expense of explanatory depth, making it somewhat under-specified for the tool's 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 a state-changing tool with optional parameters and no annotations or output schema, the description is far too sparse. It omits information about how pin and block parameters interact, side effects, and what happens on success or failure, making it inadequate for reliable invocation.

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

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

The schema provides no descriptions (0% coverage), and the description adds no parameter-level meaning. It mentions 'specific pack' and 'project' but does not map to pinned_pack_id versus blocked_pack_ids, leaving the agent unable to infer parameter semantics.

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 (pin/block) and the resource (a specific pack in a project), which distinguishes it from read/search siblings like list_packs and find_asset. However, it does not explicitly separate what it means to pin versus block, leaving slight ambiguity about the two behaviors.

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 given on when to use this tool versus alternatives. It does not mention prerequisites, common scenarios, or context for when pinning/blocking is appropriate. The agent cannot determine when to select this tool over suggest_packs or list_packs.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content and notes that it directly uses Unity AnimationClip, which is a useful implementation detail. However, it does not explicitly state whether the operation is read-only, what happens if the asset/animation is invalid, or any side effects. The word 'returns' implies non-mutating behavior, but this is not explicit.

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 in Korean. It front-loads the main purpose, includes meaningful specifics (sprite sheet, animation examples, output fields, Unity AnimationClip), and contains no fluff or redundant 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 tool is relatively simple, but the description lacks parameter explanations (especially asset_id) and does not mention error cases or prerequisites. The output schema may cover return values, but the description should still provide sufficient context for correct invocation. It is adequate but not comprehensive.

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 0%, so the description must compensate. It explains that 'animation' refers to walk/idle/etc. and mentions output fields, but it does not explain the 'asset_id' parameter at all. There is no guidance on how to identify the sprite sheet or the exact format of the animation string beyond examples. This leaves a significant gap for parameter understanding.

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: it returns frame_indices and fps_hint for a sprite sheet's animation (walk/idle/etc.). The verb '반환한다' (returns) and the specific resource '스프라이트 시트의 애니메이션' distinguish it from sibling tools like suggest_packs or find_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 implies usage: to get animation frame data for a sprite sheet. However, it does not explicitly state when to use this tool over alternatives or mention any prerequisites (e.g., asset must exist, animation must be present). No exclusions or alternative tool references are provided.

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 exist, so the description carries the full burden of behavioral disclosure. It only states sorting and user choice, with no mention of side effects, permissions, or ordering criteria. The tool appears read-only, but this is not explicit.

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 one concise, front-loaded sentence with no filler. The purpose is stated immediately, and the parenthetical adds relevant user-choice 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?

With no annotations, an output schema, and several parameters, the one-sentence description is insufficient. It does not explain key parameters or usage nuances, making it hard for an agent to construct a valid req or know when to choose this tool over siblings.

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 0% and the description does not explain any of the seven nested fields (kind, count, query, project_id, include_samples, include_thumbnails, min_matching_assets). Defaults and enums in the schema help, but the description adds no value beyond the tool 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 uses a specific verb '정렬한다' (sorts/ranks) and resource '팩 후보' (pack candidates), clearly distinguishing it from siblings like list_packs. It also adds the purpose of aligning with natural language queries and providing user choice.

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 implied use case is when a natural language query needs ranked pack candidates, but no explicit when-to-use or alternative tool exclusions are provided. Sibling tools like list_packs and request_user_pick are not referenced.

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