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

With no annotations, the description carries the full behavioral burden. It usefully discloses a real caveat: without paid Sbis access, contacts and headcount are returned masked (contacts_masked), which tells the agent to expect partial data. It does not cover other behavior such as invalid-INN handling, auth requirements, or rate limits.

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 no filler; the field list is front-loaded and the masking caveat follows as a qualification. The dense comma-separated field enumeration is efficient, though the stray line break slightly hurts formatting.

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?

This is a low-complexity, single-parameter tool with an output schema, so return values need not be explained. The description still adds value by flagging masked data and listing covered fields. Missing only routing guidance against the many sibling 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 coverage is 0% and the single parameter 'inn' has only a title, so the description must compensate. Saying the card is looked up 'по ИНН' identifies the parameter as a company tax identifier, adding modest meaning beyond the schema. It gives no format, validation, or example for the INN value.

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 (company card) keyed by INN and enumerates the fields returned: status, all OKVED codes, addresses, director, revenue, headcount, contacts. That is far more informative than the bare name. It does not explicitly distinguish itself from siblings like company_financials or search_companies, which overlap on revenue and company lookup, so it stops 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?

There is no when-to-use guidance: nothing says whether to call this before or instead of company_financials, company_vacancies, or search_companies. The only implicit signal is that the tool takes an INN, which presupposes the agent already has one. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full behavioral burden. It does add real value by disclosing the source (open FNS/GIR BO), which implies coverage limits (only officially filed accounts; possibly no data for very new or small entities), but it says nothing about years covered, empty-result behavior, caching, or cost of the call.

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 listing the returned metrics followed by the data source, with no filler or repetition. Nothing could be trimmed without losing 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?

An output schema exists, so return values need no explanation, and for a one-parameter lookup the description covers what data comes back and from where. The remaining gap is that it never states the input is an INN or how companies without filed statements behave.

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 never mentions the sole parameter, so the connection to INN is only implied by the FNS context. The parameter name 'inn' is a well-known Russian company identifier, which keeps this workable, but the description adds no meaning beyond the schema itself.

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 concrete resource set (revenue, net profit, assets by year) and its provenance (open FNS reporting / GIR BO), so the agent knows exactly what data this returns. It does not explicitly contrast itself with siblings like company_card or search_companies, but the financial-reporting scope is distinctive enough in practice.

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 when-to-use or when-not-to-use guidance and no alternative tool is named. The agent must infer that this is the lookup to pick when financial figures are needed for an already-identified company, rather than e.g. company_card.

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, and it does disclose two real behaviors: an authentication dependency (HH_APP_TOKEN) and a degraded fallback that returns a search link instead of vacancies. It stops short of describing result limits, pagination, or what the fallback link contains.

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 compact sentence with the resource front-loaded and the token caveat trailing. Nothing is wasted, though the terseness leaves the parameter unexplained.

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 need not be explained, and the auth/fallback note covers the main behavioral risk. Missing is any indication of the expected company_name format or matching behavior, which matters for a single-parameter lookup 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 coverage is 0% for the single parameter, so the description must compensate, but it says nothing about the expected form of company_name: exact legal name, partial name, slug, or ID. Only the loose notion of 'company' is conveyed.

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 verb and resource: open vacancies of a company, sourced from hh.ru. It is clearly distinct from siblings such as company_card or company_financials, though it never explicitly contrasts itself with them.

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

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

It gives a conditional hint (with HH_APP_TOKEN you get vacancies; without it you get a search link), which implies when the tool is usable. It offers no guidance on when to choose it over search_companies or company_card, and no prerequisites beyond the token.

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 supplied, so the description must carry the full behavioral burden and it does not. It never states how many categories come back, whether the match is case-insensitive or starts-with vs anywhere-in-title, or what an empty query (the parameter default is "") returns.

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, resource first then parameter meaning with inline examples; nothing is redundant and the key constraint is front-loaded.

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 need not be described, and a single parameter keeps the surface small. Still, without annotations the description should say what a bare/empty query does and roughly what matching rules apply; those gaps matter 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?

Schema description coverage is 0%, and the description compensates by defining the sole parameter as a substring of the category name, with three real fragments as examples. That is the critical semantic an agent needs — partial matching rather than ID or exact name — though the empty/default value behavior is left unexplained.

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

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

The description names a specific resource — industry categories of the Saby catalog — and the examples of a name fragment make the 'find by substring' intent unambiguous. It does not distinguish itself from the related sibling find_regions, which is the only missing element for 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 by the illustrative fragments («отход», «эколог», «очистк»), which show how to shape a query. However, there is no explicit when-to-use or when-not-to-use guidance and no mention of find_regions as the alternative for geographic lookups.

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 supplied, so the description carries the full behavioral burden; it implicitly establishes a read-only reference lookup and documents the accepted query forms (name, numeric code, abbreviation). It does not disclose matching semantics — e.g. whether 'мск' is exact or substring, and whether one query can return multiple regions — which is the main behavioral unknown for a lookup 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?

Two short sentences with zero filler, the purpose front-loaded and the parameter forms immediately after. Every clause adds information an agent needs.

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 need not be explained, and for a one-parameter lookup the definition is nearly sufficient. The remaining gap is match behavior and result multiplicity, which matter for a filter-value resolver and are not covered anywhere.

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 single 'query' parameter has no schema description — so the description must compensate, and it does: it enumerates the three accepted value shapes with concrete examples (77, мск, спб, мо). Only the matching mode (exact vs partial, case sensitivity) is left unspecified.

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 the resource and its role concretely: RF regions used as search-filter values, so an agent knows this is a reference lookup rather than a data search. It does not explicitly distinguish itself from siblings like find_categories, but the resource is specific enough to select it confidently.

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

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

'Для фильтра поиска' implies the context of use (resolving a region filter value before calling search tools), but there is no explicit when-to-use/when-not statement and no named alternative among the siblings. Usage must be inferred from the phrase 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 behavioral burden and does disclose the authentication requirement via environment variables, which is genuinely helpful. It does not state whether the call is read-only, what happens when SBIS_LOGIN/SBIS_PASSWORD are unset, or whether any state is touched — though the presence of an output schema removes the need to explain return values.

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 resource and the credential precondition front-loaded; nothing is redundant or padded. The parenthetical is compact and carries real 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?

For a zero-parameter status check with an output schema already defined, the description covers the key fact an agent needs (credentials must be configured). The main omission is the failure mode when credentials are missing, but overall it is sufficient to call the tool correctly.

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

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

The tool takes zero parameters, so there is no schema semantics to add beyond the baseline. The description does note that inputs come from environment variables rather than arguments, which is a small but relevant clarification for an otherwise parameterless tool.

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: checking whether login to a paid SBI account is valid ("Проверить вход в платный аккаунт СБИС"). This is clearly distinct from the sibling tools, which are all company/shortlist lookups. It stops short of explicit sibling differentiation, but the resource is 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 parenthetical "если заданы SBIS_LOGIN/SBIS_PASSWORD" gives an implicit precondition for meaningful use, which is useful context. However, it does not say what to do when credentials are absent (error vs. unauthenticated result) or route the agent among alternatives, so guidance remains 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 supplied, so the description carries the full burden. It does disclose two real behavioral traits — results are sorted by descending revenue and page_size is capped at 40 — but says nothing about read-only safety, whether min_revenue_mln excludes companies with unknown revenue, or what a page beyond the last returns.

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 of purpose followed by a tight per-parameter list; every line adds information an agent would otherwise have to guess. Nothing is repeated and the primary intent is front-loaded.

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 parameters, no annotations and an existing output schema, the description does enough: it explains filtering semantics, ordering and the page-size ceiling, and points to the two lookup tools needed to construct valid values. The missing piece is pagination behavior for the 'page' parameter, which leaves a small but real hole for an agent iterating 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 coverage is 0%, yet the description explains five of six parameters meaningfully: category accepts a name, slug or id, query matches name/INN/city, region is a region reference, min_revenue_mln is a threshold in millions of rubles, and page_size is bounded at 40. Only 'page' is left undocumented, which is a modest gap rather than a blocking one.

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

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

The opening line gives a specific verb and resource ('Найти компании в каталоге Saby') plus the result ordering ('по убыванию выручки'), so an agent knows exactly what this tool returns. It does not explicitly contrast itself with siblings such as company_card, but the search semantics are 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?

Usage is only implied by the verb 'search'; there is no statement of when to prefer this over company_card or how to combine it with shortlist_add. The cross-references '(см. find_categories)' and '(см. find_regions)' are genuinely useful for resolving valid values, but they guide parameter filling rather than tool 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?

With no annotations, the description carries the full behavioral burden and does disclose one non-obvious trait: data is enriched from Saby ('Данные подтягиваются из Saby'), implying an external lookup and possible latency/failure. It does not state whether repeat calls are idempotent, what happens when 'inn' already exists, or whether the operation is reversible.

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 primary action front-loaded and the secondary update behavior immediately after. Nothing is wasted, though the second sentence sits apart without connecting to the parameters.

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 need not be described, and the upsert + Saby enrichment traits are covered. For a 3-parameter, zero-coverage schema with no annotations, the definition still leaves the agent guessing about INN format, valid statuses, and duplicate handling.

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 not: 'inn', 'note', and 'status' are never explained, nor is the allowed set of status values (the schema only hints at a default of 'интересно'). It only obliquely maps 'note'/'status' to the update capability.

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 ('Добавить компанию в шорт-лист') and adds the important nuance that it also doubles as an update path for note/status. Sibling differentiation is left implicit — the name pairs with shortlist_remove/shortlist_show, but the description never names them.

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 '(или обновить заметку/статус)' signals when to reuse this tool instead of a separate update call, which is genuine usage guidance. There is no guidance on the add-vs-remove boundary, prerequisites, or what to do if the company is already shortlisted.

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 supplied, so the description carries the full burden and does not disclose the important behaviors: write side effects (where the file is written, whether an existing file is overwritten), whether a shortlist must be non-empty, or any auth/rate constraints. The Excel hint is useful, but the file-writing behavior, which is the tool's core mechanic, is left opaque.

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 compact sentence with the action front-loaded and the format options following immediately; there is no filler. It is arguably too terse, 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?

The tool is simple (one optional parameter) and an output schema exists, so return values need not be explained. However, for a file-producing tool, the destination and overwrite semantics are material omissions that leave the definition only minimally 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 coverage is 0% for the single 'fmt' parameter, so the description must compensate – and it partly does by enumerating the accepted values (csv, md) and explaining the practical difference. It does not state the default or whether other values are valid, so it falls short of full 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 gives a concrete verb+resource pair ('Сохранить шорт-лист в файл' – save the shortlist to a file), which clearly separates it from read-only siblings such as shortlist_show. It does not explicitly name a sibling alternative, so it stops 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 only implied: export the current shortlist when you need it as a file. The parenthetical '(открывается в Excel)' hints at when csv is preferable, but there is no explicit when-to-use vs when-not guidance or reference to alternatives like shortlist_show.

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 supplied, so the description carries the full behavioral burden, yet it only restates the action. It does not state whether removal is idempotent, what happens if the company is not in the shortlist, whether confirmation is needed, or what permissions apply — all material for a mutating 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?

One short, front-loaded sentence with no wasted wording. It is appropriately sized, though it errs toward under-specification rather than verbosity.

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 return value is covered by the output schema, but for a mutation tool with zero annotations and an undocumented parameter, the description omits error behavior, idempotency, and preconditions. It is not complete enough for confident 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?

Schema coverage is 0% and the single parameter 'inn' has only a title, no description. The phrase 'компанию' weakly implies the parameter identifies a company, but the description never explains what INN is, its format, or that it must match an existing shortlist entry.

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 gives a specific verb and resource combination ('Убрать компанию из шорт-листа' — remove a company from the shortlist), which distinguishes it clearly from the add/show/export siblings. It does not explicitly name which sibling to use instead, but the action is 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?

There is no guidance on when to use this versus shortlist_add, shortlist_show, or shortlist_export, and no stated preconditions. An agent must infer usage entirely from the name and the one-line purpose.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses nothing: not whether the list is per-user or global, whether it is empty by default, or whether it has side effects. The only behavioral hint is the verb "show", which is minimal for a zero-annotation 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?

It is a single short sentence and contains no filler, but the brevity is under-specification rather than tightness: it is front-loaded on nothing and gives the agent no extra anchor. A marginally longer description naming the return content would earn the same score more convincingly.

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 need not be explained, but with zero annotations and a one-line description the agent still lacks scope, preconditions, and sibling routing. For a shortlist-read tool sitting next to export/add/remove siblings, that leaves meaningful gaps.

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 no parameters, which is the stated baseline of 4. The description adds nothing about filtering or scoping options, but there is nothing to add given the empty 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 the resource and a display action ("Показать шорт-лист" = show the shortlist), so the basic intent is legible. However, it offers no differentiation from siblings such as shortlist_export (which presumably also displays/returns the list) or shortlist_add/remove; the agent must infer the boundary from names alone.

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 when-to-use guidance, no mention of prerequisites (e.g. whether items must first be added), and no stated alternative such as shortlist_export for retrieving data. The agent is left to guess the use case from the tool name.

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