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

With no annotations provided, the description must carry the behavioral burden. It does disclose a key recovery property (images are re-downloaded when needed) and the dry_run reporting mode, but omits whether the operation is destructive, whether it can be undone, permission requirements, and whether it blocks or is synchronous.

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 tight lines: a purpose statement followed by one line per parameter. Front-loaded and free of redundant filler; each 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 two-parameter, annotation-less mutation tool, the description covers purpose, both parameter meanings, and the re-download behavior. The remaining gap is the absence of any permission, irreversibility, or scope caveats, which is a modest but real omission.

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, and it does: it explains the exact semantics of both parameters, including the non-obvious note that 0 means all and that dry_run reports without deleting. It does not document the types or defaults, but the meaning of each parameter is fully clarified.

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 (Deletes) and resource (cached images), and adds the distinctive trait that they are downloaded again when needed. No sibling tool touches caching, so it is immediately differentiated from the list.

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

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

The effect of each parameter is explained but there is no explicit when-to-use guidance, no mention of irreversibility, and no condition distinguishing when to prefer dry_run. Usage is implied from the parenthetical and parameter notes 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?

With no annotations, the description carries the full burden and does disclose several important traits: legacy links are accepted, the clipboard-JSON format is accepted, and unrecognized parameters surface in an `unresolved` field. It does not say what happens on a malformed URL or whether any network fetch occurs, but disclosure is well above the annotation-less baseline.

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, front-loaded with what the tool does and what it returns; the inline URL example and legacy/clipboard caveats each carry real information. The truncated example URL is a little noisy but still illustrative rather than wasteful.

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 single-parameter parsing tool with no output schema and no annotations, the description covers input formats, the returned structure, and the `unresolved` field, which is enough for an agent to call it correctly. Error handling for invalid input is the only notable omission.

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% (the lone `url` parameter is undocumented), so the description must compensate, and it largely does by explaining the two accepted input formats with a concrete URL example. It is slightly ambiguous whether the exported JSON is passed through the same `url` parameter, leaving a small 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 verb and resource ("Reads a link from the LPC generator site") plus the exact output shape ({body_type, items}) and names generate_character as the consumer. It never explicitly contrasts itself with the inverse sibling to_site_url, so the differentiation is inferred from context rather than stated.

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 trigger conditions are clear: use it when you have a link from the LPC generator site or JSON from the site's Export to Clipboard button, and the result is "ready for generate_character". There is no explicit "when not to use this" or routing to an alternative tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose the file side effect and naming convention (<prefix>_01.png, <prefix>_02.png...) plus that credits are saved. However it omits permissions, whether existing files are overwritten, rate/scale limits, and the default output location implied by output_dir.

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?

Front-loaded with the core purpose in the first sentence, followed by output behavior and the two documented parameters. The inline JSON example for fixed_items is compact, though it edges toward schema duplication rather than description 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?

A batch-mutation tool with 11 parameters, no annotations, and no output schema leaves too much unexplained: nine parameters undocumented, no auth/permission notes, no overwrite behavior, and no locality of output described beyond the filename pattern.

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% across 11 parameters, yet the description documents only body_types and fixed_items (with an example). The other nine (seed, count, split, export, layout, prefix, licenses, animations, output_dir) get no meaning at all, so agents cannot reason about most inputs.

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 and resource (generates many random characters at once) with a concrete framing example ('villagers for a town'), clearly distinguishing a batch operation from the single-character siblings. It stops short of explicitly naming the alternative tools like generate_character, so it is clear but not sibling-differentiated.

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 'many at once' framing implies batch use, and the villagers example hints at the scenario, but it never says when to prefer this over generate_character or how it relates to random_character. Usage is left 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 behavioral burden and does so richly: it discloses animation_check, license_check, warnings, replaced swaps, the consent requirement for prefer_complete, automatic oversized animation inclusion, and the credits files always written. This gives the agent a clear picture of side effects, outputs, and safety considerations.

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

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

The description is long but front-loaded with the core purpose, then proceeds through parameter explanations efficiently. Each sentence adds useful detail, though the dense parameter-by-parameter format could be more visually structured. Length is justified by the tool's complexity and the absence of schema descriptions.

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

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

For a complex 11-parameter generation tool with no annotations and no output schema, the description is remarkably complete. It explains behavior, output artifacts, validation checks, warnings, and parameter semantics well enough that an agent can invoke it correctly 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?

Schema description coverage is 0%, so the description must explain all 11 parameters, and it does so for nearly every one: items structure, body_type values, animations subset, layout modes, split modes, export targets, licenses filtering, zip packaging, output_dir defaults, and prefer_complete behavior. Only filename is not explicitly described, which is a minor omission given the overall compensation.

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

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

The description opens with a specific verb and resource: 'Builds the character spritesheet and saves it as PNG.' This clearly separates it from preview-only or batch tools by specifying that it writes a PNG artifact. An agent can understand the core operation without opening 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?

The description gives extensive guidance for individual parameters, including when to use prefer_complete only with user consent and when to use standard vs. compact layout. However, it never explicitly compares this tool to siblings like preview_character, random_character, or generate_batch, so tool-selection guidance is only implied.

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 behavioral burden. It implies a read via 'details', but says nothing about error behavior for unknown IDs, whether the result is cached, or the cost/latency of the per-body animation expansion it advertises.

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?

It is a single compact sentence with no filler, so it is not bloated. However, it is structured as a comma list of payload fields rather than a front-loaded statement of action and purpose, which weakens its utility as a first-glance summary.

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

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

With no output schema, the enumeration of returned data (bodies, animations, variants, multi-color parts) is genuinely useful and partially compensates. But the required input is undocumented and no usage context is supplied, leaving material gaps for a one-required-param 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% for the single item_id parameter, and the description never explains its expected format or origin. The only semantic content is about the return payload, not the input, so the agent gets no help on how to construct the required argument.

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 reads as a fragment listing return contents ('Item details: supported bodies, animations...') rather than stating a verb+resource cleanly. It is inferable that this fetches details for one item, but it does not distinguish itself from search_items or list_categories, so an agent must guess the 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?

No when-to-use guidance is given. There is no statement of when to call get_item versus search_items or list_categories, and no mention of prerequisites such as needing a valid item_id. The agent is left to infer usage entirely.

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 does disclose the return content ('how many items each has'), which is useful since there is no output schema. It says nothing about whether this is a pure read, permission needs, or result size, which are minor for a zero-parameter listing tool but not fully covered.

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?

A single front-loaded sentence with zero filler; the resource comes first and the examples and return content follow immediately.

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, no output schema, and no parameters, the description needs to convey purpose and return shape, which it does by naming categories and their item counts. An agent has enough to call it correctly, though a hint about ordering or scale is absent.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate.

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 and resource ('Lists item categories') and goes further by giving concrete examples (body, hair, torso/shirts), so an agent knows exactly what domain it covers. It does not explicitly contrast with siblings like get_item or search_items, keeping it 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?

Usage is implied: call this to discover what categories exist before searching or fetching items. There is no explicit when-to-use statement, no exclusion, and no named alternative among the many sibling tools, so it lands at minimum-viable.

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 and does well: it discloses that no files are saved (non-persistent), and that the return type varies (animated GIF vs still image) based on the animated flag. It does not cover auth requirements, rate limits, or error behavior, and never explains what the required items input must contain.

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?

Front-loads what the tool does and keeps to four tight lines with no filler; each sentence carries information. Slightly terse in places (e.g., the items obligation), but nothing is wasted.

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

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

No output schema and no annotations, so the description must fully carry the behavior. It adequately covers the animated/animation semantics and the non-saving nature, but omits any explanation of the required items argument or body_type, leaving real gaps for a 4-parameter tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains animated (True=GIF, False=still) and enumerates animation values (walk, idle, slash, run, 1h_slash, watering, oversized options), but says nothing about the required items parameter or body_type, leaving half the parameters undocumented.

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?

Specific verb (shows/preview) plus resource (the character) with explicit scope: the 4 directions side by side, rendered in chat and not saved to files. It distinguishes itself from the siblings by naming generate_character as the follow-up and implying this is a non-persistent look-see versus random_character/generate_character.

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?

"Use it to check the look before generate_character" gives a clear usage context and names the alternative tool the agent should follow with. It does not state explicit when-not-to-use conditions, but the preview-before-generate framing is unambiguous.

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 well: it discloses that no rendering occurs, that returned items are filtered to those with complete animations, that fixed_items are unconditionally merged in, and that seed makes rolls reproducible. Only permissions/rate/error behavior is absent, which is a minor gap for a pure randomizer.

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?

Dense but front-loaded: the core action and the no-render contract come first, then parameter notes. Every sentence carries information, though the parenthetical slot list is longer than strictly necessary.

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?

There is no output schema, yet the description spells out the return shape ({items, body_type, url}), which is exactly what an agent needs to chain into generate_character. Combined with the animation-completeness and fixed_items behavior, it is nearly complete; only body_type's semantics are missing.

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%, so the description must compensate. It explains fixed_items (always added, e.g. a weapon), seed (repeat the same roll), and licenses (restricts to named license families, with an example). However, body_type — a meaningful selector defaulting to 'male' — is never mentioned, leaving one of four parameters undocumented anywhere.

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 (rolls) and resource (random character) and enumerates the randomized slots (skin, head, hair, clothes, shoes, plus conditional beard/hat/vest). It also names the sibling it hands off to (generate_character), so the agent can distinguish it from generate_character and preview_character without opening a 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?

Explicitly frames this as the non-rendering step whose output is meant to be reviewed and passed to generate_character, which gives clear context for when to pick it. It does not state when-not-to-use it or contrast directly against preview_character/generate_batch, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does notable work: it discloses the AND semantics of 'query' words, the prefix matching of 'category', the body_type-derived default for 'animation', the ordering side-effect of 'complete_only', and the intersection logic of 'licenses'. It omits pagination behavior and the meaning of 'limit', plus any auth/rate-limit notes, which keeps it short of a 5.

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?

Front-loaded with the core action and the key fact that all filters are optional, then one compact line per parameter with examples. Dense but every line earns its place; the only slack is the trailing sentence about result completeness, which restates earlier content rather than adding new guidance.

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, zero-schema-coverage search tool, the description covers the filter semantics, a practical license-selection rule, and the shape of each result's completeness fields. Since an output schema exists, it does not need to enumerate return values, so nothing essential is missing.

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% across 8 parameters, so the description must compensate, and it explains 7 of them with formats and examples (category prefixes like 'torso/shirts', animation ids like 'slash', license families). Only 'limit' is left undocumented, and the per-result field explanation (complete, missing animations, drm_safe) adds value the flat schema cannot.

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+resource ('Searches items') and immediately characterizes the whole filter set as optional and combinable, which tells an agent this is a broad query tool. It does not, however, differentiate itself from siblings like get_item or list_categories, which would require either naming them or stating the boundary.

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?

Usage is implied through per-filter explanations and the concrete example ('leather armour'), plus practical routing advice for DRM stores ('use ["CC0", "OGA-BY"]'). But there is no explicit when-to-use vs. when-not, and no mention of the sibling get_item for single-item lookups, leaving the agent to infer the search-vs-fetch choice.

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

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

No annotations are provided, so the description carries the full burden. It implies URL construction and browser opening but does not disclose whether the operation is read-only, what permissions are needed, whether state changes occur, or any limits on item count or encoding.

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 efficient sentence that front-loads the core action and purpose. Every phrase contributes to understanding what the tool does, with no obvious 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?

For a two-parameter tool with zero schema description coverage and no annotations, the description leaves too much unspecified. It does not explain item structure, body_type, or behavioral expectations; only the existence of an output schema reduces the need to describe return values.

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 should compensate but largely does not. It refers to 'these items' without explaining their object shape or contents, and it completely omits body_type even though that parameter has a default and likely affects the generated link.

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 verb and resource: builds a generator site link using provided items. It makes the browser-facing purpose clear. It does not, however, distinguish this from sibling tools such as from_site_url or preview_character.

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 explicit guidance on when to use this tool versus alternatives like from_site_url or preview_character. The phrase 'to open and tweak the character in a browser' implies the context but does not state prerequisites, exclusions, or alternative paths.

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 does disclose a meaningful side effect (clear_image_cache=True deletes downloaded PNGs so they are refetched) and implies a network pull from an external repository. However, it doesn't say whether existing local definitions are overwritten, whether this is destructive, or if a network connection is required.

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

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

Two tight sentences with the primary purpose front-loaded and the parameter caveat second. Nothing is wasted, though the phrasing 'Pulls new items and palettes' is slightly loose relative to the tool's update semantics.

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 one-parameter tool with no annotations and no output schema, the description covers the action and the parameter side effect. It stops short of stating what happens to existing definitions, whether the operation is idempotent, or what the call reports back when it completes.

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, and it does: it explains exactly what clear_image_cache=True does (deletes downloaded PNGs so they are fetched again). It covers the sole parameter's intent and side effect, though it doesn't state the default value (false) explicitly.

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 and source: pulling new items and palettes from the official LPC generator repository, which clarifies the otherwise generic name 'update_definitions'. It does not, however, distinguish this tool from siblings like clear_cache or list_categories, so the agent gets purpose but not 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisite or exclusions. With siblings such as clear_cache and generate_character present, the absence of routing guidance is a real gap; the only context is about a parameter, not about tool selection.

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