Vice City Mission: GTA 6

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds genuine behavioral context: results are ordered missable-first and include a completion percentage. With no output schema, that return-shape detail is the main thing the description must carry, and it does so concisely.

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?

One sentence, front-loaded with the input condition, then the output contract (missable first, completion percentage). Nothing is wasted and no filler precedes the substance.

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 read tool with full schema coverage and no output schema, the description supplies the input source and the return ordering/summary. Minor gaps remain — the shape of returned items (ids vs. names) and how unknown or partial ids are handled are unstated.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes one better by documenting the provenance and expected format of completed_ids (the tracker's export button). The optional category parameter is only documented in the schema, not the description, which keeps it from a 5.

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+resource: take completed ids and return the remaining items plus a completion percentage. That is clearly distinct from the sibling get_checklist (which presumably returns the full list), though it never names that sibling to make the split explicit.

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

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

It tells the agent exactly where the required input comes from — the tracker's 'Copy progress for AI' button — which is a real prerequisite that prevents malformed calls. It stops short of saying when to prefer this over get_checklist or what to do if ids are stale/invalid.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (result ordering, in-game meter units, gtadb.org coordinate reference), but is silent on what happens when neither an origin coordinate pair nor near_location_id is supplied, and on what takes precedence if both are given.

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 compact sentences with the core operation and ordering front-loaded, and units/coordinate reference packed into the second. No filler or redundancy.

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

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

For a six-parameter tool with zero required parameters and no output schema, the definition should say what the default query is when no origin is provided and how radius interacts with a pin-based search. Those gaps remain even though schema coverage is 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 100%, so every parameter including x/y units, radius, limit and category enum is already documented in the schema. The description only restates the coordinate convention and nearest-first ordering, adding little beyond what the schema provides, and does not resolve the x/y versus near_location_id precedence question.

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 ('Find pins close to another pin or to a map position') plus result ordering ('nearest first'), so an agent knows this is a proximity query rather than a name/text search. It does not name the sibling tools (search_locations, search_landmarks) that the non-proximity cases map to, so differentiation is inferred 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 two supported origins (another pin vs. a map position) are described, which implies when the tool is appropriate, but there is no explicit when-not guidance or named alternative for name-based discovery. The agent must infer from sibling names like search_locations that those cover non-proximity queries.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description doesn't need to repeat safety. It adds genuine context that is not in annotations or schema: the checklist enumerates item ids that match saved tracker progress, which tells an agent how to correlate results across calls, and it names the item types returned.

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

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

Two sentences, no filler, with the resource and its scope front-loaded before the id-matching note. The second sentence is slightly compressed but still earns its place as the only non-obvious fact in the description.

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 optional-parameter read with no output schema, the agent needs to know what comes back; the description lists the checklist sections and notes that items carry ids matching saved progress. Missing only pagination/size expectations for what could be a large list.

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

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

Schema coverage is 100% and the category parameter already documents its five section ids, so the baseline is 3. The description restates the same sections in prose but adds no filtering semantics (e.g. omitted category returns everything).

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 resource (the completion checklist) and enumerates its contents: story missions, side missions, activities, collectibles, trophies. That is clear, but it never distinguishes itself from the sibling `checklist_remaining`, which an agent could easily confuse with a full checklist.

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 only implied: an agent can infer this returns the full checklist and that the category section selects a slice. There is no explicit when-to-use/when-not and no mention of the obvious alternative `checklist_remaining` for partial-progress queries.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot express: every item carries a provenance marker (official, reported, or community estimate), which tells the agent how much to trust the output. Return shape/pagination is still unstated.

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?

One dense sentence that front-loads the resource and then enumerates sections, followed by a short trust-signal sentence. No filler, though the section list is partly redundant with the enum already in the schema.

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-param, read-only lookup with no output schema, the description is adequate: it covers scope and data provenance. It is incomplete in two respects — the 'faq' section is undocumented, and there is no disambiguation from get_launch_info, which appears to overlap on price/platforms/editions.

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

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

Schema coverage is 100% and the single enum parameter is fully documented in the schema, so baseline is 3. The description restates the section breakdown but adds no new meaning, and it omits the 'faq' section entirely, so it does not even fully mirror the schema.

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

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

The description names a specific resource (confirmed GTA VI facts) and enumerates exactly what it returns: quick facts, characters, and regions of Leonida. That is far more informative than the title alone, but it never distinguishes itself from overlapping siblings such as get_launch_info (which plausibly also covers price/platforms/editions) or get_news.

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 only implied by the content enumeration — an agent can infer this is the reference/fact-lookup tool rather than a search tool like search_landmarks or find_nearby. There is no explicit when-to-use, when-not-to-use, or named alternative, and the overlap with get_launch_info is left unresolved.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds valuable context the annotations can't: it enumerates the return payload (release date, days remaining, community data volume) and acts as a prerequisite probe before other calls.

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 short sentences with zero waste: payload contents first, then the when-to-call rule. Front-loaded and immediately actionable.

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

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

With no output schema, the description carries the burden of describing the return values, and it does so adequately. "How much community data" remains slightly vague about format, but for a zero-param status probe it is sufficient to call 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?

Zero parameters, so the baseline of 4 applies; there is no parameter semantics to explain. The description correctly avoids inventing parameters or implying optional filters.

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?

Names a specific verb and resource (launch info: release date, days remaining, community data coverage) that a sibling like get_game_info would not cover. It is clear what comes back, but it never explicitly distinguishes itself from get_game_info or get_news, leaving the boundary to inference.

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?

"Call this first if unsure whether data exists yet" gives an explicit sequencing rule and the condition that should trigger it. It stops short of naming alternatives or stating when not to call it (e.g., before/after launch), so it isn't a full 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?

Annotations already declare this is a read-only, idempotent, non-destructive operation with no open-world access. The description adds that it returns 'full details' for a single pin, which is modestly useful context, but does not describe error behavior or response characteristics beyond that.

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 no redundant or filler content. It communicates the essential 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 one-parameter read tool with full schema coverage and clear safety annotations, the description is nearly complete. It could mention what happens when the id is not found, but no output schema exists and the essential calling information is present.

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

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

Schema coverage is 100%, and the id parameter already documents that its value comes from search_locations or find_nearby. The description's 'by its id' adds no meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: retrieve full details for one map pin identified by id. It is clear and unambiguous, though it does not explicitly differentiate itself from sibling retrieval tools like get_game_info or search_locations.

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

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

The phrase 'by its id' implies the tool should be used when an id is already known, but the description does not explicitly state when to choose this over search_locations or find_nearby. The schema's id description provides that routing, but the description itself only implies usage.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data is 'confirmed' (i.e., partial and pre-launch) and full tracklists only arrive at launch, which tells the agent to expect incomplete results — a real caveat absent from the annotations.

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 tightly packed sentences with no filler; the content inventory is front-loaded and the launch-timing caveat closes it out. The dense parenthetical list is slightly heavy but every element maps to a real data attribute, so 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?

For a read-only reference lookup with full schema coverage and no output schema, the description covers content scope, what each song record carries, and the pre-launch incompleteness caveat. The only mild gap is not describing result volume or filtering behavior when 'all' is selected, which is minor for this tool type.

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

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

Schema coverage is 100% so the baseline is 3, but the description enriches the enum semantics by spelling out what each section actually contains (e.g., radio stations include genre, on-air hosts, reported voice actors, previewed songs), which goes beyond the schema's one-line enum descriptions. It also clarifies that per-song streaming links are always attached, adding value over the schema.

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

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

The description names a specific resource (GTA VI music) and enumerates its sub-parts — radio stations, album singles, Justice's score, trailer songs — so an agent knows exactly what data the tool returns. It doesn't explicitly contrast itself with siblings like get_game_info or get_news, leaving that differentiation to inference, which keeps it just 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 rather than stated: an agent can infer this is the tool for soundtrack/music questions, but the description never says when to call it versus get_game_info or get_news, nor any exclusions. The 'Full tracklists arrive at launch' line hints at a timing caveat but isn't framed as guidance.

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?

Annotations already declare this a safe, idempotent, closed-world read, so the description's job is to add context — and it does, disclosing sort order, the per-item record shape (date, status, source links), and the status taxonomy (official/reported/community). It stops short of saying whether the list is curated/static or how large the corpus is, so not 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?

One sentence, front-loaded with the resource and ordering, with no filler. Every clause (ordering, status values, source links) carries information the agent would otherwise have to discover.

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

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

With no output schema, the description takes on return-shape disclosure and does it well for a simple, single-optional-parameter read tool. The only residual gap is whether the timeline is a fixed curated set or refreshed, which affects how an agent should present results.

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

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

Schema description coverage is 100% and the single parameter already explains 'newest first' and its bounds. The description's mention of 'newest first' merely echoes the schema rather than adding meaning, so the baseline 3 applies.

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

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

The description names the resource precisely (major GTA VI announcements) and its ordering (newest first), which cleanly separates it from siblings like get_game_info or get_launch_info. The verb is only implicit ('announcements... each with'), so it reads as a content summary rather than an explicit retrieval action, keeping it just below 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?

There is no statement of when to use this tool versus get_launch_info, get_game_info, or any other sibling, and no preconditions or exclusions are given. The agent must infer usage purely from the resource name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is fully covered. The description adds genuine value beyond that by disclosing that counts of pins accompany each category, which is the only signal about output content since no output schema exists. It does not say whether counts are scoped to a save file or live globally.

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 sentence with the payload front-loaded and the category enumeration in a parenthetical. The list is long but earns its place by telling the agent what coverage to expect. Minor cost: the sentence is one clause-chain rather than split into purpose plus return 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?

For a zero-parameter, read-only enumeration tool with no output schema, the description covers both what the categories are and what accompanies them (pin counts), which is the information an agent needs to decide to call it. It stops short of stating whether this is the recommended entry point into the map toolset or how the counts relate to search results.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is an empty object with 100% coverage, consistent with the parameterless nature of the call.

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

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

The description names the resource (map location categories) and, crucially, discloses the return shape: each category plus its pin count. The enumerated examples (missions, collectibles, weapons, vehicles, shops, activities, secrets) make it unmistakable versus siblings like search_locations or find_nearby. It lacks an explicit verb, reading as a noun phrase rather than 'Returns the categories...', which keeps it just below 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?

There is no statement of when to call this versus search_landmarks, find_nearby, or search_locations, and no mention that it is the natural discovery step before a filtered search. Usage is only inferable from the fact that it takes no parameters and enumerates a taxonomy.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-structured context: dataset scale (~1,900), provenance and license (map.gtadb.org, CC BY 4.0), and what 'matched' means (community-confirmed against real addresses). It stops short of describing result shape or ordering.

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 dense sentences with zero filler; the dataset identity and scale are front-loaded, then search modes, then the optional radius constraint. Every clause carries information an agent would not get from structured fields.

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 six optional params, rich annotations, and no output schema, the description covers what the tool searches over and how to constrain it. The one remaining gap is that with no output schema an agent still doesn't know what fields a returned landmark contains.

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

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

Schema description coverage is 100%, so the schema already documents limit, query, near_x/near_y pairing, radius and confirmed_only — the near/radius pairing described in the text is already in the schema. The description's only real addition is example query strings like 'Ocean Drive' and 'airport', a modest increment over the schema baseline.

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

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

States a specific verb and resource — search ~1,900 GTA VI locations matched to real Miami/Florida places — with concrete example queries. It implicitly distinguishes itself from search_locations by emphasizing the in-game↔real-world mapping, but never names that sibling to make the distinction explicit.

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

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

Gives clear usage modes (search by in-game area or real place; optionally radius-limited) with examples, which is more than implied usage. However, it offers no when-not guidance and does not address the obvious overlap with the sibling find_nearby for the radius workflow.

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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is settled. The description adds genuine value by enumerating the returned fields, but it says nothing about result ordering, what happens when no match is found, or how the 50-item cap interacts with the default limit.

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

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

Two sentences, zero padding. The purpose leads and the return contract follows, with no redundant restatement of the tool name or title.

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

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

With no output schema, the description's field enumeration is exactly the right compensation for that gap. What's missing is the ranking/ordering of results and any note that the search is substring-based rather than exact, which matters for a tool with 0 required params.

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

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

Schema description coverage is 100% and the category enum is declared, so all four parameters are already documented with examples and defaults. The description's phrase 'by text and/or category' only restates the query and category params without adding syntax, matching rules, or combination behavior, so baseline 3 applies.

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

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

The description states a specific verb and resource: 'Search community-submitted GTA VI map pins by text and/or category.' That clearly distinguishes it from a fetch-by-id tool, but it never contrasts itself with siblings like find_nearby, search_landmarks, or list_categories, so the agent must infer which search variant to use.

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 when-to-use guidance, no prerequisites, and no stated exclusions. The reader must infer from the phrase 'by text and/or category' that this is the keyword/browse path rather than the proximity path (find_nearby) or single-record path (get_location), and the description never says so.

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